The Participant Relationship Protocol (PRP): A Relationship-Centric Network Architecture

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 23 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

Internet communication is commonly described through addresses, routes, transport state, and application endpoints. Those objects are necessary realization mechanisms, but none of them alone expresses the durable authorization and continuity context between communicating participants. Addresses can change, paths can fail, transport sessions can be rekeyed, and carrier attachments can disappear while the reason and authorization for communication remain.¶

PRP introduces the relationship as an explicit architectural object. A relationship records the rules under which participants recognize continuity, constrain identity, authorize communication, and replace realization mechanisms. Reachability can make communication technically possible, but it does not create or expand relationship authority.¶

The foundational statement of PRP is:¶

Communication becomes possible because a relationship already exists.¶

This is an architectural ordering rather than a claim that packets can be exchanged before reachability exists. Paths, transports, and carriers move information, while routes select scoped forwarding outcomes. The relationship determines why an exchange belongs to a continuing authorized context and which realization mechanisms are acceptable for that context.¶

This document is intended for protocol designers, implementers, researchers, and reviewers evaluating relationship-centric networking. It is published for informational purposes through the Independent Submission Stream and does not represent IETF consensus or specify an Internet Standard.¶

2. Requirements Language

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Scope

This document defines:¶

• the relationship-centric communication model;¶
• the distinction among relationships, identities, sessions, trajectories, routes, paths, adjacencies, transports, and carriers;¶
• architectural layers and dependency boundaries;¶
• continuity, authorization, and trust invariants;¶
• security and privacy properties that every realization must address; and¶
• requirements for claiming architectural conformance.¶

This document does not define packet or record layouts, cryptographic algorithms, numeric registries, session-establishment messages, routing or discovery algorithms, carrier bindings, application object models, deployment mechanisms, or administrative interfaces. Separate specifications may define those subjects provided they preserve the invariants in this document.¶

4. Foundational Model

An address-centric communication sequence is often summarized as:¶

address -> route -> transport -> communication

PRP instead places the relationship and its continuity rules before the realization mechanisms:¶

relationship -> continuity and authorization
                       ^
                       |
 trajectory / route decisions / transport / carrier

The relationship does not replace the lower-layer mechanisms. It supplies the persistent context against which their use, replacement, and failure are evaluated. A realization can therefore move between addresses, paths, sessions, or carriers without silently creating a new relationship, provided continuity is authenticated under relationship policy.¶

5. Terminology

Participant:

An entity capable of taking part in a relationship. A participant can represent a person, process, service, device, organization, or another entity type.¶

Relationship:

A persistent communication and authorization context among participants. Persistence is semantic and does not require a particular storage mechanism or uninterrupted availability.¶

Continuity:

The ability to determine, under relationship policy, whether an interaction belongs to the same relationship across time or a change of realization mechanism.¶

Identity:

A representation by which a participant or service can be distinguished within a defined scope. An identity constraint is relationship policy specifying which identity properties are required, permitted, or prohibited.¶

Trust material:

Information used to evaluate continuity, authorization, or identity constraints. Transport reachability alone is not trust material unless relationship policy explicitly makes it so.¶

Authorization boundary:

The set of actions permitted within a relationship. Authentication evaluates a principal or continuity claim; authorization determines what that claim is allowed to do.¶

Session:

Bounded cryptographic and operational state used to exchange information within a defined scope and generation. A relationship can use multiple sessions over its lifetime.¶

Route:

A scoped directional forwarding decision used in the realization of a trajectory. A route selects an eligible next path, adjacency, or local-delivery outcome. It is one decision leg of a trajectory and is not the trajectory itself.¶

Trajectory:

A validated directional realization of reachability for a relationship. A trajectory can span multiple route decisions and contains one or more paths.¶

Path:

An authenticated directional opportunity to carry traffic within a trajectory.¶

Routing identifier:

An operational selector for local route state, interpreted within an explicit routing scope and lifetime.¶

Adjacency:

A context in which participants can directly exchange units through a carrier under a defined local scope. Physical proximity or carrier enumeration can create an adjacency candidate but does not establish an authenticated relationship.¶

Transport:

The exchange semantics used to realize a relationship, including the applicable authentication, confidentiality, integrity, replay, ordering, and reliability properties.¶

Carrier:

A mechanism capable of moving protocol units between adjacent participants. Carrier technology and locators are realization details.¶

Service:

A capability exposed within an authorization context above core relationship semantics. Discovery, governance, evaluation, storage, and application protocols can be services without becoming prerequisites of every deployment.¶

Aggregation:

An optional relationship-realization arrangement in which an authorized participant coordinates or intermediates multiple independently authorized relationship contexts or trajectories. Aggregation does not merge relationships, identities, continuity state, or authorization boundaries. It is distinct from packet batching, data summarization, and group identity.¶

Aggregator:

A participant performing aggregation under explicitly delegated relationship authority. Acting as an aggregator grants no implicit authority over endpoint identity, relationship continuity, or application authorization.¶

6. Architectural Invariants

7. Architectural Layers

1. The relationship layer defines continuity, trust, authorization, and communication permissions.¶
2. The routing layer selects and maintains trajectories and the scoped route decisions that realize a relationship.¶
3. The transport layer supplies exchange semantics over those trajectories.¶
4. The carrier layer moves units between adjacent participants.¶

Services operate above these concerns. A protocol can combine layers in one component, message, or cryptographic transcript, but it MUST retain their semantic boundaries.¶

A function belongs to the architectural core only when every valid deployment requires it, it cannot be supplied as an optional service, and omitting it would invalidate the relationship-centric model.¶

8. Conceptual Operation

This section is non-normative. It illustrates the distinction between a relationship and its realizations without prescribing messages or implementation components.¶

1. Participants possess local policy and trust material sufficient to recognize or propose a relationship.¶
2. A carrier supplies an adjacency candidate, eligible paths are authenticated, and scoped route decisions participate in a selected trajectory.¶
3. A protocol profile authenticates the required principals and binds a session to the relationship context.¶
4. Authorized services exchange information through that session.¶
5. If a path, trajectory, carrier, or session fails, another realization can be established. The relationship continues only if its continuity rules are satisfied.¶
6. Revocation of the relationship authorization terminates its authority independently of whether old trajectories, route decisions, or sessions remain technically usable.¶

This sequence does not require a globally resolvable participant name. A selected profile can require a self-certifying identity, a provisioned trust anchor, a pseudonymous continuity key, or another explicitly specified mechanism.¶

9. Illustrative Use Cases

This section is non-normative. The examples illustrate consequences of the architecture and do not prescribe protocol mechanisms or deployment models.¶

10. Discovery, Routing, and Aggregation

Discovery produces candidates or information used to realize a relationship. It does not establish identity, trust, continuity, or authorization unless a separate authenticated procedure explicitly says so.¶

Routing constructs and maintains trajectories through scoped directional route decisions. A relationship can be direct or transit one or more forwarding participants. Transit does not grant an intermediary authority over endpoint identity or application authorization.¶

Aggregation is an optional scaling and privacy mechanism. Direct relationships remain architecturally valid. An aggregation profile MUST specify what an aggregator learns, which statements it authenticates, and which decisions remain reserved to endpoints. It MUST preserve the independent relationship, identity, continuity, and authorization boundaries defined by this architecture.¶

11. Relationship to Existing Network Architectures

PRP is independent of the Internet Protocol. It does not require IPv4, IPv6, or any other particular network-layer protocol. A PRP realization can operate over any compatible carrier capable of moving protocol units between adjacent participants.¶

An IP-based profile can use IP addresses, routing, and transport protocols as optional realization mechanisms. IPv6 continues to provide packet delivery as described in [RFC8200] when such a profile uses it. This does not make IP an architectural prerequisite, and possession of an IP address does not establish participant identity, relationship continuity, or authorization.¶

Transport protocols already separate some connection state from a particular path. For example, QUIC supports connection migration [RFC9000]. That continuity is transport-specific; PRP defines a relationship context that can outlive and authorize replacement of the complete transport session.¶

Other architectures separate endpoint identity from routing location. The Host Identity Protocol [RFC7401] introduces a host identity namespace, while the LISP architecture [RFC9299] separates endpoint identifiers from routing locators. PRP does not replace those mechanisms. It distinguishes both identity and locator from the relationship that determines continuity and authorization, and a PRP profile can use such mechanisms as realizations.¶

The architecture therefore does not claim that identity-locator separation, path migration, or authenticated sessions are new individually. Its contribution is the explicit relationship object and the invariants that prevent those replaceable mechanisms from becoming implicit sources of persistent authority.¶

12. Security Considerations

Relationship primacy does not itself provide cryptographic security. Every protocol profile MUST specify authenticated principals and transcript scope, confidentiality and integrity properties, replay domains, authorization inputs, selector and generation scopes, key and state lifetimes, exhaustion and amplification bounds, downgrade protection, and failure behavior.¶

A carrier-security claim does not imply end-to-end security. Adjacent authentication does not imply service authorization. A self-certifying identifier demonstrates control of key material but does not establish an external civil identity or authorize arbitrary services.¶

Continuity creates valuable long-lived state and is therefore a target for fixation, rollback, replay, and confused-deputy attacks. A replacement realization MUST be bound to the exact relationship, participants, direction, generation, and authorization policy required by its profile. State from one scope MUST NOT be admitted into another merely because identifiers or byte lengths coincide.¶

Unknown or malformed security-critical values MUST fail closed unless a specification defines a safe extension rule. Loss of continuity evidence MUST NOT be repaired by silently accepting reachability, a local handle, or unauthenticated forwarding state as equivalent authority.¶

Persistent relationships can increase the impact of compromised trust material. Profiles must define revocation, recovery, key replacement, and the point at which continuity can no longer be safely claimed. Denial-of-service protections must bound retained state, verification work, retries, referrals, and fanout per authenticated authority.¶

13. Privacy Considerations

Relationship-centric operation does not inherently provide anonymity, unlinkability, traffic-flow confidentiality, resistance to correlation, or availability. A stable relationship context can itself become a correlation surface even when routes, addresses, and session keys change.¶

Profiles MUST state which relationship identifiers, participant references, timing signals, path changes, and service metadata are visible to carriers, intermediaries, discovery services, and peers. Operational selectors should have the narrowest practical scope and lifetime. Implementations should avoid exposing durable relationship state where an ephemeral correlation is sufficient.¶

Padding, batching, multipath, private discovery, aliases, and cover traffic can reduce particular observations, but each requires separate analysis. No deployment should infer privacy properties merely from the absence of globally meaningful addresses or civil identities.¶

14. Operational Considerations

Relationship, trajectory, route-decision, path, session, and carrier state should be observable as distinct objects so that operators do not mistake path availability for relationship authorization. Diagnostics should identify scope and generation while avoiding disclosure of long-lived trust material or globally correlatable identifiers.¶

Implementations need explicit bounds for relationship state, candidate trajectories and paths, route decisions, concurrent sessions, retained replay information, and recovery attempts. Replacement should normally be make-before-break when the selected profiles can authenticate continuity, but an implementation must prefer loss of availability over an unauthorized continuity claim.¶

Interoperability depends on protocol profiles that instantiate this architecture. Architectural conformance alone does not imply wire compatibility.¶

15. Extensibility and Evolution

Extensions MUST preserve the invariants in this document. An extension that requires globally stable locators, equates routes with identity, or makes optional governance a universal prerequisite is not architecturally conforming.¶

Protocol versions and profiles MUST define explicit selection and failure behavior. Negotiation MUST NOT silently weaken authenticated properties or reinterpret assigned values. Migration SHOULD preserve relationship continuity through an authenticated make-before-break procedure when both profiles permit it.¶

16. Architectural Conformance

A design conforms to this architecture only if it:¶

1. treats a relationship as the primary persistent communication and authorization context;¶
2. defines continuity independently of any single trajectory, route, path, session, or carrier;¶
3. keeps operational routing and carrier selectors distinct from identity;¶
4. makes authorization an explicit relationship decision;¶
5. permits direct communication without mandatory global governance;¶
6. does not make IP or another particular network-layer protocol a universal prerequisite;¶
7. states the scope and lifetime of identities, sessions, trajectories, routes, paths, and selectors; and¶
8. does not claim security or privacy properties beyond those supplied by specified profiles.¶

Conformance to this architecture does not imply conformance to a particular wire protocol, discovery mechanism, routing protocol, carrier binding, or service profile.¶

17. IANA Considerations

This document has no IANA actions.¶

Appendix A. Acknowledgments

The author thanks the contributors and implementers whose independent protocol work exposed the architectural distinctions documented here. Specific reviewers will be acknowledged in subsequent revisions.¶

Author's Address