DTN Peering Protocol

1.1. Motivation

Two DPP speakers establish a session to exchange reachability information across administrative boundaries. Common scenarios include:¶

Inter-Agency Connectivity:

Two space agencies operate independent DTN infrastructures. DPP allows their border gateways to advertise which spacecraft and ground stations are reachable through each network, enabling bundles to flow between agencies.¶

Commercial-Government Integration:

A commercial satellite operator peers with a government science network. DPP enables the commercial network to advertise transit capacity to deep-space assets, while the science network advertises its spacecraft endpoints.¶

Redundant Path Discovery:

A Mars relay satellite is reachable via two ground station complexes. If both complexes belong to the same AD, DPP allows both paths to be advertised with appropriate metrics, enabling the network to prefer one path while maintaining the other as backup. If they belong to different ADs, each AD advertises its own path, and peers choose between them by local policy, estimated delivery time, and path length.¶

Scheduled Contact Windows:

Deep-space links are available only during planned contact windows. DPP's time-variant routing attributes allow DPP speakers to advertise future connectivity, enabling proactive bundle scheduling.¶

Independent Intra-Domain Routing:

DPP plays the role of an exterior gateway protocol: it carries routing information between ADs and leaves each AD free to choose how it routes bundles internally. One AD might use Contact Graph Routing (CGR), standardized by CCSDS as Schedule-Aware Bundle Routing (SABR) [CCSDS-SABR]; another might use static routes, or routes computed by its mission planning or network orchestration systems. DPP speakers advertise reachability derived from whatever their AD uses internally, and peers need neither know nor share that mechanism. This also avoids any need for a single contact plan spanning all agencies, spacecraft, and ground stations: each organization maintains its own mission planning systems and contact schedules, and the cost of contact-based routing grows with network size.¶

1.2. Design Principles

Transport:

Messages are defined using Protocol Buffers [PROTOBUF] and carried over gRPC [GRPC], and so over any transport that gRPC supports.¶

Both EID schemes:

Reachability is carried for both the ipn and dtn schemes, and routes for both are selected by the same process.¶

DNS-rooted identity:

ADs are identified by DNS domain names, and each AD uses its own DNS zone to authorize the speakers that act on its behalf.¶

Identity separate from reachability:

An AD's identity is independent of the nodes it advertises routes for.¶

1.3. Scope

This specification defines the protocol messages, state machine, and operational requirements for DPP implementations. It does not define:¶

• Routing within an Administrative Domain (e.g., CGR or static routing), which is chosen independently by each AD¶

• How a DPP speaker configures the gateways of its AD with the routes it has selected¶

• Bundle forwarding algorithms¶

• Policy languages for route filtering¶

2.1. Definitions

Administrative Domain (AD):

An autonomous unit of routing control identified by a DNS domain name. Examples include agency networks (e.g., dsn.example.org), commercial providers, or research institutions.¶

DPP Speaker:

An entity that participates in the DPP protocol, maintaining peering sessions with other DPP speakers and exchanging route information on behalf of an Administrative Domain. A DPP speaker may be a gateway, a centralized route controller, or any other system authorized to advertise and receive routes for its AD.¶

Gateway:

A bundle node within an Administrative Domain that forwards bundles to or from other ADs. A gateway may or may not also be a DPP speaker. A route names the gateway to which bundles should be sent (Section 7.9).¶

Session:

A connection between two DPP speakers over which routes are exchanged. The speaker that opens the connection is the Initiator; the other is the Responder. Once a session is established the roles are symmetric.¶

Route:

A statement, received over a session, that bundles for the nodes matching an EID pattern can be delivered via the advertising AD, together with the attributes of that statement. A speaker also holds routes that it originates for nodes within its own AD.¶

EID Pattern:

A pattern matching one or more Bundle Protocol [RFC9171] Endpoint Identifiers, as defined in [I-D.ietf-dtn-eid-pattern] and [I-D.taylor-dtn-eid-pattern-dtn].¶

AD_PATH:

The ordered list of Administrative Domains that a route has traversed, most recent first. The last entry is the originating AD. DPP is a path-vector protocol: AD_PATH is used to detect loops and to compare path lengths, as AS_PATH is in BGP.¶

Metric:

A numeric value set by the originating AD to express its preference among routes into its own network. It is analogous to BGP's Multi-Exit Discriminator, with the differences described in Section 8.4.¶

Local preference:

A preference that a speaker assigns to routes by local policy, for example by originating AD or by the peer from which they were learned. It is the first criterion of route selection after specificity (Section 8.5).¶

Transitive:

A flag carried with an attribute whose type the receiving speaker may not understand, telling such a speaker whether to propagate the attribute unchanged when it re-advertises the route, or to drop it (Section 7.5). It says nothing about how a speaker that does understand the attribute treats it.¶

Routing Information Base (RIB):

The set of routes a speaker holds, from all sessions and its own origination, from which it selects routes. This document does not prescribe how it is organized.¶

Forwarding Information Base (FIB):

The table used by a gateway to forward bundles. A speaker populates the FIBs of its AD's gateways from the routes it selects; how it does so is outside the scope of this document.¶

3.1. Administrative Domains

An Administrative Domain is an autonomous unit of routing control.¶

Identity:

An AD is identified solely by a DNS domain name (e.g., dsn.example.org). Wherever an AD identity appears in DPP, in a Hello, in AD_PATH, or in AD_SET, it is a fully qualified domain name without a trailing dot, with any internationalized labels in A-label form (Section 2.3.2.1 of [RFC5890]). Two AD identities are the same if they are equal under case-insensitive ASCII comparison.¶

Independence:

An AD Identity is distinct from the nodes it advertises. An AD named dsn.example.org may advertise ipn:100.*.* and dtn://rover1.example.org/**.¶

Advertising versus originating:

An AD that advertises a route is not necessarily the AD that originates it. An AD originates routes for the resources it serves, and may also re-advertise routes learned from other ADs, providing transit. The originating AD is identified by the last element of the route's AD_PATH (see Section 7.3).¶

3.2. DPP Speakers and Gateways

DPP speakers and gateways are defined in Section 2.1. A DPP speaker and a gateway MAY be the same node, but they need not be. For example, a centralized route controller may run DPP sessions on behalf of multiple gateways within its AD, naming the appropriate gateway in each route it advertises. This separation of the control plane (DPP) from the data plane (bundle forwarding) allows flexible deployment topologies.¶

An Administrative Domain MAY deploy multiple DPP speakers, each maintaining independent sessions with external ADs. Because loop detection operates on AD identity rather than on individual speaker identity, routes that leave an AD through one speaker and return through another are detected as loops (Section 7.3). Keeping the routes selected by an AD's several speakers consistent with one another, so that the AD's gateways forward coherently, is an intra-domain matter outside the scope of this document.¶

3.3. Deployment Model

DPP depends on DNS, which is not available on spacecraft and requires low-latency connectivity. This is compatible with deep-space deployment because of where the protocol's components sit:¶

DPP speakers are ground infrastructure.

DPP operates at administrative boundaries. DPP speakers are ground stations, mission control centers, network operations facilities, or centralized route controllers, all of which have Internet connectivity and can perform DNS lookups. Gateways, by contrast, are the forwarding nodes that handle bundle traffic and may be located anywhere, including on spacecraft or relay satellites, since they need neither DNS access nor direct participation in DPP.¶

DNS is used at session establishment only.

DPP performs DNS lookups only when establishing a session, to find a peer's DPP service and to retrieve the TLSA records that authorize the peer's key. Once a session is established, no further DNS queries are required, and the session is unaffected by the subsequent unavailability of DNS.¶

Spacecraft do not run DPP.

Spacecraft run the Bundle Protocol and may use CGR or static routing for their own forwarding decisions, under instructions from their ground-based mission operations, which participate in DPP on their behalf. Spacecraft and relay satellites MAY serve as gateways, forwarding bundles between ADs, without participating in DPP: a ground-based DPP speaker advertises routes on their behalf, naming the in-space node as the gateway.¶

As with BGP, the systems that run the routing protocol require connectivity that the systems they route for need not have.¶

4.1. DNS Records at _dpp

An AD publishes the records used by DPP at the owner name _dpp.<AD-Domain>. The _dpp label is specific to this protocol: the records it holds authorize and locate DPP speakers, and do not describe DTN nodes or convergence layers in general.¶

The zone containing these records MUST be signed with DNSSEC [RFC9364].¶

_dpp.<AD-Domain>.  IN  TLSA  <usage> <selector> <mtype> <data>

_dpp.dsn.example.org.  IN  TLSA  3 1 1 (
    8f3a5e...c2 )

_dpp.dsn.example.org.  IN  SVCB  1 speaker.dsn.example.org.
_dpp.dsn.example.org.  IN  SVCB  2 backup.dsn.example.org. port=4600

; Speakers accepting incoming sessions, on the default port
_dpp.dsn.example.org.  IN  SVCB  1 gds.dsn.example.org.
_dpp.dsn.example.org.  IN  SVCB  2 cbr.dsn.example.org.

; Keys authorized to act for dsn.example.org
_dpp.dsn.example.org.  IN  TLSA  3 1 1 (
    8f3a5e...c2 )   ; Goldstone
_dpp.dsn.example.org.  IN  TLSA  3 1 1 (
    51d07b...9e )   ; Canberra
_dpp.dsn.example.org.  IN  TLSA  3 1 1 (
    a7e214...41 )   ; Delegated operator (initiates only)

4.2. Session Establishment and Authentication

A DPP session is established as follows:¶

1. TLS: The Initiator opens a TLS connection to the Responder. Both speakers MUST use TLS 1.3 [RFC8446] or later, and both MUST present a certificate: the Responder MUST request a certificate from the Initiator, and MUST abort the connection if none is provided. The Responder does not learn which AD the Initiator claims to represent until it receives the Initiator's Hello, so it accepts the Initiator's certificate provisionally and completes its verification in step 5.¶

2. Hello: Once the gRPC stream is established, each speaker MUST send a Hello message, containing its local_ad_id, as its first message on the stream. A speaker need not wait for its peer's Hello before sending its own.¶

3. Peer check: On receiving the peer's Hello, the Initiator MUST reject the session if the local_ad_id it contains is not the AD to which the Initiator intended to connect. The Responder MUST reject the session if the local_ad_id is not an AD with which it is configured to peer. AD identities are compared as described in Section 3.1; a local_ad_id that is not a valid domain name in that form is treated as not matching. Performing this check before the DNS lookup prevents an unauthenticated peer from causing lookups of arbitrary names. Either speaker MUST also reject the session if the version in the peer's Hello is not one it supports, or if the peer's hold_time_seconds is unacceptable (Section 5.2).¶

4. Lookup: The speaker MUST query DNS for TLSA records at _dpp.<local_ad_id>, where local_ad_id is the AD named in the peer's Hello. The TLSA RRset MUST be validated as secure using DNSSEC. The speaker MUST either perform DNSSEC validation itself, or obtain the validation result from a validating resolver that it trusts and that it reaches over a channel protected from modification, as described in Section 4.9.3 of [RFC4035]; an AD bit received over an unprotected channel MUST NOT be relied on. If the validation state is insecure, indeterminate, or bogus, or the RRset contains no usable records (Section 4.1 of [RFC6698]), the speaker MUST reject the session.¶

5. Verification: The certificate that the peer presented in the TLS handshake MUST match at least one usable TLSA record, using the DANE-EE matching rules of Section 5.1 of [RFC7671]. If none matches, the speaker MUST reject the session.¶

A speaker that rejects a session SHOULD send a Notification with an appropriate error code before closing the stream. From each speaker's point of view, the session is ESTABLISHED once it has both sent its own Hello and verified its peer's. A speaker MUST NOT send RouteUpdate messages before then.¶

Because the Initiator knows which AD it is connecting to, it MAY perform steps 4 and 5 for the Responder during the TLS handshake itself, and so avoid sending its Hello to an unauthorized peer.¶

DNS is consulted only during session establishment, and an established session is not affected by the subsequent unavailability of DNS. A speaker MAY periodically repeat steps 4 and 5 for an established session, and terminate the session if the peer's key is no longer authorized. A lookup failure during such a check MUST NOT by itself cause the session to be terminated.¶

5.1. States

Both speakers run the same state machine. The steps referred to are those of Section 4.2.¶

A Notification MAY be sent and received in any state.¶

A speaker MUST move to CLOSING, sending the Notification code shown, if:¶

• any step of Section 4.2 fails (UNSUPPORTED_VERSION, UNEXPECTED_AD, AUTHORIZATION_FAILED, or UNACCEPTABLE_HOLD_TIME, as appropriate);¶

• it receives any message other than Hello or Notification before reaching ESTABLISHED, or a second Hello on the same stream (UNEXPECTED_MESSAGE);¶

• the session does not reach ESTABLISHED within a locally configured time (UNSPECIFIED);¶

• the hold timer expires (Section 5.2; HOLD_TIMER_EXPIRED);¶

• it receives more routes from the peer than it will accept (Section 10.4; MAX_ROUTES_EXCEEDED); or¶

• it decides to close the session for any other reason (CEASE, or CONNECTION_COLLISION in the case of Section 5.4).¶

A speaker MUST also move to CLOSING, without sending a Notification, if it receives a Notification whose code ends the session (Section 6.7), or if the gRPC stream is closed by the peer or fails.¶

In the ESTABLISHED state, a speaker that receives a PeerMessage whose payload it does not recognize, or a Hello, SHOULD send a Notification with level WARNING and code UNEXPECTED_MESSAGE, and MUST otherwise ignore the message. A speaker MUST NOT send a message defined by an extension that is not in effect on the session (Section 6.3).¶

5.2. Hold Time and Keepalives

Each speaker proposes a hold time in the hold_time_seconds field of its Hello, which MUST be at least 3 seconds. A speaker that receives a Hello with a hold_time_seconds of less than 3 MUST reject the session with code UNACCEPTABLE_HOLD_TIME. The hold time for the session is the smaller of the two values.¶

In the ESTABLISHED state, a DPP speaker MUST send KeepAlive messages at intervals not exceeding one third of the session hold time. If a speaker receives no message from its peer for a period equal to the session hold time, it MUST move to CLOSING with code HOLD_TIMER_EXPIRED.¶

5.3. Initial Route Exchange

On entering ESTABLISHED, a speaker MUST send to its peer every route that it would advertise to that peer at that time (Section 9), followed by a RouteUpdate with initial_update_complete set. That RouteUpdate MAY also carry announcements or withdrawals. A speaker MUST send it even if it has no routes to advertise. The flag MUST NOT be set in any later RouteUpdate on the session, and a receiving speaker MUST ignore it if it is.¶

Until a speaker has received its peer's RouteUpdate with initial_update_complete set, or a locally configured time has elapsed since the session became ESTABLISHED, it SHOULD defer updating its own advertisements to other peers in response to routes received over the new session. Without this, each advertisement received during the initial exchange could change the speaker's selected routes, and so cause a separate update to every other peer. Routes received during the initial exchange MAY be used for forwarding as soon as they are received. This is analogous to the End-of-RIB marker of [RFC4724].¶

5.4. Multiple Sessions and Collisions

A speaker MAY hold sessions with several speakers of the same AD, and an AD's speakers MAY each hold sessions with the same peer; routes received over each session are independent (Section 7.7). Two sessions between the same pair of speakers, which can arise when each is configured to initiate a session to the other, are not harmful, but carry the same routes twice.¶

A speaker identifies a peer speaker by the public key that the peer presented in the TLS handshake (Section 4.2) together with the peer's speaker_id; speakers of one AD that share a key (Section 4.1.3) SHOULD therefore set distinct speaker_id values. When a speaker has two sessions with the same peer speaker, both of which are ESTABLISHED or being established, it SHOULD close one of them with code CONNECTION_COLLISION. So that both speakers close the same session, the session to close is the one initiated by the speaker whose public key has the numerically greater SHA-256 digest, with the digests compared as unsigned big-endian integers. A speaker MUST NOT close a session for this reason until the newer session is ESTABLISHED, so that a session is not lost to a connection attempt that fails.¶

5.5. Session Termination

A speaker that is ending a session, whether because of an error or by choice, MUST send a Notification whose code describes the reason before closing the gRPC stream, if it is able to; CEASE is used for an orderly close with no other cause. It MUST then close the stream. It SHOULD log the reason.¶

A session has ended, from a speaker's point of view, when it has sent or received a Notification whose code ends the session, or when the gRPC stream has been closed by the peer or has failed. When a session ends, the speaker MUST remove all routes received over it (Section 7.7), repeat route selection, and update its advertisements to other peers (Section 9).¶

This document defines no means of preserving routes across a session failure, such as the graceful restart mechanism of BGP [RFC4724], nor of asking a peer to re-send its routes without re-establishing the session. A transient transport failure therefore removes every route learned over the session, including those for contact windows far in the future, until a new session is established and the initial route exchange repeated. Speakers on links prone to interruption SHOULD set hold times accordingly. A mechanism for retaining routes across a brief interruption may be the subject of a future extension.¶

An Initiator whose session has ended MAY establish a new one. It SHOULD wait before doing so, for an interval that increases with each successive failure to establish or keep a session with the same peer, so that a persistently failing peer is not retried continuously; it MAY reconnect promptly after an orderly CEASE.¶

6.1. Service Definition

syntax = "proto3";
package dtn.peering.v1;

import "google/protobuf/timestamp.proto";

service DtnPeering {
  // Single stream for Hello, Routes, and Keepalives
  rpc Peer(stream PeerMessage) returns (stream PeerMessage);
}

6.2. Message Envelope

message PeerMessage {
  oneof payload {
    Hello hello = 1;
    KeepAlive keep_alive = 2;
    RouteUpdate update = 3;
    Notification notification = 4;
  }
}

6.3. Identity Message

message Hello {
  // Protocol version; 1 for this document
  uint32 version = 1;
  // DNS Domain (e.g., "dsn.example.org")
  string local_ad_id = 2;
  uint32 hold_time_seconds = 3;
  // Optional protocol extensions supported by the sender
  repeated string capabilities = 4;
  // Optional, free-form (e.g., "goldstone-1")
  string speaker_id = 5;
}

The version field identifies the version of this protocol that the sender implements. This document defines version 1. A speaker MUST set version to the highest version it supports, and MUST reject a session if the version in its peer's Hello is not one that it supports (Section 4.2). A Hello in which version is absent has version 0, which is not valid.¶

The capabilities field lists optional extensions to this protocol that the sender supports, by the names registered for them (Section 11.3); this document defines none. An extension is in effect on a session only if both speakers listed it. A speaker MUST ignore capability names that it does not recognize, and MUST NOT send any message or attribute defined by an extension that is not in effect.¶

The optional speaker_id field allows a speaker to identify itself among the speakers of its AD, for example in logs and diagnostics, and to distinguish itself from other speakers of its AD that present the same key (Section 5.4). Its content is chosen by the AD and has no defined format; in particular, it need not be an EID or a DNS name, since a DPP speaker need not be a BP node. A receiving speaker MUST NOT use speaker_id for authentication, authorization, loop detection, or route selection.¶

Authentication is performed by TLS (see Section 4.2), so no authentication messages are defined.¶

6.4. Routing Messages

The semantics of these messages are specified in Section 7.¶

message RouteUpdate {
  repeated RouteAdvertisement announcements = 1;
  repeated RouteWithdrawal withdrawals = 2;
  // Set once per session, on the last message of the
  // initial route exchange (see Initial Route Exchange)
  bool initial_update_complete = 3;
}

// One or more routes sharing the same attributes
message RouteAdvertisement {
  // Advertisement ID: identifies this advertisement within the
  // session; re-sending the same id replaces the advertisement
  uint64 id = 1;

  // Destination nodes; each pattern creates a route
  repeated EidPattern patterns = 2;

  // Required attributes
  // AD Domains traversed, most recent first
  repeated string ad_path = 3;
  // Originating AD's preference (lower = preferred)
  uint32 metric = 4;

  // Optional attributes
  repeated RouteAttribute attributes = 5;
}

// Removes all routes created by the advertisements with the
// listed advertisement IDs
message RouteWithdrawal {
  repeated uint64 advertisement_ids = 1;
}

6.5. Route Attributes

The semantics of each attribute are specified in Section 7.¶

// Optional route attribute; see Optional Attributes. The field
// number of each typed member is the attribute's registered type.
message RouteAttribute {
  oneof attribute {
    // Bundle forwarding endpoint, for data plane separation
    string gateway_eid = 1;

    // Time window: when the advertising AD starts and stops
    // accepting bundles
    google.protobuf.Timestamp valid_from = 2;
    google.protobuf.Timestamp valid_until = 3;

    // What the advertising AD accepts
    uint64 bandwidth_bps = 4;     // Rate (bits per second)
    uint32 max_bundle_size = 5;   // Maximum bundle size (bytes)

    // Estimated earliest delivery time at the destination
    google.protobuf.Timestamp arrival_time = 6;

    // Aggregated AD_PATH members; see Aggregation
    AdSet ad_set = 7;

    // An attribute carried by type number rather than as a
    // typed member; see Attribute Types and Forward
    // Compatibility
    UnknownAttribute unknown = 65535;
  }
}

message UnknownAttribute {
  uint32 type_id = 1;   // Registered attribute type
  bytes value = 2;      // Encoding defined for the type
  bool transitive = 3;  // Propagate even if not understood
}

// Unordered set of AD identities; see Aggregation
message AdSet {
  repeated string ad_ids = 1;
}

The value of an UnknownAttribute carrying one of the attribute types defined in this document is the Protocol Buffers encoding of the typed member's value: for gateway_eid, the UTF-8 string; for valid_from, valid_until, and arrival_time, the serialized google.protobuf.Timestamp; for bandwidth_bps and max_bundle_size, the varint; and for ad_set, the serialized AdSet.¶

6.6. Data Types

message EidPattern {
  oneof scheme {
    IpnPattern ipn = 1;
    DtnPattern dtn = 2;
  }
}

// Matches every Service Number of the nodes it identifies.
// An unset component is a wildcard; ipn:** has both unset.
message IpnPattern {
  IpnComponent allocator = 1;
  IpnComponent node = 2;
}

message IpnComponent {
  oneof value {
    uint32 exact = 1;
    IpnRange range = 2;
  }
}

// Aligned power-of-two range of size > 1 (inclusive bounds)
message IpnRange {
  uint32 min = 1;
  uint32 max = 2;
}

// Matches every demux of the nodes it identifies. The authority
// is in the text form of the dtn EID Pattern specification.
message DtnPattern {
  string authority = 1;  // e.g. "*.example.org"
}

6.7. Control Messages

message KeepAlive {}

message Notification {
  enum Level { INFO = 0; WARNING = 1; ERROR = 2; }
  enum Code {
    UNSPECIFIED = 0;
    // Session establishment
    UNSUPPORTED_VERSION = 1;
    UNEXPECTED_AD = 2;
    AUTHORIZATION_FAILED = 3;
    UNACCEPTABLE_HOLD_TIME = 4;
    // Session operation
    HOLD_TIMER_EXPIRED = 5;
    UNEXPECTED_MESSAGE = 6;
    MALFORMED_UPDATE = 7;
    MAX_ROUTES_EXCEEDED = 8;
    // Orderly close
    CEASE = 9;
    CONNECTION_COLLISION = 10;
  }
  Level level = 1;
  // Human-readable detail; not for machine interpretation
  string message = 2;
  Code code = 3;
}

A Notification reports a condition to the peer. It MAY be sent in any state, including before a Hello. The level indicates severity for logging and diagnostics. The code identifies the condition, and determines whether the sender is ending the session:¶

A speaker that receives a Notification whose code ends the session MUST treat the session as ended (Section 5.5). A speaker that receives any other Notification MUST NOT end the session on that account. The message field carries human-readable detail, such as which advertisement was malformed; a speaker MUST NOT depend on its content. Codes are registered in the "DPP Notification Codes" registry (Section 11.2).¶

7.1. Advertisement Structure

A RouteAdvertisement (Section 6.4) carries:¶

Advertisement ID:

An id that identifies the advertisement within the session, so that it can later be replaced or withdrawn (Section 7.7).¶

Patterns:

One or more EID patterns identifying the destination nodes, constrained as described in Section 8.2. Each pattern creates a separate route; all share the advertisement's attributes.¶

Attributes:

The properties of the route. Two are always present, ad_path and metric; the rest are optional and are carried in an extensible list.¶

7.2. Required Attributes

7.3. Loop Detection

DPP is a path-vector protocol: routing loops are prevented using the AD_PATH attribute (similar to BGP's AS_PATH [RFC4271]). Loop detection operates on Administrative Domain identity, not on individual DPP speaker identity. This means an AD MAY deploy multiple speakers without risk of routing loops, as all speakers within an AD share the same local_ad_id.¶

Mechanism:

Every route advertisement MUST include the ordered list of ADs it has traversed.¶

Propagation:

When a DPP speaker advertises a route to a peer, it MUST prepend its own local_ad_id to the AD_PATH. This applies both to routes it originates (which therefore carry an AD_PATH containing only the originating AD) and to routes it re-advertises.¶

Verification:

When a DPP speaker receives a route advertisement, the first (left-most) entry in AD_PATH MUST match the local_ad_id that the peer authenticated during session establishment (Section 4.2). If it does not, or if AD_PATH is empty, the advertisement is malformed (Section 7.8). This prevents a peer from omitting its own AD from the path, or from presenting a route as though it had been received directly from another AD.¶

Detection:

If a DPP speaker receives an advertisement whose AD_PATH, or whose AD_SET attribute if present (Section 9.1), contains its own local_ad_id, it MUST NOT create routes from it; the advertisement is treated as a withdrawal of its ID (Section 7.8).¶

AD identities in AD_PATH and AD_SET are compared as described in Section 3.1.¶

7.4. Optional Attributes

Optional attributes, each carried as a RouteAttribute (Section 6.5):¶

How each attribute is updated when a route is re-advertised is specified in Section 9.¶

7.5. Attribute Types and Forward Compatibility

Every route attribute has a type, identified by a number in the "DPP Route Attribute Types" registry (Section 11.4). Each registered type records the protocol version (Section 6.3) that introduced it and the document that defines it. The attributes defined in this document are all introduced in version 1.¶

A RouteAttribute (Section 6.5) carries an attribute in one of two forms: as the typed member of the attribute choice defined for its type, or as an UnknownAttribute, which carries the type number, the attribute's value as an opaque byte string, and a transitive flag that tells a speaker which does not understand the type what to do with it. A sender MUST choose the form as follows:¶

• An attribute whose type was introduced in a version that the peer supports (that is, not later than the version in the peer's Hello) MUST be sent in its typed form.¶

• An attribute whose type was introduced in a later version than the peer supports MUST be sent as an UnknownAttribute. Its value is the encoding specified for that type in the document that defines it.¶

• An attribute whose type is in the Private Use range of the registry MUST always be sent as an UnknownAttribute.¶

The second rule is what makes it possible for a speaker running an older version to carry a transitive attribute defined by a newer one: because Protocol Buffers does not deliver an unrecognized oneof member to the application, a newer typed member would otherwise be silently lost at the first older speaker on the path. The first rule is what allows speakers running the same version to use the typed, more compact and more convenient form between themselves.¶

A receiving speaker MUST handle an UnknownAttribute as follows:¶

1. If it recognizes the type, it MUST decode the value as specified for that type and process the attribute exactly as if it had been received in typed form.¶

2. If it does not recognize the type and transitive is true, it MUST preserve the attribute and propagate it, unchanged, as an UnknownAttribute when re-advertising the route.¶

3. If it does not recognize the type and transitive is false, it MUST discard the attribute and not propagate it.¶

The transitive flag exists only in UnknownAttribute form, and is meaningful only to a speaker that does not understand the attribute's type: it is all that such a speaker can know about the attribute. A speaker that does understand the type MUST handle the attribute as the document defining the type specifies, in particular when re-advertising a route (Section 9), whether the attribute arrived in typed or UnknownAttribute form; and when it sends the attribute in UnknownAttribute form it MUST set the flag as that document specifies. For a Private Use type, the party using it chooses the flag. The flag is deliberately not recorded in the registry: knowing whether an attribute may be passed on unexamined is no substitute for knowing how it is to be processed, and for every attribute defined in this document except ad_set the correct behavior on re-advertisement is to replace or recompute the value, not to propagate it. A document that defines a new attribute type MUST specify its typed RouteAttribute member, the encoding of its value in UnknownAttribute form, the value of its transitive flag, and how a speaker that understands it treats it when a route is re-advertised.¶

7.6. Time-Variant Routing

All times carried in DPP are absolute, and are compared across ADs. DPP speakers MUST therefore keep their clocks synchronized to UTC, for example using NTP. The time windows that DPP describes are typically measured in minutes or hours, so the accuracy that ordinary network time synchronization provides is sufficient; this document defines no tolerance for clock skew, and two times are equal only if they are identical.¶

The valid_from and valid_until attributes allow an AD to advertise reachability that is available only at certain times, as is common in deep-space networks. Together they define the time window during which the advertising AD will accept bundles for the advertised destinations. A receiving AD can use these time windows as input to its own routing, whether that is contact-based (e.g., [CCSDS-SABR]) or not. Routes without these attributes are valid immediately and remain valid until explicitly withdrawn.¶

Because DTN is a store-and-forward network, the window in which an AD accepts bundles need not coincide with the contacts over which it will forward them. An AD with sufficient storage can accept bundles before its next contact towards their destination opens, and hold them until it does; it can also offer a single window that spans several such contacts.¶

A route is available from the time given by its valid_from attribute. A route with no valid_from attribute, or whose valid_from time has passed, is available immediately. A route expires at the time given by its valid_until attribute: once that time has passed, a DPP speaker MUST treat the route as withdrawn. An advertisement that carries both attributes with a valid_until time not later than its valid_from time is malformed (Section 7.8).¶

The optional arrival_time attribute gives the advertising AD's estimate of the earliest time at which a bundle that it accepts at the start of the route's window can be delivered to the advertised destinations. Unlike the time window, which describes only the advertising AD, the arrival time describes the whole path to the destination. It is set by the originating AD, if that AD can estimate when it will deliver bundles, and is updated by each AD that re-advertises the route (Section 9). A route without an arrival_time attribute provides no estimate.¶

An advertisement that carries both an arrival_time and a valid_from, with the arrival_time earlier than the valid_from, is malformed (Section 7.8): a bundle cannot be delivered before it is accepted.¶

Because the availability of routes changes over time, a DPP speaker MUST repeat route selection (Section 8.5) for the current time whenever any of the following occurs, and MUST update its own advertisements if the routes that it would advertise change (Section 9):¶

• it receives, replaces, withdraws, or loses a route;¶

• the valid_from time of a route it holds is reached, making the route available;¶

• the arrival_time of a route it holds is reached, after which the route is estimated to deliver bundles as soon as they are accepted (Section 8.5); or¶

• the valid_until time of a route it holds is reached, expiring the route.¶

A peer MAY send multiple advertisements for the same pattern, each with its own advertisement ID (Section 7.7), to describe a series of distinct periods in which it accepts bundles, each with its own attributes.¶

7.7. Advertisement IDs and Withdrawal

Each RouteAdvertisement carries an advertisement ID, in its id field, chosen by the sending speaker, that identifies the advertisement within the session over which it is sent. Each EID pattern in the advertisement creates a separate route, which has the advertisement's attributes; the routes created by an advertisement are identified by the session, the advertisement ID, and their patterns. The ID identifies the advertisement as a whole, not any one of the routes it creates.¶

An advertisement ID is meaningful only within the session in which it is used. A speaker MAY choose advertisement IDs in any way, provided that it does not use the same value for two advertisements that it intends to be held at the same time on the same session. When a session ends, all routes received over it are removed, and the advertisement IDs used in it have no significance in any later session.¶

When a DPP speaker receives a route advertisement, it MUST replace all of the routes previously received over the same session with the same advertisement ID, if any, with the routes created by the new advertisement. The replacement is atomic: the new advertisement's patterns, attributes, and time window take effect together, and any pattern that was in the previous advertisement but is not in the new one is removed. This allows a peer to change any aspect of an advertisement, including its time window, by re-sending it with the same advertisement ID, without first withdrawing it.¶

Advertisements with different advertisement IDs are independent, even if they contain the same pattern and their time windows overlap. A speaker can therefore hold several routes for the same pattern from a single peer, for example when a centralized route controller advertises several entry points into its AD, each with a different gateway_eid and metric (Section 7.9). Route selection chooses between them in the same way as between routes from different peers (Section 8.5).¶

A RouteWithdrawal lists, in its advertisement_ids field, the IDs of advertisements to be removed. For each ID that it lists, all routes received over the same session from the advertisement with that ID are removed. If no advertisement with that ID is held, the ID is silently ignored. A peer that wishes to remove only some of the patterns in an advertisement re-sends the advertisement with the same ID, omitting those patterns.¶

A route also ceases to exist when it expires (Section 7.6), and does not need to be withdrawn. When every route created by an advertisement has expired, its advertisement ID is no longer in use.¶

7.8. Malformed Advertisements and Processing Order

A RouteAdvertisement is malformed if any of the following holds:¶

• it contains no patterns;¶

• a pattern does not satisfy the constraints of Section 8.2, including the range constraints of Section 8.2.1, or a dtn pattern has an empty authority;¶

• its AD_PATH is empty, or the first entry of its AD_PATH does not match the AD that the peer authenticated during session establishment (Section 7.3);¶

• it carries more than one attribute of the same type, whether in typed or UnknownAttribute form, or an UnknownAttribute whose type_id is 0, 65535, or that of a typed member the peer's version supports (Section 7.5);¶

• it carries both valid_from and valid_until, and valid_until is not later than valid_from (Section 7.6);¶

• it carries both valid_from and arrival_time, and arrival_time is earlier than valid_from (Section 7.6);¶

• its gateway_eid is not the administrative endpoint EID of a node, or is a LocalNode EID (Section 7.9); or¶

• its bandwidth_bps or max_bundle_size is zero; or¶

• its ad_set is empty, or contains an AD that also appears in its AD_PATH.¶

A pattern whose scheme the receiving speaker does not recognize (that is, an EidPattern in which no known scheme is set) is not malformed: the speaker MUST ignore that pattern and process the remainder of the advertisement. This allows patterns for additional schemes to be defined in future. If ignoring such patterns leaves an advertisement with no patterns, the advertisement is treated as a withdrawal of its ID, without notification.¶

A receiving speaker MUST treat a malformed advertisement as a withdrawal of its advertisement ID: any routes previously received over the session with that ID are removed, and no routes are created. The speaker SHOULD send a Notification with level WARNING and code MALFORMED_UPDATE, identifying the advertisement in the message field, and MUST NOT end the session on account of a malformed advertisement. This follows the approach of [RFC7606] for BGP: ending the session would remove every route received over it, which is a far greater disruption than the loss of the one advertisement, and would make a peer's single error into an outage.¶

An advertisement whose AD_PATH contains the receiving speaker's own AD (Section 7.3) is likewise treated as a withdrawal of its ID, but without a Notification, since receiving one's own routes back is a normal occurrence in a meshed topology.¶

Within a single RouteUpdate, a receiving speaker MUST process the withdrawals before the announcements, and the announcements in the order in which they appear. Consequently, if an advertisement ID appears both in the withdrawals and in an announcement, the announcement takes effect; and if two announcements carry the same ID, the second replaces the first. Senders SHOULD NOT construct such messages.¶

A PeerMessage that cannot be decoded, or that contains a RouteUpdate before the session is ESTABLISHED, is handled as described in Section 5.1.¶

7.9. Gateway EID Resolution

The gateway_eid attribute identifies the gateway node to which bundles matching the advertised patterns should be forwarded. This enables separation of the control plane (DPP session) from the data plane (bundle forwarding).¶

The gateway EID always identifies a gateway in the AD that sent the advertisement, which is the next hop for matching bundles, not a gateway in the originating AD. A speaker that re-advertises a route therefore replaces the gateway EID with one of its own (Section 9).¶

A gateway_eid MUST be the EID of the gateway node's administrative endpoint (Section 4.2.5.2 of [RFC9171]): for the ipn scheme, ipn:A.N.0, the EID with Service Number zero for the node's FQNN (Section 5.7 of [RFC9758]); for the dtn scheme, dtn://<node-name>/, the EID with a zero-length demux (Section 4.2.5.1.1 of [RFC9171]). Any singleton EID of a node may serve as a node ID for it, but the administrative endpoint EID is the one such EID that every speaker will form in the same way, so requiring it ensures that two routes via the same gateway name it identically. An advertisement whose gateway_eid is not of this form, or is a LocalNode EID (Section 5.4 of [RFC9758]), is malformed (Section 7.8). A gateway_eid SHOULD use the same scheme as the route's patterns, since the receiving AD must find a convergence layer path to the gateway using the EID given.¶

Resolution rules:¶

1. If a gateway_eid attribute is present, forward matching bundles to the node it identifies.¶

2. If gateway_eid is absent, derive the gateway EID from the peer's AD identity (local_ad_id from Hello) by forming the administrative endpoint EID of a dtn node whose node-name is the AD's domain name:¶

   <dns_name>  ->  dtn://<dns_name>/
   

   ¶

   For example: dsn.example.org -> dtn://dsn.example.org/¶

   This default assumes that the AD operates a gateway node whose dtn node-name is the AD's own domain name. An AD for which that is not the case MUST include an explicit gateway_eid.¶

No mapping from a domain name to an ipn FQNN is defined: the ipn.arpa zone proposed in [I-D.ek-dtn-ipn-arpa] maps an FQNN to the records needed to reach the node, but does not map a domain name to an FQNN. An AD whose gateways have only ipn EIDs therefore needs to include an explicit gateway_eid attribute.¶

Determining how to reach a gateway at the convergence layer, once its EID is known, is a function of the receiving AD's BP agents rather than of DPP, and can use any available means, including configuration. For a gateway with an ipn EID, [I-D.ek-dtn-ipn-arpa] specifies a DNS-based procedure: for example, TCPCLv4 [RFC9174] endpoints for the node (978879,2) are found from SRV records at _dtn-bundle._tcp.2.978879.ipn.arpa.. No corresponding procedure is currently specified for gateways with dtn EIDs.¶

This allows the following deployments:¶

DNS-named gateway:

An AD with identity dsn.example.org that operates a gateway node named dtn://dsn.example.org/ need not include a gateway_eid. Since no DNS-based procedure is currently specified for discovering the convergence layer endpoints of a dtn node, the receiving AD must be configured with how to reach that gateway; the default saves the attribute, not the configuration.¶

Separated control plane:

A DPP speaker that is not itself a gateway (e.g., a centralized route controller) can advertise routes with explicit gateway_eid pointing to the forwarding nodes within the AD, enabling load distribution or failover.¶

Load distribution:

Multiple routes to the same destination can be advertised with different gateway_eid values and metrics.¶

Examples:¶

# AD identity is DNS name - gateway_eid derived automatically
AD Identity: dsn.example.org
Default Gateway EID: dtn://dsn.example.org/

RouteAdvertisement {
  patterns: [ipn:100.*.*]
  ad_path: ["dsn.example.org"]
  metric: 10
  // No gateway_eid needed - defaults to dtn://dsn.example.org/
}

# Explicit gateway_eid for control/data plane separation
AD Identity: dsn.example.org

RouteAdvertisement {
  patterns: [ipn:100.*.*]
  ad_path: ["dsn.example.org"]
  metric: 10
  attributes: [
    gateway_eid: "dtn://ingress1.dsn.example.org/"
  ]
}

8.1. Routes Identify Nodes

DPP advertises the reachability of bundle nodes, not of the services registered at them. A bundle is forwarded to the node that is the sole member of its destination endpoint; the service or demux component of the destination EID selects an application at that node, after forwarding is complete, and plays no part in it. Routes therefore match nodes:¶

• For the ipn scheme, a node is identified by its Fully Qualified Node Number (FQNN), the Allocator Identifier and Node Number together. All ipn EIDs that share an FQNN refer to the same node (Section 5.1 of [RFC9758]), so an ipn route pattern specifies Allocator Identifiers and Node Numbers only, and matches every Service Number.¶

• For the dtn scheme, a node is identified by the node-name in the authority of its EIDs (Section 4.2.5.1.1 of [RFC9171]), so a dtn route pattern specifies an authority only, and matches every demux.¶

In the text form of [I-D.ietf-dtn-eid-pattern], an ipn route pattern always ends in .* (any Service Number), and a dtn route pattern always ends in /** (any demux). The protocol encoding (Section 6.6) omits these components, since they carry no information.¶

Whether a particular service is offered at a node, and whether a gateway will accept bundles for it, are matters of application registration and of local policy at the receiving AD, not of reachability, and are outside the scope of DPP.¶

A node may have EIDs in more than one scheme, for example an ipn EID and a dtn EID. The Bundle Protocol does not define any relationship between such EIDs, and nor does DPP: routes for the two schemes are independent, and a bundle is forwarded using routes for the scheme of its destination EID. Only routes for singleton endpoints are advertised; non-singleton endpoints (Section 4.2.5.1.1 of [RFC9171]) are outside the scope of this document.¶

8.2. EID Pattern Constraints (Monotonic Specificity)

Route patterns are EID Patterns: ipn patterns as defined in [I-D.ietf-dtn-eid-pattern], and dtn patterns as defined in [I-D.taylor-dtn-eid-pattern-dtn], which supplies the scheme-specific dtn pattern that [I-D.ietf-dtn-eid-pattern] leaves to be defined by other documents. To keep specificity comparison and longest-match lookup well-defined, DPP restricts both to a Strict Monotonic Subset.¶

A pattern exhibits monotonic specificity if all wildcard components are confined to the logical "leaves" of the naming hierarchy. A specific child component cannot exist under a wildcard parent. Equivalently, when a pattern is read in hierarchy order, the wildcard (if present) MUST be the terminal element: no specific component, label, or character may follow it. This is what guarantees that any two patterns matching the same EID are nested, keeping both specificity comparison and longest-prefix lookup well-defined.¶

8.3. Specificity Scoring

The specificity score prioritizes Exact Matches over Wildcards, and Longer Prefixes over Shorter Prefixes.¶

• The specificity score is computed locally by the receiver from the EidPattern. It is NOT transmitted in route advertisements, as it can be deterministically derived from the pattern itself.¶

The score is calculated as a uint32:¶

Score = (IsExact x 256) + LiteralLength

IsExact (0 or 1):

1 if the pattern identifies exactly one node, i.e., its Allocator Identifier and Node Number (ipn) or its authority (dtn) contain no wildcard or range; 0 otherwise.¶

Multiplier (256):

A weight ensuring a pattern for a single node outranks any wildcard pattern matching that node. For ipn patterns the maximum LiteralLength is 64 (2 x 32 bits), which is well below 256. For dtn patterns LiteralLength can exceed 256, but a single-node pattern always has at least as many literal characters as any wildcard pattern that matches the same node, so the ordering is preserved.¶

LiteralLength:

The count of non-wildcard characters (or equivalent bits for integers).¶

LiteralLength = Bits_Allocator + Bits_Node

8.4. The Metric Field

The metric field in route advertisements is analogous to BGP's Multi-Exit Discriminator (MED) [RFC4271]. It allows an Administrative Domain to express a preference for how traffic should enter its network when multiple paths exist.¶

For example:¶

Organization B has two DPP speakers peering with Organization A:
  - Speaker in Europe  (gateway with high latency to Mars relay)
  - Speaker in Australia (gateway with low latency to Mars relay)

Organization B advertises routes to ipn:200.*.* via both speakers:
  - Europe speaker:    metric = 100
  - Australia speaker: metric = 10

Organization A, having learned the same route from both peers,
prefers the lower metric and routes traffic via Australia.

If Organization A instead learns the Australia route only
indirectly, via a third AD, it still prefers Australia over the
direct Europe route: both routes originate in Organization B, and
once Organization B has been chosen as the destination AD, its
metric is applied regardless of AD_PATH length.

The metric is set by the originating AD and propagated unchanged through intermediate ADs: a DPP speaker that re-advertises a route MUST NOT modify its metric. It lets an AD steer incoming traffic without coordination with other ADs.¶

The metric expresses the originating AD's preference between ways into its own network. It does not express a preference between different originating ADs, and is not used to choose between them (see Section 8.5).¶

This is a notable departure from the BGP MED, which is non-transitive: a MED received from a neighboring AS is not propagated to other neighboring ASes, and MEDs are compared only between routes received from the same neighboring AS (Section 5.1.4 of [RFC4271] and Section 9.1.2.2 of [RFC4271]; see also [RFC4451]). The DPP metric is transitive, and is compared between routes with the same originating AD, regardless of the neighbor from which they were learned.¶

8.5. Route Selection Algorithm

When a DPP speaker has multiple routes whose patterns match the same EID, it MUST select the best path in two stages: it first chooses the originating AD (the last entry in AD_PATH) to which bundles for that EID will be sent, and then chooses among the routes to that AD. The process is specified as a sequence of steps for clarity; an implementation MAY compute the result by any means that produces the same outcome. The reasons for the order of the steps are given in Appendix B.¶

Routes that a speaker originates for nodes within its own AD take part in selection alongside routes received from peers. For this purpose an originated route has an AD_PATH containing only the speaker's own AD, the metric and other attributes that the speaker would advertise for it, and is available from when it is configured.¶

A pattern may legitimately be originated by more than one AD. For example, a spacecraft may be reachable through the ground stations of several agencies, each of which originates routes to it. This is expected in DTN, and the selection process is designed for it.¶

Route selection is performed for a time t: the time at which a bundle is, or would be, accepted. A speaker forwarding a bundle that it holds selects a route for the current time; a speaker deciding what to re-advertise selects routes for each time within the windows that it advertises (Section 9). Only routes that have not expired by time t are considered, including routes that are not yet available at time t: in a store-and-forward network, a bundle accepted at time t can be held until such a route becomes available. A route is available at time t if it has no valid_from attribute, or its valid_from time is not later than t. The outcome of selection for the current time changes only at the events listed in Section 7.6, and a speaker needs to repeat selection only when one of them occurs.¶

Stage 1, choosing the originating AD:¶

1. Specificity: Keep only the routes with the highest Specificity Score (Section 8.3). For example, prefer dtn://rover1.example.org/** over dtn://*.example.org/**.¶

2. Local preference: If local policy assigns preferences to originating ADs, or to the peers from which routes were learned (for example, to reflect cost, contractual arrangements, or trust), keep only the routes with the highest preference. A speaker with no such policy treats all routes as equally preferred.¶

3. Earliest delivery: For each route, take its estimated delivery time to be its arrival_time if it has one, and otherwise the time at which it becomes available, given by its valid_from attribute (Section 7.6); in either case, if that time is earlier than t, take it to be t. For each originating AD among the remaining routes, find the earliest estimated delivery time among its routes. Keep only the ADs for which this time is earliest.¶

4. Shortest path to each origin: For each remaining AD, find the length of the shortest AD_PATH among its routes whose estimated delivery time is the time found in step 3. Keep only the ADs for which this length is smallest. Path length counts entries in AD_PATH only; members of an ad_set attribute (Section 9.1) are not counted.¶

5. Tie-break between origins: If more than one AD remains, choose the AD with the longest-held route among the routes considered in step 4; if that does not decide, choose the AD whose name sorts first in a case-insensitive comparison. A route's age is the time since the advertisement that created it was first received on its session; replacing an advertisement with the same ID does not reset the age of routes whose pattern it retains.¶

Let T be the earliest time, not earlier than t, at which any of the chosen AD's routes considered in step 4 is available. Stage 2, choosing a route to that AD, from among the routes of the AD chosen in stage 1 that remain after steps 1 and 2 and are available at time T:¶

6. Lowest metric: Keep only the routes with the lowest metric (Section 8.4), regardless of the length of their AD_PATHs.¶

7. Earliest arrival: Keep only the routes with the earliest arrival_time. Routes without an arrival_time attribute are considered only if no remaining route has one.¶

8. Latest expiry: Keep only the routes that remain valid the longest, as given by their valid_until attributes (Section 7.6). A route with no valid_until attribute is treated as remaining valid indefinitely.¶

9. Shortest AD_PATH: Keep only the routes with the fewest entries in AD_PATH.¶

10. Oldest route: If more than one route remains, choose the one that has been held the longest, for stability. If more than one route remains, choose the one with the lower advertisement ID, and then the one received over the session whose peer's public key has the numerically smaller SHA-256 digest.¶

Treating a route without an arrival_time as delivering bundles as soon as it accepts them is optimistic, and so favors routes that omit the attribute. For this reason, a speaker that re-advertises a route that carries an arrival_time is required to include one (Section 9), and an originating AD that can estimate when it will deliver bundles SHOULD include an arrival_time in the routes it originates.¶

Selecting a route by this process is meaningful only if each AD along the path forwards bundles according to the route that it advertised. A DPP speaker therefore MUST advertise to its peers, for each pattern and each time, only a route derived from the route that it has selected for that time (Section 9), and MUST NOT advertise a route that it has not selected.¶

A DPP speaker MAY implement additional local policy that further modifies this process, but such policy is outside the scope of this specification.¶

9.1. Aggregation

A speaker MAY aggregate: that is, in place of the routes it has selected for several patterns, it MAY advertise a single route whose pattern covers them all, so as to reduce the number of routes it advertises. For example, a speaker holding selected routes for ipn:100.[0-3].* and ipn:100.[4-7].* may advertise ipn:100.[0-7].*. An aggregate is derived from a set of selected routes, the component routes, as follows.¶

Pattern:

The aggregate's pattern MUST satisfy Section 8.2 and MUST cover every component route's pattern. A speaker MUST NOT advertise an aggregate whose pattern matches any node for which it has no selected route at any time within the aggregate's window: aggregating MUST NOT claim reachability that the speaker does not have.¶

AD_PATH and AD_SET:

The aggregate's AD_PATH is the longest common prefix of the component routes' AD_PATHs, after the speaker has prepended its own AD to each (Section 7.3); since every component was received from some peer, this prefix always contains at least the speaker's own AD. Every AD that appears in any component's AD_PATH but not in that common prefix MUST be placed in the aggregate's ad_set attribute, together with the members of every component's own ad_set. AD_SET is an unordered set, and is propagated unchanged by speakers that re-advertise the aggregate. Loop detection considers both AD_PATH and AD_SET (Section 7.3). This is the role played by AS_SET in BGP aggregation (Section 9.2.2.2 of [RFC4271]).¶

Metric:

Component routes MUST have the same originating AD and the same metric; routes that differ in either MUST NOT be aggregated together, since the metric is compared only among routes from one originating AD (Section 8.4). The aggregate carries that metric. The originating AD of an aggregate is the last entry of its AD_PATH if the components share one; if the common prefix is shorter than the components' AD_PATHs, the originating AD is not recoverable from the aggregate, and speakers receiving it MUST treat the last AD_PATH entry as the originating AD for the purposes of Section 8.5.¶

Time window and arrival time:

The aggregate's window is set as for any re-advertised route (Section 9), and MUST lie within the intersection of the windows during which the speaker has a selected route for every node the aggregate's pattern matches. If any component carries an arrival_time, the aggregate MUST carry one that is not earlier than the latest of them, since the aggregate claims delivery to every component's nodes.¶

Other attributes:

gateway_eid, max_bundle_size, and bandwidth_bps describe the aggregating speaker's own AD and are set as for any re-advertised route. Component routes whose values for these attributes the speaker would set differently (for example, routes reached through different gateways) SHOULD NOT be aggregated.¶

Because AD_SET loses the order and the per-route composition of the component paths, path length comparison in Section 8.5 counts AD_PATH entries only; an aggregate therefore appears no longer than its shortest component. Operators who prefer precise path information over smaller route tables can disable aggregation.¶

10.1. AD Authentication

DPP authenticates Administrative Domains using mutual TLS and TLSA records published in each AD's DNS zone (Section 4). The security of this mechanism depends on:¶

DNSSEC:

The TLSA records are only as trustworthy as the DNSSEC chain that protects them. For this reason, DPP requires the TLSA RRset to be validated as secure (Section 4.2), and an AD that cannot sign its zone cannot be authenticated. An attacker who can forge a secure DNSSEC response for an AD's zone, for example by compromising the zone's signing keys or those of a parent zone, can impersonate that AD.¶

Private Key Protection:

The private key of each speaker authorized by a TLSA record MUST be protected. Compromise of a key allows impersonation of the Administrative Domain until its TLSA record is removed and the record's DNS TTL and signature validity have expired. Speakers that periodically re-verify their peers' authorization (see Section 4.2) limit the lifetime of an established session using a revoked key.¶

Channel binding:

Because the key authorized in DNS is the key that authenticates the TLS connection, an attacker cannot relay one speaker's authentication to a different session. An application-layer proof of key possession, such as a signed nonce, would not have this property unless it were explicitly bound to the TLS session.¶

DNS lookups triggered by unauthenticated peers:

The Responder looks up TLSA records for an AD named by a peer whose authorization has not yet been verified. Restricting lookups to ADs with which the Responder is configured to peer (Section 4.2) prevents a peer from causing lookups of arbitrary names.¶

Misdirected SVCB records:

An SVCB record at _dpp.<AD-Domain> can direct an Initiator to any host and port. Because the resulting TLS connection must be authenticated against the AD's TLSA records before any DPP message is acted on, a forged or misconfigured SVCB record can cause connection attempts to a host of the attacker's choosing, but cannot produce an authenticated session with it. Initiators SHOULD apply the same restrictions on destination ports to SVCB-derived addresses as to configured ones (Section 12 of [RFC9460]).¶

10.2. Transport Security

All DPP sessions use TLS 1.3 [RFC8446] or later, with both speakers authenticated, as specified in Section 4.2. This protects the confidentiality and integrity of route advertisements in transit, and ensures that every message on a session comes from the authenticated peer.¶

10.3. Route Injection Attacks

A malicious or compromised DPP speaker could advertise routes for destinations it does not legitimately serve. Implementations SHOULD support policy-based route filtering, so that operators can restrict the patterns accepted from each peer, and SHOULD provide the means to monitor route changes. Operators are advised to confirm, through channels outside DPP, that a peer is entitled to advertise routes to destinations that matter to them.¶

Specificity is the first step of route selection, ahead of local preference (Section 8.5). A malicious AD can therefore attract traffic for part of another AD's destinations by advertising a more specific pattern than the legitimate originating AD does: for example, ipn:100.5.* within another AD's ipn:100.*.*, or dtn://rover1.example.org/** within another AD's dtn://*.example.org/**. Such a route is preferred for the EIDs that it matches, whatever its local preference, delivery time, or path length, so none of the later selection steps limits its effect. This is the DPP equivalent of a BGP sub-prefix hijack. Until origin authorization is available (see below), the principal defense is route filtering: operators SHOULD configure, for each peer, the patterns that they are prepared to accept from that peer, and SHOULD reject more specific patterns than they expect.¶

The AD_PATH verification in Section 7.3 ensures that the first entry in AD_PATH is the authenticated peer, but a receiving speaker cannot verify the remaining entries: a malicious peer can still add or remove ADs further along the path, including the originating AD. Aggregation (Section 9.1) widens this: because an aggregate's AD_PATH is only the common prefix of its components' paths, a transit AD can shorten the apparent path of a route by aggregating it, legitimately or otherwise, and so make it more attractive in selection. Operators who do not trust a peer to aggregate honestly can apply local preference to routes that carry an ad_set.¶

Similarly, the metric is not protected. A malicious transit AD could lower the metric of routes it re-advertises, in violation of Section 8.4, and so attract traffic for the originating AD, even over a longer path: once that AD has been chosen as the destination, the metric takes precedence over AD_PATH length (Section 8.5). Because metrics are not used to choose between originating ADs, such manipulation cannot divert traffic from one originating AD to another, but it can divert traffic between routes into the same AD. Operators that are concerned by this can apply local preference to the peers from which they learn routes, or ignore the metric on routes from untrusted peers.¶

The time window, arrival time, bundle size, and bandwidth attributes are not protected either. Because estimated delivery time is used to choose between originating ADs (Section 8.5), a malicious transit AD that advertises an arrival_time earlier than the one it received, in violation of Section 9, or that omits the arrival_time it received, can attract traffic away from other originating ADs, not just between routes into the same AD. Local preference, which is applied before estimated delivery time, can be used to limit the influence of untrusted peers.¶

The time window, bundle size, and bandwidth attributes describe what the advertising AD itself offers, and a transit AD can legitimately advertise values that differ from those it received, in either direction (Section 9). A receiving speaker therefore cannot detect a false value by comparing it with the values advertised by other ADs on the path. An AD that overstates what it can store or forward can attract bundles that it then fails to deliver; the consequences are similar to those of any other AD that accepts bundles and discards them.¶

Mechanisms that could address these threats, analogous to those used to secure BGP, are discussed in Appendix C.¶

10.4. Denial of Service

DPP speakers are potentially vulnerable to denial of service attacks:¶

Connection exhaustion:

Implementations SHOULD limit the number of concurrent sessions and implement rate limiting for new connections.¶

Route table exhaustion:

Implementations SHOULD limit the number of routes accepted from a single peer, and close the session with code MAX_ROUTES_EXCEEDED when the limit is exceeded (Section 5.1).¶

Keepalive flooding:

Implementations SHOULD rate-limit incoming messages.¶

10.5. Privacy Considerations

Route advertisements reveal network topology and reachability information. Operators should consider whether this information is sensitive before establishing peering relationships.¶

11.1. Underscore-Prefixed DNS Name

This document requests registration of _dpp in the "Underscored and Globally Scoped DNS Node Names" registry per [RFC8552], for both RR types used at that name:¶

The SVCB entry satisfies the requirement of Section 14.3 of [RFC9460] that a protocol mapping be accompanied by such a registration; the mapping itself is in Section 4.1.2.1.¶

11.2. DPP Notification Codes Registry

This document requests the creation of a "DPP Notification Codes" registry. The registration policy is Specification Required (Section 4.6 of [RFC8126]). Each entry consists of a numeric value, a name, whether the code ends the session, and a reference. The initial contents are the values defined in Section 6.7, with this document as the reference. Values 0 through 10 are assigned by this document; values 11 through 65535 are available for assignment.¶

11.3. DPP Capabilities Registry

This document requests the creation of a "DPP Capabilities" registry of names that may appear in the capabilities field of the Hello message (Section 6.3). The registration policy is Specification Required (Section 4.6 of [RFC8126]). Each entry consists of a name, which MUST consist of lowercase ASCII letters, digits, and hyphens, and a reference. This document registers no names.¶

11.4. DPP Route Attribute Types Registry

This document requests the creation of a "DPP Route Attribute Types" registry. Each entry consists of a type number, a name, the protocol version that introduced it, and a reference to the document that defines it (Section 7.5). The type number is also the field number of the attribute's typed member in RouteAttribute (Section 6.5).¶

The registration policy for the Unassigned range is Specification Required (Section 4.6 of [RFC8126]). A specification requesting a type MUST provide the items listed in Section 7.5. The registry does not record how an attribute is processed; that is defined by the referenced document.¶

11.5. Future Considerations

This document does not request a port assignment. DPP uses port 50051 by default (Section 4.1.2.1), which is the port conventionally used by gRPC services and is not assigned to any protocol in the "Service Name and Transport Protocol Port Number Registry". Should a port be assigned for DPP by a later document, it would become the default.¶

12.1. Normative References

[GRPC]

The gRPC Authors, "gRPC over HTTP2", commit cf61c7d62a1a7f43b9d2ea6488186bc14fc41a8c, 17 April 2025, <https://github.com/grpc/grpc/blob/cf61c7d62a1a7f43b9d2ea6488186bc14fc41a8c/doc/PROTOCOL-HTTP2.md>. The gRPC wire protocol over HTTP/2. The current revision is at https://github.com/grpc/grpc/blob/master/doc/PROTOCOL-HTTP2.md.

[I-D.ietf-dtn-eid-pattern]

Sipos, B., "Bundle Protocol Endpoint ID Patterns", Work in Progress, Internet-Draft, draft-ietf-dtn-eid-pattern-11, 23 September 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-eid-pattern-11>.

[I-D.taylor-dtn-eid-pattern-dtn]

Taylor, R., "Endpoint ID Patterns for the dtn URI Scheme", Work in Progress, Internet-Draft, draft-taylor-dtn-eid-pattern-dtn-00, 2026, <https://datatracker.ietf.org/doc/html/draft-taylor-dtn-eid-pattern-dtn-00>. Work in progress; not yet published.

[PROTOBUF]

Google LLC, "Protocol Buffers: Encoding", commit d75b49a09168103d132dcccf7dc9d6e126ba1f98, 8 October 2026, <https://github.com/protocolbuffers/protocolbuffers.github.io/blob/d75b49a09168103d132dcccf7dc9d6e126ba1f98/content/programming-guides/encoding.md>. The protobuf wire format. The current rendering is at https://protobuf.dev/programming-guides/encoding/.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC4035]

Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, <https://www.rfc-editor.org/rfc/rfc4035>.

[RFC5890]

Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/rfc/rfc5890>.

[RFC6698]

Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/rfc/rfc6698>.

[RFC7671]

Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/rfc/rfc7671>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/rfc/rfc8446>.

[RFC8552]

Crocker, D., "Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves", BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/rfc/rfc8552>.

[RFC9171]

Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.

[RFC9364]

Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, RFC 9364, DOI 10.17487/RFC9364, February 2023, <https://www.rfc-editor.org/rfc/rfc9364>.

[RFC9460]

Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

[RFC9758]

Taylor, R. and E. Birrane III, "Updates to the 'ipn' URI Scheme", RFC 9758, DOI 10.17487/RFC9758, May 2025, <https://www.rfc-editor.org/rfc/rfc9758>.

12.2. Informative References

[CCSDS-SABR]

Consultative Committee for Space Data Systems, "Schedule-Aware Bundle Routing", CCSDS Recommended Standard 734.3-B-1, 2019, <https://ccsds.org/Pubs/734x3b1.pdf>.

[I-D.ek-dtn-ipn-arpa]

Kline, E., "The ipn.arpa Zone and IPN DNS Operations", Work in Progress, Internet-Draft, draft-ek-dtn-ipn-arpa-00, 4 November 2025, <https://datatracker.ietf.org/doc/html/draft-ek-dtn-ipn-arpa-00>.

[I-D.ietf-dtn-bibe]

Taylor, R. and A. Montilla, "Bundle-in-Bundle Encapsulation", Work in Progress, Internet-Draft, draft-ietf-dtn-bibe-01, 23 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-bibe-01>.

[I-D.ietf-sidrops-aspa-verification]

Azimov, A., Bogomazov, E., Bush, R., Patel, K., Snijders, J., and K. Sriram, "BGP AS_PATH Verification Based on Autonomous System Provider Authorization (ASPA) Objects", Work in Progress, Internet-Draft, draft-ietf-sidrops-aspa-verification-29, 16 October 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-verification-29>.

[RFC3345]

McPherson, D., Gill, V., Walton, D., and A. Retana, "Border Gateway Protocol (BGP) Persistent Route Oscillation Condition", RFC 3345, DOI 10.17487/RFC3345, August 2002, <https://www.rfc-editor.org/rfc/rfc3345>.

[RFC4271]

Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/rfc/rfc4271>.

[RFC4451]

McPherson, D. and V. Gill, "BGP MULTI_EXIT_DISC (MED) Considerations", RFC 4451, DOI 10.17487/RFC4451, March 2006, <https://www.rfc-editor.org/rfc/rfc4451>.

[RFC4724]

Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, DOI 10.17487/RFC4724, January 2007, <https://www.rfc-editor.org/rfc/rfc4724>.

[RFC6480]

Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/rfc/rfc6480>.

[RFC6811]

Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, DOI 10.17487/RFC6811, January 2013, <https://www.rfc-editor.org/rfc/rfc6811>.

[RFC7606]

Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/rfc/rfc7606>.

[RFC7911]

Walton, D., Retana, A., Chen, E., and J. Scudder, "Advertisement of Multiple Paths in BGP", RFC 7911, DOI 10.17487/RFC7911, July 2016, <https://www.rfc-editor.org/rfc/rfc7911>.

[RFC8205]

Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol Specification", RFC 8205, DOI 10.17487/RFC8205, September 2017, <https://www.rfc-editor.org/rfc/rfc8205>.

[RFC9174]

Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4", RFC 9174, DOI 10.17487/RFC9174, January 2022, <https://www.rfc-editor.org/rfc/rfc9174>.

[RFC9319]

Gilad, Y., Goldberg, S., Sriram, K., Snijders, J., and B. Maddison, "The Use of maxLength in the Resource Public Key Infrastructure (RPKI)", BCP 185, RFC 9319, DOI 10.17487/RFC9319, October 2022, <https://www.rfc-editor.org/rfc/rfc9319>.

[RFC9461]

Schwartz, B., "Service Binding Mapping for DNS Servers", RFC 9461, DOI 10.17487/RFC9461, November 2023, <https://www.rfc-editor.org/rfc/rfc9461>.