Bundle Protocol (BP) Secure Advertisement and Neighborhood Discovery (SAND)
draft-ietf-dtn-bp-sand-04
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Brian Sipos , Joshua Deaton | ||
| Last updated | 2026-09-08 (Latest revision 2026-07-06) | ||
| Replaces | draft-sipos-dtn-bp-sand | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | WG Document | |
| On agenda | dtn at IETF-127 | ||
| Document shepherd | (None) | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-dtn-bp-sand-04
Delay-Tolerant Networking B. Sipos
Internet-Draft JHU/APL
Intended status: Standards Track J. Deaton
Expires: 12 March 2027 SAIC
8 September 2026
Bundle Protocol (BP) Secure Advertisement and Neighborhood Discovery
(SAND)
draft-ietf-dtn-bp-sand-04
Abstract
This document defines the Secure Advertisement and Neighborhood
Discovery (SAND) protocol for Bundle Protocol version 7 (BPv7) within
a delay-tolerant network (DTN). This protocol defines a general
purpose advertisement mechanism with an initial set of message and
data types able to be advertised by participating nodes in a BPv7
network. The focus of this document is for advertisement to
topological neighbors about local neighborhoods but can be expanded
upon in the future through extension points.
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 12 March 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
Sipos & Deaton Expires 12 March 2027 [Page 1]
Internet-Draft BP SAND September 2026
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Use Cases Considered . . . . . . . . . . . . . . . . . . 6
1.2.1. Zero-Configuration Neighbor Discovery . . . . . . . . 6
1.2.2. Targeted Neighbor Discovery . . . . . . . . . . . . . 6
1.2.3. Neighbor Reachability Discovery . . . . . . . . . . . 7
1.2.4. Neighborhood Topology Discovery . . . . . . . . . . . 7
1.2.5. Credential Discovery . . . . . . . . . . . . . . . . 7
1.2.6. Private Use Discovery . . . . . . . . . . . . . . . . 7
1.3. Use of CDDL . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. General Protocol Description . . . . . . . . . . . . . . . . 10
2.1. Extensibility . . . . . . . . . . . . . . . . . . . . . . 10
2.1.1. Transport Extensions . . . . . . . . . . . . . . . . 11
2.1.2. SAND Message Types . . . . . . . . . . . . . . . . . 11
2.1.3. Metadata Parameters . . . . . . . . . . . . . . . . . 11
2.1.4. Message Data Parameters . . . . . . . . . . . . . . . 11
2.1.5. Enumerated Data Values . . . . . . . . . . . . . . . 12
2.2. Relationship to other Discovery Protocols . . . . . . . . 12
3. Information Bases . . . . . . . . . . . . . . . . . . . . . . 13
3.1. Local Node Information Bases . . . . . . . . . . . . . . 13
3.2. Neighbor Information Bases . . . . . . . . . . . . . . . 20
3.3. Network Information Bases . . . . . . . . . . . . . . . . 22
4. Message Transport . . . . . . . . . . . . . . . . . . . . . . 24
4.1. SAND Endpoints . . . . . . . . . . . . . . . . . . . . . 24
4.2. SAND Bundle . . . . . . . . . . . . . . . . . . . . . . . 25
4.3. Previous Node Identification . . . . . . . . . . . . . . 26
4.4. Bundle Security . . . . . . . . . . . . . . . . . . . . . 27
4.5. Superseding Messages . . . . . . . . . . . . . . . . . . 28
4.6. Default Convergence Layers . . . . . . . . . . . . . . . 28
4.6.1. IP Multicast Forwarding . . . . . . . . . . . . . . . 29
4.6.2. Ethernet Multicast Forwarding . . . . . . . . . . . . 30
5. Message Structure and Types . . . . . . . . . . . . . . . . . 30
5.1. Data Solicitation . . . . . . . . . . . . . . . . . . . . 34
5.2. Credential Advertisement . . . . . . . . . . . . . . . . 34
5.3. Underlayer Network (ULN) Advertisement . . . . . . . . . 35
5.3.1. IP-Related ULN Parameters . . . . . . . . . . . . . . 37
5.4. Convergence Layer (CL) Advertisement . . . . . . . . . . 40
5.4.1. IP-Related CL Parameters . . . . . . . . . . . . . . 42
5.4.2. TCPCLv4 Parameters . . . . . . . . . . . . . . . . . 43
5.4.3. UDPCLv2 Parameters . . . . . . . . . . . . . . . . . 44
Sipos & Deaton Expires 12 March 2027 [Page 2]
Internet-Draft BP SAND September 2026
5.4.4. LTPCL-over-UDP Parameters . . . . . . . . . . . . . . 45
5.4.5. BTPU-over-Ethernet Parameters . . . . . . . . . . . . 46
5.4.6. TCPCLv3 Parameters . . . . . . . . . . . . . . . . . 48
5.4.7. Experimental UDPCL Parameters . . . . . . . . . . . . 48
5.5. Resource Advertisement . . . . . . . . . . . . . . . . . 48
5.6. Local Topology Advertisement . . . . . . . . . . . . . . 49
5.6.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 51
5.6.1.1. SABR/CGR . . . . . . . . . . . . . . . . . . . . 52
5.7. Router Advertisement . . . . . . . . . . . . . . . . . . 55
5.8. Endpoint Advertisement . . . . . . . . . . . . . . . . . 56
5.8.1. SAND Singleton Endpoint . . . . . . . . . . . . . . . 58
6. Messaging Modes . . . . . . . . . . . . . . . . . . . . . . . 58
6.1. Group Hello . . . . . . . . . . . . . . . . . . . . . . . 58
6.2. Targeted Hello . . . . . . . . . . . . . . . . . . . . . 59
6.3. Response to Solicitation . . . . . . . . . . . . . . . . 59
6.4. Periodic Update . . . . . . . . . . . . . . . . . . . . . 59
7. Operational Considerations . . . . . . . . . . . . . . . . . 59
7.1. Types of Data to Advertise . . . . . . . . . . . . . . . 60
7.2. Instances of Data to Advertise . . . . . . . . . . . . . 60
7.3. Context-Specific Advertisement Filtering . . . . . . . . 61
7.4. When to Advertise . . . . . . . . . . . . . . . . . . . . 61
7.5. Authorizing Discovered Data . . . . . . . . . . . . . . . 62
7.6. Culling Discovered Data . . . . . . . . . . . . . . . . . 63
7.7. Correlating CL Instances with SAND Bundles . . . . . . . 63
8. Security Considerations . . . . . . . . . . . . . . . . . . . 64
8.1. Threat: Passive Leak of Data to Eavesdroppers . . . . . . 64
8.2. Threat: Leak of Data to Discovering Nodes . . . . . . . . 65
8.3. Threat: SAND Bundle Replay . . . . . . . . . . . . . . . 65
8.4. Threat: Denial of Service . . . . . . . . . . . . . . . . 65
8.5. Threat: Route Leaking and Hijacking . . . . . . . . . . . 66
8.6. Identity Bootstrapping . . . . . . . . . . . . . . . . . 66
8.7. Messaging Without Authentication . . . . . . . . . . . . 67
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67
9.1. Well-Known IMC Group and Service . . . . . . . . . . . . 67
9.2. Well-Known IPN Service . . . . . . . . . . . . . . . . . 68
9.3. BP SAND Registry Group . . . . . . . . . . . . . . . . . 68
9.3.1. SAND Message Types . . . . . . . . . . . . . . . . . 68
9.3.2. SAND Message Metadata . . . . . . . . . . . . . . . . 70
9.3.3. SAND ULN Registries . . . . . . . . . . . . . . . . . 70
9.3.4. SAND CL Registries . . . . . . . . . . . . . . . . . 71
9.3.5. SAND Resource Registries . . . . . . . . . . . . . . 75
9.3.6. SAND Local Topology Registries . . . . . . . . . . . 76
9.3.7. SAND Endpoint Parameters . . . . . . . . . . . . . . 79
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 80
10.1. Normative References . . . . . . . . . . . . . . . . . . 80
10.2. Informative References . . . . . . . . . . . . . . . . . 83
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 87
Implementation Status . . . . . . . . . . . . . . . . . . . . . . 87
Sipos & Deaton Expires 12 March 2027 [Page 3]
Internet-Draft BP SAND September 2026
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 87
1. Introduction
Deployments of Bundle Protocol version 7 (BPv7) nodes have required a
significant amount of configuration for both the node being enrolled
in the BPv7 network as well as the pre-existing (one-hop neighbor)
nodes expected to communicate with the new node. The configuration
consists of both BP-layer parameters, such as identity and security
capabilities, as well as underlying convergence layer (CL) and
associated transport parameters.
When nodes are in the same administrative domain, these parameters
might be easy to find and the burden is solely about configuring the
nodes. But when nodes need to configure across administrative
domains simply finding the parameters could be an operational
challenge, and if the parameters change keeping them synchronized is
yet more complexity. Administrative domains might be crossed at the
boundary between organizations (_e.g._, when bridging two BP wide-
area networks) but they can also be crossed within a single host or
platform where there are nodes from different vendors present which
need to interoperate.
Additional considerations for discovery within a BP network are
related to the expectation of challenged nature of a delay-tolerant
network (DTN) more generally. This means long one-way light-time
(OWLT) delays between neighbors, expected time-varying
discontinuities between neighbors, and a variety of CL transport
types, each with associated parameters, capabilities, and
limitations. More detailed descriptions of the challenges of DTNs
can be found in "Delay-Tolerant Network Architecture" [RFC4838].
Earlier research into discovery within a BP network led to
development of the draft experimental IP Neighbor Discovery (IPND)
protocol [I-D.irtf-dtnrg-ipnd], but that protocol is intimately tied
to its use of UDP datagram "beacons" and necessary use of an IP
underlay network. It also would require allocation of well-known UDP
port number and IP multicast addresses or pre-configuration of those
parameters across network nodes, but no such allocations were ever
made.
To mitigate the need for manual parameter discovery and
configuration, an online neighborhood discovery protocol can be used,
and such a protocol is defined in this document. The Secure
Advertisement and Neighborhood Discovery (SAND) protocol operates at
and above the BP-layer, as shown in Figure 1, which insulates it from
strict dependence on any specific CL for its message transport and
allows the use of BPSec for message security. The full protocol
Sipos & Deaton Expires 12 March 2027 [Page 4]
Internet-Draft BP SAND September 2026
stack of this document uses the UDP Convergence Layer (UDPCL) version
2 [I-D.ietf-dtn-udpcl] as a zero-configuration default (Section 4.6)
for its any-source multicast (ASM) capability but SAND could be, and
is expected to be, used over other CLs (to include unicast
transports) which might be informed by lower-layer discovery
protocols (see Section 2.2).
+-------------------------+
| Secure Discovery (SAND) | -\
+-------------------------| |
| BPv7 + BPSec | -> Application Layer
+-------------------------+ |
| CL + opt. security | -/
+-------------------------+
| TCP/UDP/etc. | ---> Transport Layer
+-------------------------+
| IPv4/IPv6 + ASM | ---> Network Layer
+-------------------------+
| Link-Layer Protocol | ---> Link Layer
+-------------------------+
Figure 1: The Locations of SAND and BP above the Internet
Protocol Stack
1.1. Scope
This document describes the format of the protocol data units passed
between BP nodes for neighborhood discovery and defines behavior at
message source and destination nodes. This document is specifically
limited to one-hop messaging between neighbors and reserves any
discussion of multi-hop advertisement with forwarded messages to
later specifications.
This document does not address:
* The format of protocol data units of the Bundle Protocol, as those
are defined elsewhere [RFC9171]. This includes the concept of
bundle fragmentation or bundle encapsulation.
* Logic for routing bundles along a path toward a bundle's endpoint.
This messaging protocol involves only one-hop singleton and group
messaging.
* Policies or mechanisms for using BP extension blocks for purposes
not defined in this document. Some networks could require
specific extension blocks to be present for valid traffic.
Sipos & Deaton Expires 12 March 2027 [Page 5]
Internet-Draft BP SAND September 2026
* Policies or mechanisms for issuing Public Key Infrastructure Using
X.509 (PKIX) certificates; provisioning, deploying, or accessing
certificates and private keys; deploying or accessing certificate
revocation lists (CRLs); or configuring security parameters on an
individual entity or across a network.
* Uses of Bundle Protocol Security (BPSec) in which authentication
of the Source Node ID is not possible (see Section 8.7).
1.2. Use Cases Considered
This section explains use cases for which the SAND protocol defined
in this document serves as a supporting role. Other use cases might
be supported by or enhanced by SAND and are left to other documents
to explain.
1.2.1. Zero-Configuration Neighbor Discovery
This case is the most simple to explain, to discover enough
information about BP neighbors to forward to them and receive from
them without any prior in-band configuration needed. It relies on a
critical assumption about its operating environment: that nodes are
listening on multicast group destinations for one or more default
convergence layer (see Section 4.6) which is reachable from each
advertising node through some shared medium.
Given that assumption, any SAND participant can (periodically or
based on link status events, see Section 7.4) advertise itself to
and/or solicit from potential neighbors using the well-known BP group
destination (Section 9.1) and the lower-layer multicast group. There
is no guarantee that any other lower-layer multicast group members
exist, happen to be listening at, or are in fact reachable at any
specific time.
1.2.2. Targeted Neighbor Discovery
This case is when another, lower-layer discovery mechanism (see
Section 2.2) has prompted the node that some lower-layer neighbor
exists and is reachable. Information about that lower-layer neighbor
is then used by the SAND participant to advertise itself to and/or
solicit from the potential new neighbor using the well-known BP group
destination (Section 9.1) and the lower-layer unicast destination
address. There is no guarantee that just because a lower-layer
neighbor exists that it will also be a SAND participant.
Sipos & Deaton Expires 12 March 2027 [Page 6]
Internet-Draft BP SAND September 2026
1.2.3. Neighbor Reachability Discovery
Once a SAND participant BP neighbor is known to exist (with specific
compatible CL instances), there is both operational and diagnostic
value in verifying reachability to and from that neighbor regardless
of the presence (or absence) of other BP traffic with that neighbor.
Each node can periodically send Local Topology Advertisement messages
to known neighbors that contain at least the SAND singleton EID for
the neighbor itself. The message itself conveys reachability to the
neighbor and the presence of the neighbor within the message conveys
near-past reachability from that neighbor. This BP-layer information
can be combined with lower-layer mechanisms for reachability or link
metrics discovery to drive routing decisions on a node.
1.2.4. Neighborhood Topology Discovery
As the title of this document implies, one of the most complex use
cases of this protocol is to discover the topology of the local 2-hop
neighborhood. This is an extension of the simple reachability
discovery case where each advertising node includes _all_ known 1-hop
neighbors in its Local Topology Advertisement so that each neighbor
is made aware of each other within the 2-hop neighborhood. The means
by which these advertisements are transported (either as group
destinations in BP and underlayer or singleton/unicast destinations)
is an implementation choice based on the availability of multicast in
the underlayer(s) and any need for context-specific filtering
(Section 7.3) of the data.
1.2.5. Credential Discovery
A secondary use case of this protocol is to allow an advertising node
to distribute arbitrary credentials to other participating nodes.
This enables capabilities such as using short-term auto-renewed
(STAR) signing certificates with the BPSec COSE Context
[I-D.ietf-dtn-bpsec-cose] without requiring each BIB on every bundle
to contain a copy of the certificate chain. Other BP-based
applications could also make use of credentials discovered via SAND,
but such uses are left to other specifications.
1.2.6. Private Use Discovery
While applications are free to use their own payload structures with
BP non-singleton destinations, this protocol provides extensibility
(Section 2.1) of both message types and data parameters which can
enable an implementation to maintain, advertise, and discover
application-specific data. The benefit to the application in this
case would be that it interacts with the information bases of the
local SAND entity rather than need to deal with messaging and
Sipos & Deaton Expires 12 March 2027 [Page 7]
Internet-Draft BP SAND September 2026
transport logic (Section 4) provided by SAND.
1.3. Use of CDDL
This document defines CBOR structure using the Concise Data
Definition Language (CDDL) [RFC8610]. The entire CDDL structure can
be extracted from the XML version of this document using the XPath
expression:
'//sourcecode[@type="cddl"]'
The following initial fragment defines the top-level rules of this
document's CDDL.
start = sand-adu-seq / sand-msg
1.4. Terminology
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.
This document re-uses the following terms from IETF network topology
model [RFC8345].
Node: This refers both to the concept of a BP node and more
generally as a node in a network inventory or topology.
Termination Point (TP): This refers to a single stable, identified
feature of a node to which underlayer names and/or addresses are
assigned. Outside of the topology model, in the actual data
plane, each TP might correspond with an IP interface [RFC8200] or
Ethernet interface.
Link: This term is used in the abstract sense to identify pairwise
reachability between TPs of different nodes in the same
topological layer. The actual link-layer is not implied by this
logical entity, and exists in a separate supporting underlayer.
Inventory: A collection of known nodes and their properties without
regard for their reachability.
Topology: A collection of nodes which includes information about
reachability via termination points and links.
Supporting Network: Within the SAND data model, an underlayer
Sipos & Deaton Expires 12 March 2027 [Page 8]
Internet-Draft BP SAND September 2026
network is used in support of a BP network without regard to the
specific technology of that underlayer. Each underlayer network
will have its own topology which is managed separately from the BP
network topology used by SAND.
Additional terminology used within the SAND protocol includes the
following.
SAND Bundle: A BPv7 PDU which envelopes a payload of a SAND PDU as
defined in Section 4.
Participating node: A BP node which transmits and/or delivers SAND
Bundles.
Advertising node: A BP node which transmits SAND Bundles. Because
SAND transport requires a singleton source EID, each SAND Bundle
has a single advertising node.
Discovering node: A BP node which delivers SAND Bundles. Because
SAND transport allows a non-singleton destination EID, each SAND
Bundle can have multiple discovering nodes (or none).
Reference node: A BP node which serves as the reference point for
some local topology.
Reachable: A one-way determination of whether a source node can
transfer bundles to a destination node (via any number of BP hops
using any combination of CLs).
1-hop Reachable: A one-way determination of whether a destination
node is reachable from a reference node via a single BP hop.
1-hop Neighbor: A participating node for which a reference node is
1-hop reachable. The other node does not need to also be 1-hop
reachable from the reference node to be a neighbor.
Mutual Neighbors: Two nodes which each identify the other as a 1-hop
neighbor.
2-hop Neighbor: A participating node which is a 1-hop neighbor of a
1-hop neighbor of a reference node, but is not itself a 1-hop
neighbor of the reference node.
Neighborhood: The collection of all 1-hop and 2-hop neighbors of a
participating node.
Sipos & Deaton Expires 12 March 2027 [Page 9]
Internet-Draft BP SAND September 2026
2. General Protocol Description
The service of this protocol is the discovery of security credentials
and capabilities of peer nodes within a 2-hop neighborhood without
needing any pre-configuration on the participating node or on other
nodes in the network.
Each participating node uses per-underlayer and per-neighbor timers
to determine when to solicit and when to advertise data. Some
external events (e.g. network- or link-level discovery) can be used
to reset timers so that discovery can be completed more quickly.
The types of data able to be advertised by a node are the following,
each associated with a subsection defining its message type and
structure. Each type of data can be associated with a desired update
time interval to ensure timely synchronization between peers.
Security credentials: Defined in Section 5.2 to contain credentials
(_e.g._, PKIX certificates) associated with the node's identities
which are used for signing/key-agreement/encryption.
Underlayer networks: Defined in Section 5.3 to contain information
about what underlayer networks (and their termination points) are
available on the node.
Convergence Layer instances: Defined in Section 5.4 to contain CL
types and parameters needed to communicate with the node through
specific underlayer networks.
Node resource forecast: Contains operating state and other forecasts
for the node.
Local (1-hop) topology: Contains 1-hop neighbors seen by the node.
Routing willingness: Contains willingness for the node to route
specific traffic, and stub network contents.
Application endpoints: Contains endpoints available on the node.
2.1. Extensibility
Future specifications can use this same messaging and transport
mechanism to define additional message modes, types, and data content
including types for private or experimental use.
Sipos & Deaton Expires 12 March 2027 [Page 10]
Internet-Draft BP SAND September 2026
2.1.1. Transport Extensions
This document specifies only the use of SAND for one-hop
advertisement over either a unicast or multicast convergence layer.
Future specifications could extend this to define multi-hop flooding
of SAND Bundles in order to distribute data more widely for link-
state-style routing algorithms.
Altering the transport profile can be done without changing the SAND
PDU or message structure of Section 5, and would allow re-using much
of the logic defined in Section 4.
2.1.2. SAND Message Types
The set of SAND message types (as integer code points) is defined in
an IANA registry in Section 9.3.1. This allows for future
specifications to add new message types as well as reserving blocks
of code points for private use and experimental use. New message
types could be used for BP-node-related discovery, BP-routing-related
discovery, or even application data discovery facilitated by SAND.
2.1.3. Metadata Parameters
The set of message metadata parameters (as integer map keys) is
defined in individual IANA registries in Section 9.3.2. This allows
future specifications to augment message semantics if necessary.
2.1.4. Message Data Parameters
The set of message-type-specific data parameters (as integer map
keys) is defined in an IANA registry in Section 9.3.2. This allows
future specifications to expand the envelope of technologies
supported by SAND without needing a change in message structure or
semantics.
For example, a non-IP-based CL type can define new parameters (either
IANA-registered or within a private-use block) to express other
address families. As another example, a specific implementation can
augment existing CL-type-specific parameters (negative keys) without
needing to define a new CL type code point, so there is a backward
compatibility with implementations that do not support the new
parameters.
Sipos & Deaton Expires 12 March 2027 [Page 11]
Internet-Draft BP SAND September 2026
2.1.5. Enumerated Data Values
There are specific message data parameters which define and use an
IANA registry for extensible values. In this document, these
parameters are the CL Type (Table 20) within the CL Advertisement
message (Section 5.4), and the Routing Type (Table 25) within the
Local Topology Advertisement message (Section 5.6). Both of these
parameters allow additional type-specific parameters to be used and
reserve blocks of value code space for private use and experimental
use.
2.2. Relationship to other Discovery Protocols
Many of the structural, behavioral, and especially timing definitions
in this specification follow the model of MANET messaging [RFC5444]
and MANET NHDP [RFC6130] in both terminology and semantics. This is
intentional to allow an implementer to understand BP discovery with
very similar logic to MANET discovery. Where the NHDP is concerned
with IP routers discovering reachable IP neighbors and routes, SAND
is concerned with BP nodes discovering reachable BP neighbors and
routes.
A node participating in the SAND protocol is expected to use lower-
layer discovery mechanisms as necessary to enroll in a local network,
obtain network-layer address(es) and parameters, and possibly
discover network-layer neighbor nodes and routers. This might
involve the use of IPv4 Internet Router Discovery Protocol (IRDP)
[RFC1256] or IPv6 Secure Neighbor Discovery Protocol (SEND) [RFC3971]
[RFC4861] to determine IP neighbors, the Dynamic Host Configuration
Protocol (DHCP) [RFC2131] [RFC8415] to assign addresses and network-
level parameters, or the Dynamic Link Exchange Protocol (DLEP)
[RFC8175] to discover connectivity and specific IP neighbor nodes.
The robust and delay-tolerant protocol in this document is also
compatible with the DNS-Based Service Discovery (DNS-SD) of BP
routers by edge nodes [I-D.sipos-dtn-edge-zeroconf]. The SAND
protocol can be used to enroll an edge router in a BP network and
synchronize routing information across a variety of network and link
types, while DNS-SD is used within IP stub underlay networks (or
enclaves) at the edges of the BP network for simpler and more
synchronous edge nodes.
Sipos & Deaton Expires 12 March 2027 [Page 12]
Internet-Draft BP SAND September 2026
3. Information Bases
SAND operates by each participating node keeping a persistent store
of its enrolled underlayer networks, 1-hop neighbors, symmetric 2-hop
neighbors along with attributes for each type of entity. These are
used as the basis for outgoing SAND message contents and are updated
as part of message reception processing.
The discussion in this section is in support of interoperable SAND
implementations by providing a conceptual information model [RFC3444]
which is abstracted from implementation details about how data
conforming to the information model is actually structured,
maintained, stored, accessed, _etc._ This information model is not
normative for a SAND entity, and where there are normative statements
in this section they are all related somehow to observable protocol
behavior.
There are also relationships between this information model and the
extensibility discussed in Section 2.1 which are left as an
implementation matter to resolve. The information model presented
here applies only to the base protocol defined in this document with
hints about where extensibility might affect this model or the more
concrete data model of an implementation.
3.1. Local Node Information Bases
This category of information is based on a participating node's
knowledge of its own underlayer network (ULN) and PKI configuration.
It exists as input to SAND processing and messaging and is unaffected
by the results of processing or reception of messages.
The resource information of Table 1 is used to populate Resource
Advertisement messages. The information in this table applies
generally to the node as a whole and not for any specific underlayer
network, termination point, or CL.
Sipos & Deaton Expires 12 March 2027 [Page 13]
Internet-Draft BP SAND September 2026
+===========+===================================================+
| Name | Description |
+===========+===================================================+
| Validity | This is the full time horizon for resource |
| Interval | schedules in this information base. |
+-----------+---------------------------------------------------+
| Operating | This represents a time-varying operating state of |
| Schedule | the local node (as either "on" or "off") within |
| | the validity interval. An operating schedule |
| | which indicates "always on" is a valid default. |
+-----------+---------------------------------------------------+
Table 1: Local Resource Information
The ULN information described in Table 2 allows a participating node
to define different profiles for different networks (IP or otherwise)
accessible by the node through local termination points. As defined
in Section 6, when assembling and sending SAND messages much of the
data can be filtered-down based on what is accessible via a
termination point associated with the network-layer source of a SAND
message (among other possible additional filtering, see Section 8.1).
Sipos & Deaton Expires 12 March 2027 [Page 14]
Internet-Draft BP SAND September 2026
+===============+================================================+
| Name | Description |
+===============+================================================+
| Termination | This is a locally-unique numeric identifier |
| Point Index | for a network interface or equivalent |
| | termination point. Whether or not this index |
| | corresponds some way to other identifiers is |
| | an implementation matter and does not affect |
| | this protocol. |
+---------------+------------------------------------------------+
| Properties below are based on the above unique key columns. |
+---------------+------------------------------------------------+
| Accessible | This is the set of ULN names and addresses |
| Network Set | assigned to the termination point and |
| | associated subnetworks accessible to this node |
| | via the termination point. For IP |
| | underlayers, these are respectively DNS names, |
| | IP addresses, and CIDR-form of subnetwork |
| | definitions conforming to BCP 122 [RFC4632]. |
+---------------+------------------------------------------------+
| Link MTU | This is the configured or discovered maximum |
| | transmission unit (MTU) of the first-hop |
| | network link for the underlayer. Because this |
| | is a link MTU it excludes any network packet |
| | header overhead and is network-protocol- |
| | independent. This also represents a maximum |
| | outgoing size and not necessarily the maximum |
| | incoming size. This is not necessarily the |
| | same as a path MTU between any peers on this |
| | network, and a path MTU can be directional. |
+---------------+------------------------------------------------+
| SAND Timer | This is the set of timers needed to configure |
| Configuration | SAND activities, as defined in Table 3. |
+---------------+------------------------------------------------+
Table 2: Underlayer Network Information Columns
The items in Table 3 represents the set of timer configuration needed
to operate a participating node. As an information model, details
such as specific units or encoding forms are left as an
implementation matter. Because SAND uses the DTN time epoch and
encoded form, SAND timer configuration SHOULD have a resolution down
to at least one millisecond.
Sipos & Deaton Expires 12 March 2027 [Page 15]
Internet-Draft BP SAND September 2026
+==========+==================+=================================+
| Name | Scope | Description |
+==========+==================+=================================+
| Minimum | default and per- | This represents the shortest |
| Time | message-type | time interval between sending |
| Interval | | messages of the same type on a |
| | | particular ULN or to a specific |
| | | singleton destination. |
+----------+------------------+---------------------------------+
| Maximum | default and per- | This represents the longest |
| Time | message-type | time interval between sending |
| Interval | | messages of the same type on a |
| | | particular ULN or to a specific |
| | | singleton destination. This is |
| | | used as a timeout for Periodic |
| | | Update messaging. The Maximum |
| | | Time Interval MUST be longer |
| | | than the Minimum Time Interval |
| | | by some factor. |
+----------+------------------+---------------------------------+
| Validity | default and per- | This is embedded in messages |
| Duration | message-type | optionally and used for SAND |
| | | Bundle lifetimes. The Validity |
| | | Duration MUST be longer than |
| | | the Maximum Time Interval by |
| | | some factor. |
+----------+------------------+---------------------------------+
Table 3: SAND Timer Configuration
The Identity information of Table 4 is a logical table used both as a
source for sending Credential Advertisement messages as well as for
deriving BPSec policy used to send signed payloads and/or receive
encrypted payloads.
Sipos & Deaton Expires 12 March 2027 [Page 16]
Internet-Draft BP SAND September 2026
+===============+===================================================+
| Name | Description |
+===============+===================================================+
| Thumbnail | This is the x5t or c5t thumbnail of the encoded |
| | certificate, used as a selector. |
+---------------+---------------------------------------------------+
| Properties below are based on the above unique key columns. |
+---------------+---------------------------------------------------+
| Key Usage | This is the extracted Key Usage value, from |
| | Section 4.2.1.3 of [RFC5280], used as a selector. |
+---------------+---------------------------------------------------+
| Validity | This is the extracted Validity interval, from |
| Time | Section 4.1.2.5 of [RFC5280], used as a selector. |
| Interval | |
+---------------+---------------------------------------------------+
| Encoded | This is the DER-encoded X509 certificate |
| Certificate | contents. |
+---------------+---------------------------------------------------+
Table 4: Local Identity Information Columns
The trust anchor information of Table 5 is a logical table used for
validating received peer certificates and for deriving BPSec policy
used to receive signed payloads.
+=============+====================================================+
| Name | Description |
+=============+====================================================+
| Subject Key | This is the extracted Subject Key Identifier, from |
| Identifier | Section 4.2.1.2 of [RFC5280], used as a selector. |
+-------------+----------------------------------------------------+
| Properties below are based on the above unique key columns. |
+-------------+----------------------------------------------------+
| Validity | This is the extracted Validity interval, from |
| Time | Section 4.1.2.5 of [RFC5280], used as a selector. |
| Interval | |
+-------------+----------------------------------------------------+
| Encoded | This is the DER-encoded X509 certificate contents. |
| Certificate | |
+-------------+----------------------------------------------------+
Table 5: Local Trust Anchor Information Columns
Sipos & Deaton Expires 12 March 2027 [Page 17]
Internet-Draft BP SAND September 2026
The convergence layer information of Table 6 is a logical table
separated from the network information of Table 2 because many BP
node deployments are expected to have CL instances that are bound to
"any endpoint" addresses and can operate across multiple networks.
Even in cases where a CL establishes persistent sessions which might
be bound to a specific endpoint address or network, the CL instance
as a whole can operate simultaneous sessions across many networks.
When used as a source for sending Convergence Layer (CL)
Advertisement messages the advertised CL List is expected to be, but
not required to be, filtered-down based on the termination point and/
or network on which the message will be sent. Besides being
filtered-out for a specific network, a CL instance SHALL NOT be
represented differently across different termination points.
The effective removal of a CL instance is to store and advertise the
same combination of CL Type and Termination Point Index but include
no Bind Addresses or other parameters. This will cause the CL
instance to no longer be associated with its previous parameters and
thus unusable by neighbors.
Sipos & Deaton Expires 12 March 2027 [Page 18]
Internet-Draft BP SAND September 2026
+===============+=================================================+
| Name | Description |
+===============+=================================================+
| CL Type | This is the type of CL being represented, which |
| | need not be unique when there are multiple |
| | instances of a CL operating on a single node |
| | (with different parameters presumably). |
+---------------+-------------------------------------------------+
| Termination | An index which corresponds to one of the |
| Point Index | underlayer network entries of Table 2 and |
| | distinguishes different instances of a CL type. |
+---------------+-------------------------------------------------+
| Properties below are based on the above unique key columns. |
+---------------+-------------------------------------------------+
| Bind IP | This is the set of IP addresses to which the CL |
| Addresses | instance is bound (for either listening/ |
| | receiving or connecting/sending). This |
| | includes both IPv4 and IPv6 addresses, and can |
| | include the "any endpoint" IPv4 _and_ IPv6 |
| | addresses (0.0.0.0 and :: respectively). |
+---------------+-------------------------------------------------+
| Bind Port | This is the specific transport-layer port |
| Number | number to which the CL instance is bound. This |
| | includes the default port number for each CL |
| | type. |
+---------------+-------------------------------------------------+
| Transport | This indicates whether transport security is |
| Security | required, prohibited, or neither (meaning it |
| | can be opportunistic or conditional) by the CL |
| | instance. |
+---------------+-------------------------------------------------+
| Roles | This indicates the logical roles which this CL |
| | instance is able to perform among "active" or |
| | "passive" options. The definition of an active |
| | role is CL-specific, but is expected to involve |
| | initiating outgoing conversations/connections/ |
| | sessions, while a passive role is expected to |
| | involve listening for incoming ones. A single |
| | CL instance can be capable of both roles. |
+---------------+-------------------------------------------------+
| Type-Specific | Each CL type (see Section 5.4) able to be |
| Parameters... | represented by SAND can have a set of |
| | parameters specific to that type. |
+---------------+-------------------------------------------------+
Table 6: Local Convergence Layer Information Columns
Sipos & Deaton Expires 12 March 2027 [Page 19]
Internet-Draft BP SAND September 2026
3.2. Neighbor Information Bases
An information base for 1-hop neighbor existence and intrinsic
properties is managed separately from other information bases which
represent relationships between nodes. Neighbor information can be
received from any number of ULNs and is aggregated together into
these information bases. In some cases the original received
termination point properties are significant and kept, and in others
they are discarded in order to have a single record representing the
entire neighbor node separate from its ULNs.
The neighbor node information of Table 7 is a logical table of
immediate neighbors of this node. Multiple sources of information
are aggregated together into this table.
+===========+================================================+
| Name | Description |
+===========+================================================+
| Node ID | This is the SAND Singleton EID for the node. |
+-----------+------------------------------------------------+
| Operating | This represents a time-varying operating state |
| Schedule | of the node (as either "on" or "off") as |
| | reported in Resource Advertisement messages. |
+-----------+------------------------------------------------+
Table 7: Neighbor Node Information Columns
An information base for 1-hop neighbor reachability in Table 8 is a
logical table relating 1-hop neighbor nodes from Table 7 to a
specific ULN termination point from Table 2 on which the node is
reachable or on which messages have been received. Due to having
multiple-network connectivity, it is possible to have multiple
records identifying the same 1-hop Neighbor but each will have their
own set of path metrics for a specific network.
+==============+====================================================+
| Name | Description |
+==============+====================================================+
| Local | This is a cross-reference to the unique |
| Termination | index from Table 2, the local termination |
| Point Index | point which has seen messages from the node. |
+--------------+----------------------------------------------------+
| Neighbor | This is a cross-reference to the unique |
| Node ID | identifier from Table 7. |
+--------------+----------------------------------------------------+
| Neighbor | This is the neighbor-provided index for its |
| Termination | termination point corresponding to this |
| Point Index | record. |
Sipos & Deaton Expires 12 March 2027 [Page 20]
Internet-Draft BP SAND September 2026
+--------------+----------------------------------------------------+
| Properties below are based on the above unique key columns. |
+--------------+----------------------------------------------------+
| Latest | This is the latest bundle creation timestamp |
| Timestamps | (Section 4.2.7 of [RFC9171]) for each SAND |
| | Message Type (Section 9.3.1) received from |
| | the neighbor on this termination point, |
| | which is used to filter-out old, out-of- |
| | order messages in Section 4.5. |
+--------------+----------------------------------------------------+
| DNS Name Set | This is the set of DNS Names assigned to the |
| | neighbor node and accessible on the |
| | associated ULN. |
+--------------+----------------------------------------------------+
| IP Address | This is the set of IP addresses assigned to |
| Set | the neighbor node and accessible on the |
| | associated ULN. |
+--------------+----------------------------------------------------+
| Link MTU | This is the configured or discovered MTU of |
| | the first-hop link for the neighbor on the |
| | associated ULN. Similar to the local |
| | interface Link MTU, the actual Path MTU to |
| | and from this peer might be reduced from any |
| | one-hop Link MTU and might be directional. |
+--------------+----------------------------------------------------+
| Reachability | An indication of whether this neighbor has |
| | been only received from (HEARD), or if this |
| | node is present in that neighbor's own 1-hop |
| | neighbor list (SYMMETRIC), or if no messages |
| | have been received after some time (LOST). |
+--------------+----------------------------------------------------+
| Routing | This is the set of routing metrics for |
| Metrics | expected path delay, maximum data rate, and |
| | bit error rate in each direction between the |
| | two termination points. |
+--------------+----------------------------------------------------+
| Timeout | This is the absolute local-clock time when |
| | this record becomes invalid. |
+--------------+----------------------------------------------------+
Table 8: Neighbor Reachability Information Columns
Sipos & Deaton Expires 12 March 2027 [Page 21]
Internet-Draft BP SAND September 2026
+=============+==============================================+
| Name | Description |
+=============+==============================================+
| Local | This is a cross-reference to the unique |
| Termination | index from Table 2, the local termination |
| Point Index | point which has seen messages from the node. |
+-------------+----------------------------------------------+
| Neighbor | This is the SAND Singleton EID for the node. |
| Node ID | |
+-------------+----------------------------------------------+
| Neighbor | This is the neighbor-provided index for its |
| Termination | termination point corresponding to this |
| Point Index | record. |
+-------------+----------------------------------------------+
| Properties below are based on the above unique key |
| columns. |
+-------------+----------------------------------------------+
| CL Type | This is the type of CL being represented, |
| | which need not be unique when there are |
| | multiple instances of a CL operating on a |
| | neighbor node-and-ULN. |
+-------------+----------------------------------------------+
| Properties below are based on the above unique key |
| columns. |
+-------------+----------------------------------------------+
| CL | These are the transport and network |
| Parameters | parameters (see Table 6), as reported in |
| | Convergence Layer (CL) Advertisement |
| | messages. |
+-------------+----------------------------------------------+
Table 9: Neighbor CL Information Columns
3.3. Network Information Bases
This category of information is about an individual node, or pairs of
nodes, independent of the location of the node in the network
topology relative to this node.
An information base for 2-hop neighbors is limited to only those
which have symmetric reachability between that node and one of the
1-hop neighbors from Table 7. This information includes simplified
path metrics between the 1-hop and 2-hop neighbors. Due to having
multiple-network connectivity, it is possible to have multiple
records identifying the same 2-hop Neighbor but each will have their
own set of path metrics for a specific pair of termination points.
Sipos & Deaton Expires 12 March 2027 [Page 22]
Internet-Draft BP SAND September 2026
+============+==============================================+
| Name | Description |
+============+==============================================+
| Node ID | This is the SAND Singleton EID for the node. |
+------------+----------------------------------------------+
| Latest | This is the latest bundle creation timestamp |
| Timestamps | (Section 4.2.7 of [RFC9171]) for each SAND |
| | Message Type (Section 9.3.1) received from |
| | the node, which is used to filter-out old, |
| | out-of-order messages in Section 4.5. |
+------------+----------------------------------------------+
Table 10: Peer Node Information Columns
The network information base does not include any CL information
because that is only needed for reaching 1-hop neighbors. Only
coarse routing metrics are needed between peer nodes outside of 1-hop
neighbors.
+==================+================================================+
| Name | Description |
+==================+================================================+
| Left Node ID | This is a cross-reference to a |
| | unique identifier from Table 10. |
+------------------+------------------------------------------------+
| Left Termination | This is the index for the |
| Point Index | termination point of the left node |
| | corresponding to this record. |
+------------------+------------------------------------------------+
| Right Node ID | This is a cross-reference to a |
| | unique identifier from Table 10. |
+------------------+------------------------------------------------+
| Right | This is the index for the |
| Termination | termination point of the right |
| Point Index | node corresponding to this record. |
+------------------+------------------------------------------------+
| Properties below are based on the above unique key |
| columns. |
+------------------+------------------------------------------------+
| Routing Metrics | This is the set of routing metrics |
| | between the left and right node. |
+------------------+------------------------------------------------+
Table 11: Peer Reachability Information Columns
The Peer Certificate Information of Table 12 is used as a way to
store and cache certificates received via Credential Advertisement
messages and validated in a time-independent way.
Sipos & Deaton Expires 12 March 2027 [Page 23]
Internet-Draft BP SAND September 2026
This means that certificates SHALL only be considered for caching by
a node unless they have been part of a chain validated in accordance
with the procedures of Section 6 of [RFC5280], up to a root CA from
the Trust Anchor information of Table 5, while ignoring validity
times. In addition to the base validation, all end-entity
certificates SHALL only be considered for caching by a node if it
conforms to the certificate profile of Section 4 of
[I-D.ietf-dtn-bpsec-cose]. The Peer Certificate Information SHALL be
de-duplicated from the Trust Anchor information of Table 5 by
ignoring root CA certificates.
+=============+====================================================+
| Name | Description |
+=============+====================================================+
| Node ID | This is the SAND Singleton EID for the node. |
+-------------+----------------------------------------------------+
| Thumbnail | This is x5t or c5t thumbnail of the encoded |
| | certificate, used as a selector. |
+-------------+----------------------------------------------------+
| Subject Key | This is the extracted Subject Key Identifier, from |
| Identifier | Section 4.2.1.2 of [RFC5280], used as a selector. |
+-------------+----------------------------------------------------+
| Properties below are based on the above unique key columns. |
+-------------+----------------------------------------------------+
| Key Usage | This is the extracted Key Usage value, from |
| | Section 4.2.1.3 of [RFC5280], used as a selector. |
+-------------+----------------------------------------------------+
| Validity | This is the extracted Validity interval, from |
| Time | Section 4.1.2.5 of [RFC5280], used as a selector. |
| Interval | |
+-------------+----------------------------------------------------+
| Encoded | This is the DER-encoded X509 certificate contents. |
| Certificate | |
+-------------+----------------------------------------------------+
Table 12: Peer Certificate Information
4. Message Transport
The SAND relies on BPv7 for end-to-end transport, one or more CL for
one-hop transport, and BPSec for message security (both end-to-end
and one-hop).
4.1. SAND Endpoints
Within BPv7, the SAND uses two types of well-known endpoint
identifier (EID) used as source and/or destination for bundles
transported between SAND participants.
Sipos & Deaton Expires 12 March 2027 [Page 24]
Internet-Draft BP SAND September 2026
SAND Singleton EID: This identifies the SAND application on the
participating node and is used as the Source EID for SAND Bundles
from the node. The SAND Singleton EID uses either the DTN or IPN
scheme with a well-known service part as registered in
// TBD and Section 9.2 respectively.
SAND Group EID: This allows participating nodes to receive SAND
Bundles without any pre-configuration. The SAND Group EID uses
the interplanetary multipoint communication (IMC) scheme with a
well-known group number
// TBA1 and service number
// TBA2 as registered in Section 9.1.
Beyond its necessary use as a bundle EID, the SAND Singleton EID also
serves as a unique identifier for the participating node and a unique
and stable correlator for the SAND information bases (Section 3).
4.2. SAND Bundle
For the remainder of this document a bundle with a source matching
the SAND Singleton EID will be referred to as a SAND Bundle. A SAND
Bundle will have a destination of either the SAND Group EID or
another SAND Singleton EID. This is illustrated by the following
text form EID Pattern [I-D.ietf-dtn-eid-pattern].
imc:TBA1.TBA2|ipn:*.*.TBA3
A SAND Bundle has the following basic characteristics:
* The primary block of a SAND Bundle SHALL NOT be marked with the
administrative flag, as the destination is not an administrative
endpoint.
* A SAND Bundle SHALL contain a Hop Count extension block
Section 4.4.3 of [RFC9171] to control the scope of the message. A
message set intended only for 1-hop neighbors uses a Hop Limit of
1. That doesn't prohibit a single outgoing message from being
conveyed over multiple CLs (which is distinct from a single CL
with multicast behavior).
* A SAND Bundle which is being forwarded SHALL contain a previous
node identification in accordance with Section 4.3 This is a more
strict requirement than BPv7 itself because SAND processing
handles 1-hop neighbors differently than more distant nodes.
Sipos & Deaton Expires 12 March 2027 [Page 25]
Internet-Draft BP SAND September 2026
* A SAND Bundle SHALL be secured using BPSec blocks as defined in
Section 4.4 in accordance with [RFC9172]. This document does not
allow for an insecure use of SAND, although prototype
implementations might use insecure transport as an intermediate
step to full SAND conformance.
* The payload block of a SAND Bundle SHALL contain a CBOR sequence
of items. The sequence SHALL consist of SAND version number
followed by one or more bstr items, each containing an encoded
SAND Message as defined in Section 5.
; The actual ADU is the sequence ~sand-adu-seq, not array enveloped
sand-adu-seq = [
version: 1,
+ adu-item
]
adu-item = bstr .cborseq sand-msg
Each encoded SAND Message SHOULD use CBOR core deterministic encoding
requirements from Section 4.2.1 of [RFC8949]. Each message in this
ADU is bstr-wrapped and the Message Type item is the front of the
encoded message, which allows a SAND processor to quickly determine
if the specific message is of interest and skip over it if not.
Because multiple SAND Messages can be sent in a single bundle to
which a Hop Limit applies, all messages in a single bundle need to
have the same restriction (or non-restriction) of Hop Limit.
4.3. Previous Node Identification
In order to properly handle a SAND Bundle, the previous-hop node
needs to be positively identified. This occurs by using one of the
following (in priority order):
1. An authenticated identity (EID) from the CL over which the bundle
was received, when available.
2. An authenticated Previous Node extension block (Section 4.4.1 of
[RFC9171]), which is mandated below when forwarding beyond the
first hop.
3. An authenticated Source Node ID from the Primary block
(Section 4.3.1 of [RFC9171]) when forwarding for the first hop.
A SAND Bundle which is forwarded over a CL which includes an
authenticated identity SHOULD NOT contain a Previous Node extension
block. Otherwise, a SAND Bundle which is forwarded from a node which
is not its source SHALL contain a Previous Node extension block to
Sipos & Deaton Expires 12 March 2027 [Page 26]
Internet-Draft BP SAND September 2026
indicate that the node sending it is not its source. This last
requirement is more strict than Section 4.3.1 of [RFC9171] to ensure
that the forwarding node identity can always be determined for a SAND
bundle.
4.4. Bundle Security
All SAND Bundles SHALL contain a Block Integrity Block (BIB) which
targets the payload block. If that BIB does not include the primary
block as additional authenticated data (AAD) then the BIB SHALL also
target the primary block. The BIB MAY target any other blocks in the
SAND Bundle.
The BIB targeting the payload block SHALL have a Security Source
identifying the same node as the bundle Source EID. Due to node and
network security policy, the Security Source EID MAY be different
than the bundle Source EID. For example, a bundle source of
ipn:974848.10.3 might have an associated Security Source of
ipn:974848.10.0 but both identify the same IPN node.
Any SAND Bundles which contain a Previous Node block SHALL also
contain a BIB which targets that Previous Node block. If that BIB
does not include the primary block as additional authenticated data
(AAD) then the BIB SHALL also target the primary block. The BIB MAY
target any other blocks in the SAND Bundle. Similar to the payload,
any BIB targeting the Previous Node block SHALL have a Security
Source identifying the same node as the Previous Node block.
Any BIB used by SAND SHALL authenticate the bundle source EID and
provide proof-of-possession (PoP) of the private key bound to the
bundle source EID via PKIX certificate. This could be done using a
cryptographic signature as available in the COSE Context
[I-D.ietf-dtn-bpsec-cose] because the primary block Creation
Timestamp functions as a unique nonce for PoP.
A SAND Bundle MAY contain a Block Confidentiality Block (BCB) which
targets the payload block when being transported over an insecure CL
to a known set of recipients. If the BCB acceptors are not using
group keys or known individual-recipient keys, the SAND Bundle SHOULD
NOT be transported over a multicast CL.
When BPSec blocks can contain either certificate contents or
thumbprints, the use of thumbprints is RECOMMENDED along with the use
of Credential Advertisement messages to convey full credentials
between nodes. To avoid the bootstrapping issue described in
Section 8.6, the requirements of that section need to be met by a
participating node.
Sipos & Deaton Expires 12 March 2027 [Page 27]
Internet-Draft BP SAND September 2026
4.5. Superseding Messages
Like MANET discovery and routing protocols, all of the message types
defined in this document contain the full set of data of a particular
type from an advertising node. The processing of any one message
does not rely on incremental changes caused by the message or
processing of any preceding-in-time messages of the same type. This
also makes SAND Message processing idempotent and immune to duplicate
reception, which is an expected property of BPv7 transport.
Because of this, the reception of a message sent earlier than the
last-received message of the same type from the same source can be
completely ignored. This logic applies per-message-type so a single
SAND Bundle can contain some messages which are superseded along with
others which are not. This comparison logic below along with the
BPv7 requirement of timestamp uniqueness provide a strict ordering of
all bundles from a source.
After receiving and processing each SAND Message, a node SHALL record
the Reference Time from the message (using the bundle Creation
Timestamp as alternative) along with the bundle source and message
type. After receiving but before fully processing each SAND Message,
a node SHALL look up the latest processed Reference Time based on the
bundle source and message type. If the received message is identical
to or earlier than the latest processed timestamp it SHALL be ignored
by the application. The timestamp comparison SHALL be based on
ordering of the DTN Time followed by the Sequence Number. Ignoring a
superseded message SHALL NOT be considered a failure of processing
the message, its containing ADU, or its containing bundle.
4.6. Default Convergence Layers
Part of the ability of the SAND to be a _discovery_ protocol is the
need for initial authenticated messaging without any pre-
configuration of any participating node. This is accomplished by
using one or all of the following as needed on each ULN termination
point:
* Sending with UDPCLv2 (Section 5.4.3) to an IPv4 multicast
destination
* Sending with UDPCLv2 (Section 5.4.3) to an IPv6 multicast
destination.
* Sending with BTPU-over-Ethernet (Section 5.4.5) to a multicast
destination.
Sipos & Deaton Expires 12 March 2027 [Page 28]
Internet-Draft BP SAND September 2026
4.6.1. IP Multicast Forwarding
All SAND-participating nodes SHALL listen for UDPCL packets on
default port 4556 (defined in Section 6.2 of [I-D.ietf-dtn-udpcl])
and by joining IP multicast group(s) defined in Section 6.1 of
[I-D.ietf-dtn-udpcl] on all local termination points on which the
entity has an IP address and over which the entity is participating
in discovery. Nodes MAY listen for UDPCL packets destined for other
(unicast) addresses and/or on other ports as needed.
When sending SAND Bundles over an IP-based ULN to a group destination
(see Section 6), participating nodes will use this default UDPCL with
an IP multicast configuration. Because a multicast destination is
used, the advertising node MAY need to condition certain UDP and IP
parameters based on a specific ULN termination point to send from.
The means by which an entity does this is implementation specific.
To send bundles using the UDPCL on a specific local termination
point:
* An implementation-defined Redundancy Factor SHALL be used based on
the specific ULN or termination point.
* The default UDP port 4556 SHALL be used as its destination.
* The default UDP port 4556 SHOULD be used as its source.
* If a specific destination IP address is given that SHALL be used
as its destination.
Otherwise, use one or more of the following:
- If the termination point has an assigned IPv4 address, a UDPCL
transfer SHALL be sent using the IPv4 multicast address for
"All BP Nodes" as its destination.
- If the termination point has an assigned IPv6 address, a UDPCL
transfer SHALL be sent using the IPv6 multicast address for
"All BP Nodes" as its destination.
* A corresponding local IPv4 or IPv6 address for the termination
point SHALL be used as its source.
* Unless there is additional configuration available, the link MTU
SHALL be assumed to be the path MTU for all nodes on that MAC
domain. The advertising node SHALL use CL segmentation as
necessary to adapt the transfer size to the path MTU.
Sipos & Deaton Expires 12 March 2027 [Page 29]
Internet-Draft BP SAND September 2026
4.6.2. Ethernet Multicast Forwarding
All SAND-participating nodes MAY listen for BTP-U messages on default
ethertype by joining multicast group defined in Section 4.2.1 of
[I-D.ek-dtn-ethernet] on all local termination points over which the
entity is participating in discovery.
When sending SAND Bundles over an Ethernet-only ULN to a group
destination (see Section 6), participating nodes will use this
default BTPU-over-Ethernet with a MAC multicast configuration.
Because a multicast destination is used, the advertising node MAY
need to condition certain Ethernet parameters based on a specific ULN
termination point to send from. The means by which an entity does
this is implementation specific.
To send bundles using BTPU-over-Ethernet on a specific local
termination point:
* An implementation-defined Redundancy Factor SHALL be used based on
the specific ULN or termination point.
* If a specific destination MAC address is given that SHALL be used
as its destination.
Otherwise, if the termination point has an assigned Ethernet MAC
address, a BTPU-over-Ethernet transfer SHALL be sent using the
Ethernet multicast address for "All BP Nodes" as its destination.
* A corresponding local MAC address for the termination point SHALL
be used as its source.
* Unless there is additional configuration available, the link MTU
SHALL be assumed to be the path MTU for all nodes on that IP
network. The advertising node SHALL use CL segmentation as
necessary to adapt the transfer size to the path MTU.
5. Message Structure and Types
A SAND Message is the top-level encoded structure exchanged between
nodes. Messages are encoded according to the following general
requirements, which match the CDDL in Figure 2.
A SAND Message SHALL consist of a CBOR sequence of the following:
1. A message type code point of type int16 identifying the type of
the message. The registry of message types is IANA-managed and
defined in Section 9.3.1.
Sipos & Deaton Expires 12 March 2027 [Page 30]
Internet-Draft BP SAND September 2026
2. A map of message metadata (about the message itself) matching the
sand-generic-map rule. All keys in the metadata map SHALL be of
type int16 identifying the purpose of each map value. The
registry of metadata parameters is IANA-managed and defined in
Section 9.3.2.
3. One or more maps of type-specific message data matching the sand-
generic-map rule. All keys in a message data map SHALL be of
type int16 identifying the purpose of each associated map value.
Together each map key and value are referred to as a "parameter"
in this document. Each message type definition must include
details about the parameters in its associated data map,
including what each map represents and which parameters are
required to be present in a map.
sand-msg = $sand-msg .within sand-msg-structure
sand-msg-structure = [
sand-msg-type,
; Metadata about this message
msg-meta: sand-generic-map,
; One or more map containing type-specific parameters
+ msg-data: sand-generic-map
]
sand-msg-type = int16
sand-generic-map = {
* sand-label => sand-value,
}
; Generic map label
sand-label = int16
; Generic map value
sand-value = any
; Signed integer that fits in 16-bit two's complement form
int16 = (-32768 .. 32767) .within int
; Negative part of int16 for private values
priv16 = -32768 .. -1
Figure 2: SAND Message Structure CDDL
The initial message metadata are listed below and correspond with the
CDDL of Figure 3.
Reference Time: This pair uses key 2 and value type dtn-time
Sipos & Deaton Expires 12 March 2027 [Page 31]
Internet-Draft BP SAND September 2026
indicating the absolute time of the start of validity of this
message in the DTN time epoch (see Section 4.2.6 of [RFC9171]).
If no Reference Time is present, the message SHALL be treated as
being valid from the containing bundle's Creation Timestamp. The
Reference Time is also used as the epoch for any schedule
structure in the same message, defined later in this section.
For nodes with low-fidelity timing needs or having a low-precision
clock this value SHOULD be omitted. Otherwise, this value SHALL
be present to avoid any difference between message creation time
and the BPA-sourced Creation Timestamp.
Validity Duration: This pair uses key 3 and value type time-duration
indicating the validity-time of the message contents in
milliseconds. If no Validity Duration is present, the message
SHALL be treated as being valid through the containing bundle's
Lifetime. The Validity Duration SHALL be interpreted as starting
at the Reference Time from the same message, if present, or the
bundle's creation timestamp.
For nodes with low-fidelity timing needs this value SHOULD be
omitted. Otherwise, this value SHALL be sourced from the Validity
Duration of Table 3.
Repetition Interval: This pair uses key 4 and value type time-
duration indicating the periodic interval of the message type in
milliseconds. If no Repetition Interval is present, the message
SHALL NOT be assumed to be sent at a fixed periodic interval.
Sipos & Deaton Expires 12 March 2027 [Page 32]
Internet-Draft BP SAND September 2026
; Generic for a specific message type
; The type-id is from "SAND Message Types" registry
; The data-map defines type-specific labels
sand-msg-gen<type-id, data-map> = [
msg-type: type-id
msg-meta: {
* $$msg-meta-grp,
* priv16 => any
},
+ msg-data: data-map
]
$$msg-meta-grp //= (
2: dtn-time,
)
$$msg-meta-grp //= (
3: time-duration,
)
$$msg-meta-grp //= (
4: time-duration,
)
; Duration in DTN units of milliseconds
time-duration = uint
Figure 3: SAND Message Generic and Metadata
Some of the advertisements defined in this document associate an
optional validity _schedule_ with select data. Because the
advertisements are expected to be sent by nodes periodically on the
order of minutes, the form of this schedule is very simplified and
focused only on a short-term time horizon using the Reference Time of
the same message as its zero-offset epoch. When any schedule is
present within a message the Schedule Reference Time item SHALL be
present in the message and used as the schedule epoch time.
The schedule consists of pairs of duration values, with each pair
representing an interval of time during which the schedule applies
(and the gaps between intervals representing time during which the
schedule does not apply).
schedule = [+ schedule-interval-pair]
schedule-interval-pair = (
offset: time-duration,
length: time-duration .gt 0,
)
Figure 4: Common Schedule CDDL
Sipos & Deaton Expires 12 March 2027 [Page 33]
Internet-Draft BP SAND September 2026
5.1. Data Solicitation
The Data Solicitation message type informs recipients that the sender
desires specific types of SAND data from its peers. A peer entering
a network SHOULD send a Data Solicitation message after an
implementation defined time delay.
The Data Solicitation message SHALL be identified by message type 1.
Each message with this type SHALL contain a single data map. The
message data pairs are listed below and correspond with the CDDL of
Figure 5.
Message Type List: This pair uses key -1 and value of an array of
Message Type (int16) values. The Message Type List SHALL contain
at least one item. Each Message Type List item SHALL be unique
(no duplication). The order of items within the array SHALL NOT
be treated as significant by the recipient.
Each Data Solicitation message SHALL contain a Message Type List.
The Data Solicitation message SHALL NOT be used to request a Data
Solicitation message type. Any solicitation of a Data Solicitation
message type SHALL be ignored by the receiver.
$sand-msg /= sand-msg-gen<1, {+ $$solicit-grp }>
; Message type list
$$solicit-grp //= (
-1: [+ sand-msg-type]
)
Figure 5: Data Solicitation Message CDDL
5.2. Credential Advertisement
The Credential Advertisement message contains identity-binding
credentials which identify the advertising node and contain key
material for different security purposes. Each credential is itself
verifiable up to a trusted root which is assumed to be configured in
receivers of the advertisement.
Credentials in this message are sourced from the Identity Information
Base of Table 4. Each credential can contain validity time intervals
which have no strict relationship to the validity time of the
containing advertisement message or the lifetime of the containing
bundle, and do not relate to any SAND-form of schedule. The creator
of a Credential Advertisement message MAY filter-in or filter-out
credentials based on their validity time.
Sipos & Deaton Expires 12 March 2027 [Page 34]
Internet-Draft BP SAND September 2026
Each message with this type SHOULD contain credentials valid at the
time of creation. Each message with this type MAY contain
credentials valid only in the past or future. Those non-present-time
credentials could be needed to verify old signatures or to pre-load
future rollover keys respectively.
The Credential Advertisement message SHALL be identified by message
type 2. Each message with this type SHALL contain a single data map.
// TBD: one map per purpose? The message data pairs are listed below
and correspond with the CDDL of Figure 6.
X509 Bag: This pair uses key -1 and value type COSE_X509 for COSE
[RFC9360] to convey PKIX certificates as an unordered "bag". Each
bag MAY contain multiple end-entity certificates identifying the
advertising node with different validity time or different
extension items. Each bag SHOULD contain intermediate CA
certificates up to, but not including, the root CA needed to
verify all end-entity certificates.
Each Credential Advertisement SHALL contain an at least one end-
entity credential identifying the advertising node. A Credential
Advertisement SHALL NOT contain any end-entity credential that does
not identify the advertising node.
The Credential Advertisement message is populated in-part using the
data identified in Table 4, part of the Local Node Information Base
described in Section 3.1.
$sand-msg /= sand-msg-gen<2, {+ $$cred-grp }>
; X509 Bag
$$cred-grp //= (
-1: COSE_X509 ; From [RFC 9360]
)
Figure 6: Credential Advertisement Message CDDL
5.3. Underlayer Network (ULN) Advertisement
The ULN Advertisement message contains information about the ULN
termination points, providing recipients information about
communicating with the advertising node via the underlayer. Each ULN
Advertisement message SHALL contain at least the termination point on
which a SAND Bundle has been sent. Each ULN Advertisement message
MAY contain any other termination points on the node. It is an
implementation matter to choose which underlayer networks are
advertised in a particular message.
Sipos & Deaton Expires 12 March 2027 [Page 35]
Internet-Draft BP SAND September 2026
Each ULN Advertisement message SHALL be transported with a Hop Limit
of 1. Only 1-hop neighbors are capable of using underlayer network
parameters so there is no need to forward this to any other nodes in
the network.
The ULN Advertisement message SHALL be identified by message type 8.
Each message with this type SHALL contain a separate data map for
each ULN termination point being advertised. The generic parameters
for each ULN are listed below and correspond with the CDDL of
Figure 7. These parameters are also in the IANA registry defined in
Section 9.3.3.
Termination Point Index: This pair uses key 0 and value type uint.
This index uniquely identifies the termination point within the
advertising node, and allows correlating changes to its properties
across time.
Validity Schedule: This pair uses key 1 and value type schedule as
defined in Figure 4. Each time at which the schedule is valid
indicates when the termination point is expected to be usable for
traffic to and from the ULN. If this parameter is absent the
termination point SHALL be treated as always valid (within the
validity schedule of the node itself, see Section 5.5).
$sand-msg /= sand-msg-gen<8, {+ $$uln-grp }>
; Termination Point Index
$$uln-grp //= (
0: uln-tp-ix-value
)
uln-tp-ix-value = uint
; Validity Schedule
$$uln-grp //= (
1: schedule,
)
Figure 7: ULN Advertisement message CDDL
Each data map in this message SHALL have a unique Termination Point
Index parameter.
Sipos & Deaton Expires 12 March 2027 [Page 36]
Internet-Draft BP SAND September 2026
Each termination point being advertised SHOULD be reachable via the
ULN over which the enveloping message is sent. Advertising ULN
termination points which are not reachable by receiving SAND
participants is simply a waste of advertising resources and possibly
by resources on other participants trying to determine reachability.
An implementation could simplify its internal logic by advertising
the same full set of termination points to all of its neighbors,
regardless of reachability.
Each different ULN termination point (TP) is likely to have varying
parameter sets, with items corresponding to parameters specific to a
termination point and its associated network technology. The
parameters defined in this document are focused on IP-based
underlayer networks because this protocol is a product of the IETF.
Other ULN technologies can be supported by SAND to advertise other
forms of network names, addresses, and/or protocol identifiers by
either registering well-known type-specific parameters or using the
private use range of type-specific parameters.
5.3.1. IP-Related ULN Parameters
There are several common ULN parameters related to IP networks: a DNS
name or IPv4/IPv6 address used to communicate with the node, and
information common to links using that termination point.
| When applied to IP networks, each TP corresponds with an IP
| "interface" [RFC8200] [RFC8344] and all TP parameters are
| interpreted as applying to that single interface.
The IP-related parameters are listed below and correspond with the
CDDL of Figure 8.
DNS Name List: This pair uses key 2 and value type tstr or array of
tstr from DNS names in accordance with [RFC1034]. If this
parameter is absent the node SHALL be treated as not having a DNS
name on the ULN.
IP Address List: This pair uses key 3 and value type ip-addr-ctr
from IPv4 or IPv6 addresses encoded as 4-byte or 16-byte strings
respectively. The encodings are consistent with the types
ipv4-address and ipv6-address from Section 5 of [RFC9164]). If
this parameter is absent the node SHALL be treated as not having a
specific IP address on the ULN.
This address list MAY contain link-local addresses if the sender
has an expectation that CL instances (Section 5.4) will be usable
over the associated IP endpoint.
Sipos & Deaton Expires 12 March 2027 [Page 37]
Internet-Draft BP SAND September 2026
MAC Address List: This pair uses key 5 and value type mac-addr-ctr
from EUI-48 or EUI-64 addresses encoded as 6-byte or 8-byte
strings respectively. The encodings are consistent with the
unwrapped CBOR tag 48 from Section 2.4 of [RFC9542]). If this
parameter is absent the node SHALL be treated as not having a
specific MAC address on the ULN.
Link MTU: This pair uses key 4 and value type mtu-size indicating
the link MTU, as seen by the termination point of the advertising
node, in units of octets. This value SHALL adhere to the lower
limit of 68 octets for IPv4 [RFC791] or 1280 for IPv6 [RFC8200]
when those technologies are used on the termination point. Other
ULN technologies will still have an MTU value but with a different
lower bound. If this parameter is absent then other means of
configuring or estimating link or path MTU are needed.
Sipos & Deaton Expires 12 March 2027 [Page 38]
Internet-Draft BP SAND September 2026
; DNS Name List
$$uln-grp //= (
2: dns-name-ctr
)
dns-name-ctr = dns-name / [+ dns-name]
; Should agree with actual DNS restrictions in [RFC 1034]
dns-name = tstr .abnf ("subdomain" .det dns-name-syntax)
dns-name-syntax = '
subdomain = label *("." label)
label = letter [[ldh-str] let-dig]
ldh-str = let-dig-hyp *(let-dig-hyp)
let-dig-hyp = let-dig / "-"
let-dig = letter / digit
letter = %x41-5A / %x61-7A
digit = %x30-39
'
; IP Address List
$$uln-grp //= (
3: ip-addr-ctr
)
ip-addr-ctr = ip-address / [+ ip-address]
; Agrees with untagged bstr contents from [RFC 9164]
ip-address = ipv4-address / ipv6-address
ipv4-address = bstr .size 4
ipv6-address = bstr .size 16
; MAC Address List
$$uln-grp //= (
5: mac-addr-ctr
)
mac-addr-ctr = mac-address / [+ mac-address]
; Agrees with untagged bstr contents from [RFC 9542]
mac-address = eui48-address / eui64-address
eui48-address = bstr .size 6
eui64-address = bstr .size 8
; Link MTU
$$uln-grp //= (
4: mtu-size
)
mtu-size = uint .gt 0
Figure 8: IP Termination Point Parameters CDDL
Sipos & Deaton Expires 12 March 2027 [Page 39]
Internet-Draft BP SAND September 2026
5.4. Convergence Layer (CL) Advertisement
The CL Advertisement message indicates CL entities operating on the
node sending the message, including both active and passive roles
where applicable, and any parameters necessary for peers to make use
of those CL instances. Each instance can also have an associated
validity schedule.
Each CL Advertisement message SHALL be transported with a Hop Limit
of 1. Only 1-hop neighbors are capable of using CL data so there is
no need to forward this to any other BP nodes in the network.
The CL Advertisement message SHALL be identified by message type 3.
Each message with this type SHALL contain a separate data map for
each CL instance being advertised. The generic CL parameters are
listed below and correspond with the CDDL of Figure 9. These
parameters are also in the IANA registry defined in Section 9.3.4.
CL Type: This pair uses key 0 and value type int16 identifying the
type of CL being defined. Possible CL Type values are defined
Section 9.3.4 where, similar to message types, positive values are
for well-known CL types and negative values are for private or
experimental types.
Termination Point Index: This pair uses key 1 and value type uint.
This index correlates to a Termination Point entry from the
Underlayer Network (ULN) Advertisement from the same advertising
node.
Transport Security Required: This pair uses key 5 and value type
bool indicating whether transport security is required (when true)
or prohibited (when false). Details about how to interpret this
common parameter are CL-type-specific. If this parameter is
absent there is no information about the required policy.
Roles: This pair uses key 6 and value type uint containing flags
indicating which CL-specific roles the advertising node can act
as. Details about how to interpret this common parameter are CL-
type-specific.
The role flag at bit 0 indicates that the node can act in a
passive role. The role flag at bit 1 indicates that the node can
act in an active role. If this parameter is absent it is assumed
to be 0b11 (the node can be either role).
Sipos & Deaton Expires 12 March 2027 [Page 40]
Internet-Draft BP SAND September 2026
The definition of an "active role" is CL-specific but is expected
to involve initiating outgoing conversations/connections/sessions
rather than listening for incoming ones. Even when acting in the
active role only, the CL MAY still be bound to a specific port
number.
$sand-msg /= sand-msg-gen<3, cl-recv>
cl-recv = $cl-recv .within sand-generic-map
; Generic to provide base CL parameters
; The cl-type is from "SAND CL Types" registry
cl-base<cl-type> = (
0: cl-type .within int16,
cl-tp-ix,
$$cl-common-grp
)
; Corresponding ULN TP Index
cl-tp-ix = (
1: uln-tp-ix-value
)
; Security Required, if any, for this CL
$$cl-common-grp //= (
5: bool
)
; CL-type-defined roles
$$cl-common-grp //= (
6: uint .bits cl-role-flags
)
cl-role-flags = &(
passive: 0,
active: 1,
)
Figure 9: CL Advertisement Message CDDL
Each CL Advertisement SHALL contain at least one CL instance. A CL
instance MAY have a non-unique CL Type parameter, indicating multiple
instances of a particular CL are operating on a node. Each CL
instance SHOULD be reachable via the ULN (and its termination point)
over which the enveloping message is sent. Advertising CL instances
which are not reachable by receiving SAND participants is simply a
waste of advertising resources and possibly by resources on other
participants trying to determine reachability.
Sipos & Deaton Expires 12 March 2027 [Page 41]
Internet-Draft BP SAND September 2026
It is an important distinction that the CL parameterization is about
the capability of receiving bundles on the advertising node. It is
not about ability of the node to forward bundles, which may in fact
be more broad than its ability to receive. For example, in the
situation where a node has an ephemeral IP address and no DNS name
that node may not listen with any CL yet, because some CLs are
bidirectional, it may have symmetric (BP layer) connectivity to some
set of peer nodes. Even in that case there is still value in
discovering the presence of the non-listening node because there is
the potential for a contact (coming from that node) to allow bundle
routes to other nodes "behind" that non-listening node.
5.4.1. IP-Related CL Parameters
These are several common CL parameters related to IP-based or IP-
related transports.
Bind Port Number: This pair uses key 4 and value type uint
indicating the transport-layer port number to which the CL is
bound. If this parameter is absent, an IP-based CL type shall be
treated as using the default (_i.e._, IANA assigned) port number
SHALL for that type.
IP Bind List: This pair uses key 3 and value type ip-addr-ctr from
IPv4 or IPv6 addresses encoded as 4-byte or 16-byte strings
respectively. Each address represents a local destination to
which the CL is bound in order to receive traffic. If this
parameter is absent, an IP-based CL type SHALL be treated as if it
was bound to the "any endpoint" IPv4 _and_ IPv6 addresses (0.0.0.0
and :: respectively). If a node has either IPv4 or IPv6 addresses
assigned but is not listening on the associated address family,
this list SHALL contain the associated "any destination" bind
address on which it _is_ listening.
IP Multicast List: This pair uses key 5 and value type ip-addr-ctr
from IPv4 or IPv6 addresses encoded as 4-byte or 16-byte strings
respectively. Each address represents a multicast group for which
the CL is a member in order to receive traffic. If this parameter
is absent, an IP-based CL type SHALL be treated as if it does not
participate in any multicast group.
Sipos & Deaton Expires 12 March 2027 [Page 42]
Internet-Draft BP SAND September 2026
; Bind port number
$$cl-common-grp //= (
4: 1 .. 0xFFFF
)
; IP bind address(es)
$$cl-common-grp //= (
3: ip-addr-ctr
)
; IP multicast address(es)
$$cl-common-grp //= (
5: ip-addr-ctr
)
Figure 10: IP-Related CL Parameters CDDL
A ULN Advertisement (Section 5.3) from a node can contain any
combination of DNS Name List, IP Address List, MAC Address List, and
Link MTU items. Because of this individual CL Instances MAY contain
additional DNS names and/or addresses specific to that instance.
Duplication between underlayer DNS name or address and CL instance
values SHOULD be avoided, but has no effect on the interpretation of
the values.
If multiple values are present in IP Address List for a CL it is an
implementation matter to choose which one to attempt first, and
whether multiple attempts are made sequentially or simultaneously.
One possible algorithm to handle multiple network addresses for the
same service is Happy Eyeballs [RFC8305], but details are likely to
be CL-type-specific.
5.4.2. TCPCLv4 Parameters
This CL type specifically refers to the TCP Convergence Layer (TCPCL)
version 4 [RFC9174]. This CL type SHALL be identified by code point
1.
If the Port Number parameter is absent, the default TCPCL port 4556
SHALL be used. The Transport Security Required parameter SHALL
indicate both the Contact Header USE_TLS flag and the post-
negotiation policy enforcement (_i.e._, when the session will be
disallowed). The Role parameter SHALL indicate whether the TCPCL
entity on the node can function as either active or passive or both.
The CL-specific parameters are listed below and correspond with the
CDDL of Figure 11. These are also registered in the IANA registry
defined in Section 9.3.4.
Message Type Support: This pair uses key -1 and value type of an
Sipos & Deaton Expires 12 March 2027 [Page 43]
Internet-Draft BP SAND September 2026
array of TCPCL message type code points indicating which types the
advertising node supports. Well-known code points are managed in
the "Bundle Protocol TCP Convergence-Layer Version 4 Message
Types" registry of [IANA-BP]. All nodes SHALL include the minimum
support for types 0x01 through 0x07 inclusive.
Session Extension Type Support: This pair uses key -2 and value type
of an array of TCPCL session extension type code points indicating
which types the advertising node supports. Well-known code points
are managed in the "Bundle Protocol TCP Convergence-Layer Version
4 Session Extension Types" registry of [IANA-BP]. There is no
required minimum session extension support defined for TCPCL.
Transfer Extension Type Support: This pair uses key -3 and value
type of an array of TCPCL transfer extension type code points
indicating which types the advertising node supports. Well-known
code points are managed in the "Bundle Protocol TCP Convergence-
Layer Version 4 Transfer Extension Types" registry of [IANA-BP].
All nodes SHALL include the minimum transfer extension support for
TCPCL as type 0x01.
$cl-recv /= {
cl-base<1>,
? tcpcl-msg-support,
? tcpcl-sessext-support,
? tcpcl-xferext-support
}
tcpcl-msg-support = (
-1: [+ tcpcl-msg-type]
)
tcpcl-msg-type = 0 .. 0xFF
tcpcl-sessext-support = (
-2: [+ tcpcl-ext-type], ; session extension types from [IANA-BP]
)
tcpcl-xferext-support = (
-3: [+ tcpcl-ext-type], ; transfer extension types from [IANA-BP]
)
tcpcl-ext-type = 0 .. 0xFFFF
Figure 11: TCPCLv4 Parameters CDDL
5.4.3. UDPCLv2 Parameters
This CL type specifically refers to the UDPCL Version 2 of
[I-D.ietf-dtn-udpcl]. This CL type SHALL be identified by code point
2.
Sipos & Deaton Expires 12 March 2027 [Page 44]
Internet-Draft BP SAND September 2026
If the Port Number parameter is absent, the default UDPCL port 4556
SHALL be used. The Transport Security Required parameter SHALL
indicate the need for DTLS security when receiving CL messages.
The CL-specific parameters are listed below and correspond with the
CDDL of Figure 12. These are also registered in the IANA registry
defined in Section 9.3.4.
Extension Support: This pair uses key -1 and value type of an array
of UDPCL extension code points indicating which extensions the
advertising node supports. Well-known code points are managed in
the "UDPCLv2 Extensions" registry of [IANA-BP]. This information
is equivalent to the contents of Section 3.5.1 of
[I-D.ietf-dtn-udpcl] without needing to operate the actual CL.
$cl-recv /= {
cl-base<2>,
? udpcl-ext-support,
}
udpcl-ext-support = (
-1: [+ ext-key], ; ext-key from [I-D.ietf-dtn-udpcl]
)
Figure 12: UDPCLv2 Parameters CDDL
5.4.4. LTPCL-over-UDP Parameters
While there is no IETF specification for transporting BPv7 bundles
over the Licklider Transport Protocol (LTP) [RFC5326], the
Consultative Committee for Space Data Systems (CCSDS) profile of BPv7
includes a specification for this in Appendix
// TBD of [CCSDS-BPv7] using Client Service ID (CSID) value 5.
Additionally the LTP-over-UDP binding is defined in Section 3.3 of
[RFC7122]. This CL type SHALL be identified by code point 3.
There is also a CCSDS experimental BPv7 specification which has
allocated LTP CSID value 4 for aggregating BP PDUs. The use of LTP
CSID 4 to transport one or more BP PDUs as defined in Appendix B2.1.4
of [CCSDS-BPv7-OB] SHALL be identified by code point 252.
While there is no concrete specification for transporting BPv7
bundles over LTP using other LTP CSID values [IANA-LTP] [SANA-LTP],
this specification makes an allocation to allow a node to advertise
that it is using other combinations of protocols. The use of LTP
CSID 1 to transport single BP PDUs as defined for BPv6 in Appendix B3
of [CCSDS-BPv6] SHALL be identified by code point 253.
Sipos & Deaton Expires 12 March 2027 [Page 45]
Internet-Draft BP SAND September 2026
If the Port Number parameter is absent, the default LTP port 1113
SHALL be used. The BPv7 use of LTP does not specify a transport-
layer security mechanism.
The CL-specific parameters are listed below and correspond with the
CDDL of Figure 13. These are also registered in the IANA registry
defined in Section 9.3.4.
Engine ID: This pair uses key -1 and value type uint to advertise
the specific Engine ID used by this LTP entity when sending and
correlating LTP segments. Knowing the Engine ID of a peer before
initiating or responding to LTP sessions is necessary for some
implementations.
Extension Support: This pair uses key -2 and value type of an array
of LTP extension tag code points indicating which tags the
advertising node supports. Well-known code points are managed in
the "LTP Extension Tags" registry of [IANA-LTP]. There is no
required minimum extension support defined for LTP.
$cl-recv /= {
cl-base<(3/252/253)>,
? ltp-engine-id,
? ltp-ext-support,
}
ltp-engine-id = (
-1: uint,
)
ltp-ext-support = (
-2: [+ uint]
)
Figure 13: LTPCL Parameters CDDL
5.4.5. BTPU-over-Ethernet Parameters
This CL type specifically refers to the transport of BTP-U PDUs
[I-D.ietf-dtn-btpu] in Ethernet frames [I-D.ek-dtn-ethernet]. This
CL type SHALL be identified by code point 4.
This CL type does not make use of any of the IP-related parameters
(Section 5.4.1) or the Transport Security Required parameter.
The CL-specific parameters are listed below and correspond with the
CDDL of Figure 14. These are also registered in the IANA registry
defined in Section 9.3.4.
Sipos & Deaton Expires 12 March 2027 [Page 46]
Internet-Draft BP SAND September 2026
// This parameterization assumes there is a single well-known
// ethertype assigned by [I-D.ek-dtn-ethernet] and used by all
// implementations.
// Is there a need to expose transfer ID window size for receiver?
// Would it affect sending behavior?
Hint Support: This pair uses key -1 and value type of an array of
BTP-U Hint Type code points indicating which extensions the
advertising node supports. Well-known code points are managed in
the "BTPU Hint Types" registry of [IANA-BP]. This information
indicates support without needing to operate the actual CL.
MAC Bind List: This pair uses key -2 and value type mac-addr-ctr
from EUI-48 or EUI-64 addresses encoded as 6-byte or 8-byte
strings respectively. Each address represents a local destination
to which the CL is bound in order to receive traffic. If this
parameter is absent, the CL instance SHALL be treated as if it was
bound to the "any endpoint" MAC address(es).
MAC Multicast List: This pair uses key -3 and value type mac-addr-
ctr from EUI-48 or EUI-64 addresses encoded as 6-byte or 8-byte
strings respectively. Each address represents a multicast group
for which the CL is a member in order to receive traffic. If this
parameter is absent, the CL instance SHALL be treated as if it
does not participate in any multicast group.
$cl-recv /= {
cl-base<4>,
* $$cl-btpuoe-grp,
}
; Hint Type support
$$cl-btpuoe-grp //= (
-1: [+ btpu-hint]
)
btpu-hint = 0x00 .. 0x7F
; MAC bind address(es)
$$cl-btpuoe-grp //= (
-2: mac-addr-ctr,
)
; MAC multicast address(es)
$$cl-btpuoe-grp //= (
-3: mac-addr-ctr,
)
Figure 14: BTPUoE Parameters CDDL
Sipos & Deaton Expires 12 March 2027 [Page 47]
Internet-Draft BP SAND September 2026
5.4.6. TCPCLv3 Parameters
While there is no concrete specification for transporting BPv7
bundles over TCPCL version 3 [RFC7242], this specification makes an
allocation to allow a node to advertise that it is using this
combination of protocols. This CL type SHALL be identified by code
point 254.
If the Port Number parameter is absent, the default TCPCL port 4556
SHALL be used. The TCPCL version 3 does not specify a transport-
layer security mechanism.
$cl-recv /= {
cl-base<254>,
}
Figure 15: TCPCLv3 Parameters CDDL
5.4.7. Experimental UDPCL Parameters
While there is no concrete specification for transporting BPv7
bundles over the experimental UDPCL [RFC7122], this specification
makes an allocation to allow a node to express that it is using this
combination of protocols. This CL type SHALL be identified by code
point 255.
$cl-recv /= {
cl-base<255>,
}
Figure 16: Experimental UDPCL Parameters CDDL
5.5. Resource Advertisement
The Resource Advertisement message is used to indicates the node's
resource forecast (operating state and storage) for some near time
horizon. This corresponds to a node-scope schedule of Section 2.3.1
of [I-D.ietf-tvr-requirements] and these resources relate to all of
the CLs exposed in the Convergence Layer (CL) Advertisement message
from the same node. Per the definitions in Section 5, each schedule
applies within the Validity Duration of the message.
Resource Advertisement messages are populated using the data in
Table 1, part of the Local Node Information Base described in
Section 3.1.
Sipos & Deaton Expires 12 March 2027 [Page 48]
Internet-Draft BP SAND September 2026
The Resource Advertisement message SHALL be identified by message
type 4. Each message with this type SHALL contain a single data map.
The message parameters are listed below and correspond with the CDDL
of Figure 17. These parameters are also in the IANA registry defined
in Section 9.3.5.
Operating Schedule: This pair uses key 1 and value of a schedule
item as defined in Figure 4. Each time at which the schedule is
valid indicates when the node is forecast to be operating. The
absence of this parameter SHALL be interpreted as the node
expected to be always operating.
$sand-msg /= sand-msg-gen<4, {+ $$resource-grp }>
; Operating schedule
$$resource-grp //= (
1: schedule,
)
Figure 17: Resource Advertisement CDDL
5.6. Local Topology Advertisement
The Local Topology Advertisement message allows a participating node
to enumerate the 1-hop neighbors with which the advertising node can
communicate (via some unspecified CL or combined aggregate of CLs).
Each neighbor is identified by its SAND Singleton EID which is a
unique across a BP network.
Each 1-hop neighbor (peer) is associated with a reachability status
and a set of communication metrics similar to the behavior of MANET
NHDP [RFC6130]. The source of the metrics are not specified by this
document, but might come from estimating based on SAND traffic
exchanged with the peer. In addition, some of the data comprising
the Local Topology Advertisement message is sourced from the Neighbor
Information Base, such as Reachability and Path Metrics as discussed
in Table 8.
The Local Topology Advertisement message SHALL be identified by
message type 5. Each message with this type SHALL contain a separate
data map for each 1-hop neighbor being advertised. The message
parameters are listed below and correspond with the CDDL of
Figure 18. These parameters are also in the IANA registry defined in
Section 9.3.6.
Node ID: This pair uses key 0 and value type embed-eid-structure
from Section 4 of [I-D.ietf-dtn-eid-pattern] representing the
unique SAND Singleton EID for the neighbor node.
Sipos & Deaton Expires 12 March 2027 [Page 49]
Internet-Draft BP SAND September 2026
Reachability: This pair uses key 1 and value type uint containing an
enumerated value indicating the status of communication with the
neighbor. The value is one of the following:
HEARD (1): This means a message has been received from the peer
but this node has not yet appeared in the local topology
advertised by that peer.
SYMMETRIC (2): This means that this node is present in the local
topology advertised by the peer, so at least one message has
been received in both directions between the nodes.
LOST (3): This means that no message has been received from the
peer within an implementation-defined timeout interval.
Routing Metrics List: This pair uses key 2 and value type of an
array of Routing Metrics related to the neighbor node. Each
Routing Metrics List SHALL contain at least one item. Each
Routing Metrics List item SHALL have a unique combination of
Routing Type, (optional) Termination Point Index, Direction, and
(optional) Validity Schedule parameters.
$sand-msg /= sand-msg-gen<5, {+ $$localtopo-grp }>
; Node ID
$$localtopo-grp //= (
; Type from [I-D.ietf-dtn-eid-pattern]
0: embed-eid-structure
)
; Reachability
$$localtopo-grp //= (
1: &(
HEARD: 1,
SYMMETRIC: 2,
LOST: 3,
)
)
; Routing Metrics List
$$localtopo-grp //= (
2: [+ nbr-metrics]
)
Figure 18: Local Topology Advertisement CDDL
Sipos & Deaton Expires 12 March 2027 [Page 50]
Internet-Draft BP SAND September 2026
Each data map represents a combination of a 1-hop neighbor node, its
direct parameters, and routing metrics associated with traffic from
and to that node. Each message with this type SHALL contain at least
one data map (neighbor). Each data map in this message SHALL have a
unique Node ID parameter.
5.6.1. Routing Metrics
Each Routing Metrics map is associated with a specific routing type
and a set of metrics for BP and underlayer traffic from and to that
node. Some of the Routing Metrics parameters are common across all
algorithms and some are inputs to a specific routing algorithm.
It is expected that two nodes which each see the other as a 1-hop
neighbor will provide opposite and similar metrics between each
other. If the mutual neighbor nodes don't support the same routing
algorithms, the total set of metrics will be different. Because
there is no specific synchronization between neighbors, even when
mutual neighbors advertise the same metric items there is no
guarantee or expectation that they will have the same values. It is
an implementation detail for how to reconcile routing metrics between
mutual neighbors (_e.g._ by averaging between neighbors'
advertisements) when needed for input to routing algorithms.
The common routing metrics are listed below and correspond with the
CDDL of Figure 19. These are also registered in an IANA registry
defined in Section 9.3.6.
Routing Type: This pair uses key 0 and value type int16 identifying
a specific routing algorithm. The registry of SAND routing types
is IANA-managed and defined in Section 9.3.6.
Termination Point Index: This pair uses key 3 and value type uint
identifying a specific termination point index (local to the
advertising node) with which these metrics are associated. This
can correlate with other Termination Point Index values expressed
through Underlayer Network (ULN) Advertisement messages.
Including these index values on metrics allows a node to express
having multiple paths to reach a 1-hop neighbor, each with
different metrics.
Direction: This pair uses key 1 and value type uint containing an
enumerated value indicating the link direction associated with the
metrics in the item. The value is one of the following:
TRANSMIT: This value 1 means the metrics are associated with
traffic from the advertising node to the parent peer node.
Sipos & Deaton Expires 12 March 2027 [Page 51]
Internet-Draft BP SAND September 2026
RECEIVE: This value 2 means the metrics are associated with
traffic to the advertising node from the parent peer node.
Validity Schedule: This pair uses key 2 and value type schedule as
defined in Figure 4. Each time at which the schedule is valid
indicates when communication is expected to be available (in the
associated Direction).
This is different than the resource schedule of the node itself,
and represents availability of the shared network between the
advertising node and this peer.
nbr-metrics = $nbr-metrics .within sand-generic-map
; Generic for reachability metrics
; The rtg-type is from "SAND Routing Types" registry
nbr-metrics-base<rtg-type> = (
0: rtg-type .within int16,
metrics-tp-ix,
metrics-direction,
* $$nbr-metrics-common-grp,
)
; Corresponding ULN TP Index
metrics-tp-ix = (
3: uln-tp-ix-value
)
; Direction relative to neighbor
metrics-direction = (
1: &(
TRANSMIT: 1,
RECEIVE: 2,
)
)
; Validity Schedule
$$nbr-metrics-common-grp //= (
2: schedule
)
Figure 19: Routing Metrics Structure and Parameters CDDL
5.6.1.1. SABR/CGR
This routing type captures metrics needed for input to the Schedule-
Aware Bundle Routing (SABR) algorithm [CCSDS-SABR] defined by CCSDS.
Sipos & Deaton Expires 12 March 2027 [Page 52]
Internet-Draft BP SAND September 2026
| These parameters function, in a limited form, as a way to
| represent a short-time-horizon contact plan between the
| advertising node and the neighbor node. These metrics are not
| expected to be used for defining or distributing long-term
| plans which greatly exceed the Validity Duration of the
| containing SAND message.
The SABR routing metrics are listed below and correspond with the
CDDL of Figure 20. These are also registered in an IANA registry
defined in Section 9.3.6. Metrics parameters with negative keys are
delegated to an algorithm-specific registry.
Maximum Data Rate: This pair uses key -1 and value type unsigned-
fraction indicating the expected maximum data rate of traffic in
octets per second. This data rate is measured at the underlying
link layer, not just the throughput of BP PDUs.
Delay: This pair uses key -2 and value type time-duration indicating
the expected one-way light time (OWLT) of traffic in milliseconds.
This delay is measured between the two BP nodes so it is more than
just the free-space propagation delay, it also includes any
expected underlay, CLA, and BPA processing time.
Bit Error Rate: This pair uses key -3 and value type unsigned-
fraction indicating the expected bit error rate (BER) of traffic
as a ratio. This BER is measured at the underlying link layer and
includes errors which are caught by underlayer checksums (_e.g._,
where the CL segment/frame is lost).
Sipos & Deaton Expires 12 March 2027 [Page 53]
Internet-Draft BP SAND September 2026
$nbr-metrics /= {
nbr-metrics-base<0>,
? nbr-rtm-datarate,
? nbr-rtm-delay,
? nbr-rtm-ber
}
; Maximum data rate in bytes-per-second
nbr-rtm-datarate = (
-1: unsigned-fraction
)
; One-way delay
nbr-rtm-delay = (
-2: time-duration
)
; Estimated BER as a ratio
nbr-rtm-ber = (
-3: unsigned-fraction
)
; Same structure as tag #4 "decimal fraction" but limited in domain
unsigned-fraction = [
exp: (-20 .. 20) .within int,
mantissa: uint,
]
Figure 20: SABR Routing Metrics CDDL
For conciseness of encoding, the unsigned-fraction values SHOULD
limit the mantissa to less than 8 bits. This limits the precision of
encoded values but because these are all rough estimates that should
be sufficient for contact planning purposes.
There is no required combination of RX and TX parameters for any
peer. Because these might be estimated from traffic or some kind of
underlying discovery protocol (_e.g._, DLEP) it is possible to obtain
estimates for some subset of these but not all of them.
For both RX and TX Data Rate values, the rate is averaged over the
entire valid time, so it is actually average-of-maximum rate.
Another way to think of it is that the sum-total valid time duration
multiplied by the data rate value will yield a total data volume that
is transferable from (or to) the peer within the validity duration.
Sipos & Deaton Expires 12 March 2027 [Page 54]
Internet-Draft BP SAND September 2026
5.7. Router Advertisement
The Router Advertisement message exposes parameters about the
advertising node's willingness to route bundles with different
categories of destination EIDs.
// Each willingness to associate with an EID pattern?
The Router Advertisement message SHALL be identified by message type
6. The message parameters are listed below and correspond with the
CDDL of Figure 21.
Willingness for Singleton: This pair uses key 1 and value type uint
representing a willingness to route (see later definition) for
bundles with a singleton destination EID. The absence of this
parameter SHALL be interpreted as a willingness of zero (not
willing).
Willingness for Multipoint: This pair uses key 2 and value type uint
representing a willingness to route (see later definition) for
bundles with a non-singleton destination EID. The absence of this
parameter SHALL be interpreted as a willingness of zero (not
willing).
Attached Networks: This pair uses key 3 and value type bstr
embedding an EID Pattern as defined in Section 4 of
[I-D.ietf-dtn-eid-pattern]. The value contains the set of
endpoints not participating in SAND but for which the advertising
node is willing to route. The value MAY be an any-scheme pattern
or contain an any-SSP pattern.
Each willingness value is an integer in the inclusive range from 0
through 6, where 0 indicates the node will never route for that type
and the values 1 through 6 indicate an increasing level of
willingness. In the absence of additional configuration, a node
which is willing to route SHALL have a default willingness of 3 and
include the associated message item.
The presence of an Attached Networks pattern allows a participating
router to expose node information from a stub network reachable
"behind" the router. All of these endpoints SHALL be treated as
having persistent and reliable connectivity to the router sending the
message. It also allows the router to advertise that it is acting as
a BP gateway by using the pattern "*:**". Care needs to be taken for
which underlayer networks the gateway advertisement is made. Only a
stub network should see the gateway advertisement. See Section 8.5
for considerations about using attached network advertisement.
Sipos & Deaton Expires 12 March 2027 [Page 55]
Internet-Draft BP SAND September 2026
$sand-msg /= sand-msg-gen<1, {+ $$router-grp }>
; Willingness for Singleton
$$router-grp //= (
1: will-route .default 0
)
will-route = (0 .. 6) .within uint
; Willingness for Multipoint
$$router-grp //= (
2: will-route .default 0
)
; Attached Networks
$$router-grp //= (
3: embed-eid-pattern, ; From [I-D.ietf-dtn-eid-pattern]
)
Figure 21: Router Advertisement CDDL
5.8. Endpoint Advertisement
The Endpoint Advertisement message contains information about the
endpoints registered on the advertising node at the time of the
message formation. This information does not include information
about the registration state (active or passive, as defined in
Section 3.1 of [RFC9171]).
When creating Endpoint Advertisement messages, the advertising node
MAY filter advertised endpoints to prevent visibility of particular
endpoints to particular underlayer networks or destination nodes.
Each advertised endpoint SHOULD be reachable as a bundle destination
on the node sending the message. Advertising unreachable endpoints
wastes resources on the sender and participating nodes. Because a
node is expected to have a possibly large number of endpoints
registered with similar advertised parameters, each endpoint
definition is organized around an EID Pattern rather than a single
EID.
The Endpoint Advertisement message SHALL be identified by message
type 7. Each message with this type SHALL contain a separate data
map for each endpoint being advertised. The message parameters are
listed below and correspond with the CDDL of Figure 22. These
parameters are also in the IANA registry defined in Section 9.3.7.
EID Pattern: This pair uses key 0 and value type bstr embedding an
Sipos & Deaton Expires 12 March 2027 [Page 56]
Internet-Draft BP SAND September 2026
EID Pattern as defined in Section 4 of [I-D.ietf-dtn-eid-pattern].
Each of the other items in the parent definition applies to all
EIDs matched by this pattern. For singleton endpoints, the node-
identifying portion of the pattern SHALL agree with the
advertising node.
Payload Security Required: This pair uses key 5 and value type uint
containing flags indicating which aspects of payload security are
required for communicating with this endpoint. If this parameter
is absent there is no information about the required policy.
The security flag at bit 0 indicates that the payload SHALL be a
target of a BIB that the node can accept. The security flag at
bit 1 indicates that the payload SHALL be a target of a BCB that
the node can accept. The security flag at bit 1 indicates that
the any accepted security block SHALL bind to the primary block as
AAD.
$sand-msg /= sand-msg-gen<7, {+ $$endpoint-grp }>
$$endpoint-grp //= ( * priv16 => any )
; EID Pattern
$$endpoint-grp //= (
0: embed-eid-pattern, ; From [I-D.ietf-dtn-eid-pattern]
)
; Payload Security Required
$$endpoint-grp //= (
5: uint .bits endpoint-sec-flags
)
endpoint-sec-flags = &(
need-bib: 0,
need-bcb: 1,
bind-primary: 2,
)
Figure 22: Endpoint Advertisement CDDL
Each message with this type SHALL contain at least one data map.
Each data map SHALL have a unique EID Pattern parameter. There SHALL
NOT be any intersection between EID Pattern parameters across
multiple maps.
Sipos & Deaton Expires 12 March 2027 [Page 57]
Internet-Draft BP SAND September 2026
5.8.1. SAND Singleton Endpoint
Each participating node SHOULD register and advertise a singleton
endpoint for the SAND application itself. This allows SAND Bundles
to be transported with payload confidentiality to specific peer
nodes. The endpoint SHOULD use the well-known service number from
Section 9.2 when the Node ID uses the IPN scheme.
An advertisement for the SAND singleton endpoint SHALL contain at
least a Payload Security Required value.
6. Messaging Modes
This section outlines the ways in which SAND Messages (Section 5) can
be combined into SAND Bundles (Section 4.2) and transported to other
SAND-participating nodes. Because SAND messages can be combined in
many ways and because the contents of each message can be filtered-
out based on the need for data privacy or operational security
considerations, these modes are not exhaustive of how SAND messages
can be used to advertise to and discover about peers.
6.1. Group Hello
When a node first enrolls in a network, or when a node is informed of
a link state change to active, it SHOULD send a Group Hello message
set with a Hop Limit of 1 using one or more default convergence layer
(Section 4.6). Because this is a group BP destination, it will be
sent as a plaintext payload. This message set consists of the
following:
Data Solicitation: The node SHALL include a Data Solicitation
message if the time since the last Data Solicitation on that
termination point has exceeded an implementation-defined
threshold.
For a new enrollment, a node SHOULD solicit all of the following:
Credential Advertisement, Resource Advertisement, ULN
Advertisement, CL Advertisement, Local Topology Advertisement.
For link state change, a node SHOULD solicit at least Local
Topology Advertisement.
Credential Advertisement: For a new enrollment, the node SHALL
include a Credential Advertisement message containing certificates
which the node considers safe to advertise on that termination
point and its network. For a link state change, the node SHOULD
include a Credential Advertisement message if the time since the
last Credential Advertisement on that termination point has
exceeded an implementation-defined threshold.
Sipos & Deaton Expires 12 March 2027 [Page 58]
Internet-Draft BP SAND September 2026
ULN Advertisement: The node SHALL include a ULN Advertisement
containing parameters which apply to that termination point.
CL Advertisement: The node SHALL include a CL Advertisement message
containing CLs which apply to that termination point.
Local Topology Advertisement: The node SHOULD include a Local
Topology Advertisement message containing peers which the node
considers safe to advertise on that termination point and its
network.
6.2. Targeted Hello
When a node is informed by some lower-level discovery mechanism that
a specific peer is reachable via IP address, it SHOULD send a
Targeted Hello message set with a Hop Limit of 1 using the Default
Convergence Layers with the peer's IP address as destination. This
message set contains the same messages and data as the Group Hello
and is also sent as plaintext payload when peer BP identity and
security information is not yet available.
6.3. Response to Solicitation
After receiving a Data Solicitation message from an authorized
sender, a participating node SHALL wait and then send a targeted
advertisement to the Source Node ID of the Data Solicitation message.
The means by which a participating node authorizes any peer to have a
Data Solicitation message acted upon, or authorizes targeted
advertisement to that peer is an implementation matter. The wait
time SHALL be calculated to avoid sending each advertisement type
more frequently than a locally-configured time interval. The wait
time MAY include a random jitter [RFC5148] depending on the
underlayer network on which the targeted advertisement is to be sent.
6.4. Periodic Update
A participating node MAY send periodic update advertisements based on
an internal timer associated with the message type being advertised
and the Destination EID being advertised to. A periodic update
advertisement SHOULD be sent with an actual interval shorter than or
equal to the Repetition Interval (Section 5) in sent with associated
message type and destination.
7. Operational Considerations
This section explains various operational topics based on guidance of
the IETF Operations and Management Area Working Group [RFC5706].
Sipos & Deaton Expires 12 March 2027 [Page 59]
Internet-Draft BP SAND September 2026
7.1. Types of Data to Advertise
The choice of which types of data to advertise, in the form of
different SAND message types being transmitted, is an operational
decision of the advertising node alone. The reception and delivery
of Data Solicitation messages can inform an advertising node that
there is a desire to receive specific types of data. The use of Data
Solicitation SHALL NOT override local policy about what can be
advertised by a node. The use of Data Solicitation is also not meant
to limit the types of data being advertised by a node.
Depending on the exact use case for which SAND advertisement is being
used (see Section 1.2), different types of data will be more or less
useful. For example, when used to express the liveliness of expected
links there is little value in including long-lived credentials or
unchanging CL instances with every advertisement.
7.2. Instances of Data to Advertise
The choice of which instances of the various types of data to
advertise is an operational decision of the advertising node alone.
This choice can involve a node filtering-in specific instances to
include or filtering-out specific instances to exclude advertising.
The choice of which instances to filter-in or filter-out and how to
parameterize those filters is entirely an implementation matter on
the advertising node.
One simple reason to filter instances would be to exclude ULN
termination points or entire ULNs which are not enabled for
advertisement or discovery. This corresponds with a strategy to
either "only advertise relevant data" or "only advertise dynamic
data" to avoid advertising data which is either irrelevant to
discovery or not expected to change.
Another possible reason to filter instances is related to ULN
visibility or limiting cross-ULN-technology exposure of parameter
types. For example, only advertising IP-related CL instances or DNS-
based credentials when advertising is enabled only on IP-related
termination points. This reason is not quite security related, and
not concerned with leaking data across different underlayers (see
Section 7.3 for details about that).
Sipos & Deaton Expires 12 March 2027 [Page 60]
Internet-Draft BP SAND September 2026
7.3. Context-Specific Advertisement Filtering
The choice of which types or instances of data to advertise can also
be dependent on the ULN over which the advertisement will be made, or
dependent on the (BP-layer) destination to or source from which the
advertisement is addressed. This is slightly different than the
choices discussed in Section 7.1 and Section 7.2, which would apply
filtering to all advertisement from a node, and requires more
visibility into or control over message transport than those choices.
A simple strategy for destination-specific filtering could be to only
advertise certain types or instances of data when using singleton
destinations for which some amount of security (at BP-layer or below)
can be guaranteed. Other advertisement to a group destination (if
enabled) could be restricted to contain only enough information to
attempt reaching the advertising node and establishing a more secure
channel.
A possible strategy for termination-point-specific filtering would be
to only advertise credentials or CL instances which are relevant to a
specific ULN reachable via termination points for which advertisement
is enabled. This is slightly different than the blanket filtering
discussed in Section 7.2 because different ULNs being advertised on
will see different instances of data being advertised, each tailored
to relevancy on that ULN. For example, when a ULN uses a private
PKIX CA hierarchy an advertising node can filter-in certificates
under the associated root of trust when sending Credential
Advertisement messages on that ULN.
When these kinds of context-specific filtering strategies are
orthogonal, they can be combined. For example filtering based on ULN
technology and based on BP destination when advertising CL instances
(_e.g._, only advertise IPv6-based CLs via an IPv6-only termination
point).
Using these context-specific filtering strategies can result in a
kind of "split brain" situation, where different neighbors observe
different (possibly non-overlapping) sets of data associated with an
advertising node. Because of this careful consideration needs to be
made when choosing to filter-in or filter-out data instances across
different contexts.
7.4. When to Advertise
Another aspect of choice for an advertising node is when to send
specific types and instances of advertised data.
Sipos & Deaton Expires 12 March 2027 [Page 61]
Internet-Draft BP SAND September 2026
One valid strategy is for a node to have independent timers
associated with different types of data, instances of data, and/or
ULN termination points, and periodically sending an associated SAND
message containing the state of that data. This makes advertisement
behavior more deterministic and provides predictable message sizes
and rates. The message metadata parameter Repetition Interval is
meant to express an associated timer interval when this strategy is
used and allow a message receiver to adapt to the expected message
rates. In this case the parameter Validity Duration is expected be
on the same order of magnitude as the Repetition Interval.
Another strategy is for a node to send SAND messages only when its
associated state has changed. This strategy additionally requires
some hysteresis threshold so that frequent, small state changes do
not cause excessive advertisement messaging. The message metadata
parameter Validity Duration does not apply in this case, as the
message content will need to be valid until a superseding message
(see Section 4.5) is sent. Using this strategy exclusively is
vulnerable to messages being lost because of SAND bundles not being
delivered (for any number of possible, even temporary, reasons).
An even more extreme strategy is to send messages only when solicited
by some other node. Messages sent in response to solicitations can,
but do not need to, be specifically directed to the soliciting node.
So one possible variation of this strategy is to send advertisements
to a group destination in response to solicitations (themselves
having either group or singleton destinations).
A hybrid of these strategies would use timers to provide a baseline
average of messaging interval, with some way for a change of
associated state or a received solicitation to trigger an early send
along with some hysteresis or cool-down logic to prevent excessive
messaging. The use of timers allow the use of appropriate Validity
Duration and Repetition Interval parameters, and the superseding
logic covers cases of earlier-than-expected sending.
7.5. Authorizing Discovered Data
Just because a SAND message has been received by a participating node
and its transport meets all of the needed conditions of Section 4
does not imply that the receiving node needs to actually _use_ the
message or all of the data contained within. This specification
defines a mechanism with mandatory-to-implement structures and code
points (meaning that implementations need to be able to properly
interpret them) but none of these mechanisms are mandatory-to-use by
either an advertising node (the sender) or a discovering node (a
receiver).
Sipos & Deaton Expires 12 March 2027 [Page 62]
Internet-Draft BP SAND September 2026
The choice of a discovering node to authorize use of specific data
(for reasons discussed below) is an implementation matter on that
node. Authorization for use of SAND data can be dependent on the
SAND data/message type, SAND bundle source or destination, or CL-
related parameters about the reception of the bundle PDU.
Authorization of for use of specific data can also be conditional on
previously discovered or negotiated data about the advertising node.
7.6. Culling Discovered Data
Beyond the logic to authorize use of data, it can also be helpful for
a discovering node to cull irrelevant data. It is an implementation
matter on the discovering node for how to identify irrelevant data,
but some examples are below. One reason for such data to be present
in the first place is when the advertising node does not use
context-specific advertisement (Section 7.3) and includes
credentials, ULN instances, and/or CL instances which do not apply to
all discovering nodes which can receive the associated SAND messages.
One example of this is an advertising node which includes non-IP ULN
or CL parameters in its advertisements, which simply cannot be
interpreted by an IP-only discovering node. The culling applies only
to the internal representation of data within the discovering node
and not to any subsequent messaging. This culling is a clear example
because a software change would be needed on the discovering node to
be able to support the unhandled parameters.
Another example is the case where a node advertises ULN instances
and/or CL instances with addresses logically unreachable to the
discovering node. This does not mean that the addresses need to be
probed, just when one or more of the addresses does not have a
possible route from the discovering node. Care must be taken in this
situation because a routing check failing at the time of reception
does not mean that the routing check will not succeed at some later
time due to subsequent changes to the discovering node's routing
configuration.
7.7. Correlating CL Instances with SAND Bundles
When the context-specific advertisement (Section 7.3) is used by an
advertising node, it is necessary to relate advertised data to CL
instances in two ways:
Sipos & Deaton Expires 12 March 2027 [Page 63]
Internet-Draft BP SAND September 2026
* The advertising node chooses one or more termination points for
which advertisement is enabled and correlates those to CL
instances which operate on those termination points. This logic
can be aggregate across the termination points, sending one
advertisement about "all of" those TPs, or iterative, sending
separate advertisements for "each of" the TPs.
* Once the SAND PDU(s) are constructed, the advertising node
transmits an enveloping SAND Bundle to the appropriate destination
EID and ensures that bundle is forwarded over the appropriate CL
instance. The means by which the forwarding logic is
parameterized and controlled is an implementation matter and not
all BPA--application interfaces will cleanly allow such deep
control. In the absence of such control, context-specific
advertisement might not be available on a node.
When context-specific authorization (Section 7.5) is used by a
discovering node, it is necessary to relate received SAND messages to
their original enveloping SAND Bundle as well as the local CL
instance over which the bundle was received. The means by which the
CL-related reception details are parameterized and retained with the
received bundle is an implementation matter and not all BPA--
application interfaces will allow such deep visibility. In the
absence of such visibility, context-specific authorization might not
be available on a node.
8. Security Considerations
This section separates security considerations into threat categories
based on guidance of BCP 72 [RFC3552].
8.1. Threat: Passive Leak of Data to Eavesdroppers
Because this protocol is involved in enrollment of a node into a BP
network, any initial zero-configuration group messaging (Section 6.1)
from a participating node necessarily has a plaintext payload.
One avoidance of passive leaking is for the advertising node to
filter-out sensitive data from its initial messages as described in
Section 7. This could include not disclosing certain DNS names or IP
addresses assigned to termination points, certain CL instances, or
certain 1-hop neighbors from advertisement messages. It could also
include not disclosing certificates from CAs or with key purposes
which are sensitive. Because the initial group messaging is
termination point-specific, the filtering-out of data does not need
to be symmetric across all termination points on which the node is
participating in SAND.
Sipos & Deaton Expires 12 March 2027 [Page 64]
Internet-Draft BP SAND September 2026
Another possible mitigation is to avoid group messaging entirely on a
termination point and rely on lower-layer network peer discovery to
identify potential participants and then attempt to use UDPCL with
DTLS (or some underlayer-specific equivalent) to establish secure
transport with the peer. While more secure from eavesdroppers, this
method is more time- and resource-consuming than group messaging.
This method also assumes that transport-layer security is even
possible while in some environments only BP-layer security is viable.
It is important to consider that if end-to-end confidentiality is not
applied to the payload of a SAND bundle, its messages need to be
treated as observable by middleboxes and/or eavesdroppers. Just
because a bundle is marked with a hop limit of 1 and is expected to
traverse a single forwarding hop to its destination does not provide
any assurance that it will not be observed by some middlebox
(operating at BP layer or below).
8.2. Threat: Leak of Data to Discovering Nodes
Even if group messaging is prohibited or restricted, and
confidentiality is provided to messages targeted to a specific node,
the data itself may leak details that should be hidden from the
discovering node. The only mitigation for these kinds of leaks is to
perform destination-specific filtering as described in Section 7.3.
This filtering will be separate from (and possibly in addition to)
any TP-specific filtering that might be applied based on the
underlayer through which the SAND bundle will be forwarded.
8.3. Threat: SAND Bundle Replay
Regardless of whether the SAND messages are kept confidential (using
BPSec or lower-layer security) there is a possibility for an on-path
attacker to record and replay SAND bundles.
Because this specification defines rules for superseding messages in
Section 4.5 and there is already an expectation that redundant
transmissions can happen normally in the Default Convergence Layers,
the only bad effect of SAND bundle replay is to waste network
resources on the path(s) to the bundle destinations.
8.4. Threat: Denial of Service
The behaviors described in this section all amount to a potential
denial-of-service to a participating node. The denial-of-service
could be limited to an individual node, or could affect all entities
on a host or network segment.
Sipos & Deaton Expires 12 March 2027 [Page 65]
Internet-Draft BP SAND September 2026
Because there is a Data Solicitation mechanism it is possible to
attempt an amplification attack by soliciting many types of data,
with corresponding large bundle size, using a small request bundle.
A mitigation of this kind of attack is to treat solicitation requests
in the context of minimum and maximum update intervals. Rather than
causing a set of advertisements directly, the solicitation is treated
as an update timer reset and is limited according to that timer
interval.
A participating node may, intentionally or not, use singleton or
group messaging to overwhelm a link or network, requiring the
receiving node to process the data. This kind of attack applies to
BP Agents generally and is not specific to SAND messaging. The
victim node can block bundles or CL reception from network peers
which are thought to be incorrectly behaving within the network.
Because the Default Convergence Layers include UDP transport, the
recommended configurations of this document need to result in
behaviors which conform to the limitations of "UDP Usage Guidelines"
BCP 145, specifically Section 4 of [RFC8085]. This protocol uses the
"congestion avoidance" strategy by having implementations choose
appropriate timer intervals for minimum SAND updates and, when
applicable, for UDPCL redundant transmission explained in
Section 3.3.1 of [I-D.ietf-dtn-udpcl].
8.5. Threat: Route Leaking and Hijacking
The choice to advertise attached networks by a BP router (see
Section 5.7) is a separate concern from the choice of other
participating nodes to authorize use (some or all of) those
advertised networks for routing. This authorization-for-routing is
also separate from the recording of received SAND data in information
bases associated with the advertising node.
Without proper authorization for routing use, the vulnerabilities
associated with route leaking [RFC4593] and route hijacking [RFC7908]
apply to the online use of SAND Router Advertisement. There is
currently no equivalent to Resource Public Key Infrastructure (RPKI)
[RFC6480] for authorizing BP routing.
8.6. Identity Bootstrapping
For BP nodes enrolling in a network for the first time, with proper
authorization to do so, other participating nodes will not be able to
authenticate SAND Bundles per the requirements of Section 4.4 without
having associated end-entity certificates available.
Sipos & Deaton Expires 12 March 2027 [Page 66]
Internet-Draft BP SAND September 2026
A participating node SHOULD have the ability for an application to
inspect the payload of a bundle as part of BPSec processing in order
to extract necessary certificates from Credential Advertisement
messages. If that is not possible, a advertising node SHOULD include
necessary certificates within any BIB needed to satisfy requirements
of Section 4.4. Determination of this need is a network
administration matter outside the scope of this document.
8.7. Messaging Without Authentication
In environments where PKI is not available for the BP-layer, the SAND
could be operated without the requirements of Section 4.4 but doing
so is outside the scope of this document. Even in cases where there
is network-layer or link-layer security, specifically source
authentication with proof-of-possession, having an authorized lower-
layer identity does not imply unlimited BP-layer authorization. Part
of the purpose of BP-layer integrity protection is to prevent a
misconfigured node from polluting topology information bases of BP
routers.
9. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of code points in existing
registries and creation of new SAND registries in accordance with BCP
26 [RFC8126].
9.1. Well-Known IMC Group and Service
Within the URI Schemes registry group of [IANA-URI], the registry
titled "'imc' Scheme Well-known Group Numbers for BPv7" has been
updated to include the following entry.
+=======+===================+======================+
| Value | Description | Reference |
+=======+===================+======================+
| TBA1 | SAND Participants | [This specification] |
+-------+-------------------+----------------------+
Table 13: 'imc' Scheme Well-known Group Numbers
for BPv7
Within the URI Schemes registry group of [IANA-URI], the registry
titled "'imc' Scheme Well-known Service Numbers for BPv7" has been
updated to include the following entry.
Sipos & Deaton Expires 12 March 2027 [Page 67]
Internet-Draft BP SAND September 2026
+=======+================+===================================+
| Value | Description | Reference |
+=======+================+===================================+
| TBA2 | SAND Messaging | Section 4 of [This specification] |
+-------+----------------+-----------------------------------+
Table 14: 'imc' Scheme Well-known Service Numbers for BPv7
9.2. Well-Known IPN Service
Within the URI Schemes registry group of [IANA-URI], the registry
titled "'ipn' Scheme URI Well-known Service Numbers for BPv7" has
been updated to include the following entry.
+=======+================+===================================+
| Value | Description | Reference |
+=======+================+===================================+
| TBA3 | SAND Messaging | Section 4 of [This specification] |
+-------+----------------+-----------------------------------+
Table 15: 'ipn' Scheme URI Well-known Service Numbers for BPv7
9.3. BP SAND Registry Group
EDITOR NOTE: Registry group and registries to-be-created upon
publication of this specification.
IANA will create the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND] to
contain registries associated with the SAND protocol.
9.3.1. SAND Message Types
IANA will create, under the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a
registry titled "SAND Message Types" and initialize it with the
contents of Table 16. For positive code points the registration
procedure is Specification Required. Negative code points are
reserved for use on private networks for functions not published to
the IANA.
Specifications of new message types need to define the code point (an
int16 integer), as well as what message metadata are required and
allowed within the message and how to interpret the message data
maps. Specifications need to define how those CBOR data are used by
a node to relate the encoded message to the agent's information
bases.
Sipos & Deaton Expires 12 March 2027 [Page 68]
Internet-Draft BP SAND September 2026
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+==============+========================+======================+
| Code | Name | Reference |
+==============+========================+======================+
| -32768 to -1 | Reserved | [This specification] |
+--------------+------------------------+----------------------+
| 0 | Reserved | [This specification] |
+--------------+------------------------+----------------------+
| 1 | Data Solicitation | Section 5.1 of [This |
| | | specification] |
+--------------+------------------------+----------------------+
| 2 | Credential | Section 5.2 of [This |
| | Advertisement | specification] |
+--------------+------------------------+----------------------+
| 8 | ULN Advertisement | Section 5.3 of [This |
| | | specification] |
+--------------+------------------------+----------------------+
| 3 | CL Advertisement | Section 5.4 of [This |
| | | specification] |
+--------------+------------------------+----------------------+
| 4 | Resource Advertisement | Section 5.5 of [This |
| | | specification] |
+--------------+------------------------+----------------------+
| 5 | Local Topology | Section 5.6 of [This |
| | Advertisement | specification] |
+--------------+------------------------+----------------------+
| 6 | Router Advertisement | Section 5.7 of [This |
| | | specification] |
+--------------+------------------------+----------------------+
| 7 | Endpoint Advertisement | Section 5.8 of [This |
| | | specification] |
+--------------+------------------------+----------------------+
| 9 to 32511 | unassigned | |
+--------------+------------------------+----------------------+
| 32512 to | Reserved for private | [This specification] |
| 32767 | and experimental types | |
+--------------+------------------------+----------------------+
Table 16: SAND Message Types
Sipos & Deaton Expires 12 March 2027 [Page 69]
Internet-Draft BP SAND September 2026
9.3.2. SAND Message Metadata
IANA will create, under the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a
registry titled "SAND Message Common Parameters" and initialize it
with the contents of Table 17. The registration procedure is
Specification Required.
Specifications of new common parameters need to define the code point
(an int16 integer) as well as the CBOR form and meaning of the
associated value.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+==========+==========================+====================+
| Code | Name | Reference |
+==========+==========================+====================+
| 2 | Reference Time | Section 5 of [This |
| | | specification] |
+----------+--------------------------+--------------------+
| 3 | Validity Duration | Section 5 of [This |
| | | specification] |
+----------+--------------------------+--------------------+
| 4 | Repetition Interval | Section 5 of [This |
| | | specification] |
+----------+--------------------------+--------------------+
| 5 to | unassigned | |
| 32511 | | |
+----------+--------------------------+--------------------+
| 32512 to | Reserved for private and | [This |
| 32767 | experimental metadata | specification] |
+----------+--------------------------+--------------------+
Table 17: SAND Message Metadata Parameters
9.3.3. SAND ULN Registries
IANA will create, under the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a
registry titled "SAND ULN Advertisement Parameters" and initialize it
with the contents of Table 18. The registration procedure is
Specification Required.
Specifications of new common parameters need to define the code point
(an int16 integer) as well as the CBOR form and meaning of the
associated value.
Sipos & Deaton Expires 12 March 2027 [Page 70]
Internet-Draft BP SAND September 2026
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+==============+==========================+======================+
| Code | Name | Reference |
+==============+==========================+======================+
| -32768 to -1 | Reserved | [This specification] |
+--------------+--------------------------+----------------------+
| 0 | Termination Point Index | Section 5.3 of [This |
| | | specification] |
+--------------+--------------------------+----------------------+
| 1 | Validity Schedule | Section 5.3 of [This |
| | | specification] |
+--------------+--------------------------+----------------------+
| 2 | DNS Name List | Section 5.3.1 of |
| | | [This specification] |
+--------------+--------------------------+----------------------+
| 3 | IP Address List | Section 5.3.1 of |
| | | [This specification] |
+--------------+--------------------------+----------------------+
| 4 | Link MTU | Section 5.3.1 of |
| | | [This specification] |
+--------------+--------------------------+----------------------+
| 5 | MAC Address List | Section 5.3.1 of |
| | | [This specification] |
+--------------+--------------------------+----------------------+
| 6 to 32511 | unassigned | |
+--------------+--------------------------+----------------------+
| 32512 to | Reserved for private and | [This specification] |
| 32767 | experimental parameters | |
+--------------+--------------------------+----------------------+
Table 18: SAND ULN Advertisement Parameters
9.3.4. SAND CL Registries
IANA will create, under the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a
registry titled "SAND CL Common Parameters" and initialize it with
the contents of Table 19. The registration procedure is
Specification Required.
Specifications of new common parameters need to define the code point
(an int16 integer) as well as the CBOR form and meaning of the
associated value.
Sipos & Deaton Expires 12 March 2027 [Page 71]
Internet-Draft BP SAND September 2026
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+===========+========================+================+
| Code | Name | Reference |
+===========+========================+================+
| -32768 to | Reserved for private | [This |
| -32513 | and experimental type- | specification] |
| | specific parameters | |
+-----------+------------------------+----------------+
| -32512 to | Delegated to SAND CL | [This |
| -1 | Type-Specific | specification] |
| | Parameters registry | |
+-----------+------------------------+----------------+
| 0 | CL Type | Section 5.4 of |
| | | [This |
| | | specification] |
+-----------+------------------------+----------------+
| 1 | Termination Point | Section 5.4 of |
| | Index | [This |
| | | specification] |
+-----------+------------------------+----------------+
| 3 | Bind Address List | Section 5.4.1 |
| | | of [This |
| | | specification] |
+-----------+------------------------+----------------+
| 4 | Bind Port Number | Section 5.4.1 |
| | | of [This |
| | | specification] |
+-----------+------------------------+----------------+
| 5 | Transport Security | Section 5.4 of |
| | Required | [This |
| | | specification] |
+-----------+------------------------+----------------+
| 6 | Role | Section 5.4 of |
| | | [This |
| | | specification] |
+-----------+------------------------+----------------+
| 7 to | unassigned | |
| 32511 | | |
+-----------+------------------------+----------------+
| 32512 to | Reserved for private | [This |
| 32767 | and experimental | specification] |
| | common parameters | |
+-----------+------------------------+----------------+
Table 19: SAND CL Common Parameters
Sipos & Deaton Expires 12 March 2027 [Page 72]
Internet-Draft BP SAND September 2026
IANA will create, under the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a
registry titled "SAND CL Types" and initialize it with the contents
of Table 20. For positive code points the registration procedure is
Specification Required. Negative code points are reserved for use on
private networks for functions not published to the IANA.
Specifications of new CL types need to define the CL Type value (an
int16 integer), as well as the other CL parameters required and
allowed. Specifications need to define how those CBOR parameters are
used by a node to transfer bundles to the referred-to CL.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
Sipos & Deaton Expires 12 March 2027 [Page 73]
Internet-Draft BP SAND September 2026
+==============+=========================+======================+
| Code | Name | Reference |
+==============+=========================+======================+
| -32768 to -1 | Reserved for private | [This specification] |
| | and experimental use | |
+--------------+-------------------------+----------------------+
| 0 | Reserved | [This specification] |
+--------------+-------------------------+----------------------+
| 1 | TCPCLv4 | Section 5.4.2 of |
| | | [This specification] |
+--------------+-------------------------+----------------------+
| 2 | UDPCLv2 | Section 5.4.3 of |
| | | [This specification] |
+--------------+-------------------------+----------------------+
| 3 | LTPCL CSID5 Over UDP | Section 5.4.4 of |
| | | [This specification] |
+--------------+-------------------------+----------------------+
| 4 | BTP-U Over Ethernet | Section 5.4.5 of |
| | | [This specification] |
+--------------+-------------------------+----------------------+
| 5 to 251 | unassigned | |
+--------------+-------------------------+----------------------+
| 252 | | Section 5.4.4 of |
| | // LTPCL CSID4 Over UDP | [This specification] |
+--------------+-------------------------+----------------------+
| 253 | | Section 5.4.4 of |
| | // LTPCL CSID1 Over UDP | [This specification] |
+--------------+-------------------------+----------------------+
| 254 | TCPCLv3 | Section 5.4.6 of |
| | | [This specification] |
+--------------+-------------------------+----------------------+
| 255 | Experimental UDPCL | Section 5.4.7 of |
| | | [This specification] |
+--------------+-------------------------+----------------------+
| 256 to 32767 | unassigned | |
+--------------+-------------------------+----------------------+
Table 20: SAND CL Types
IANA will create, under the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a
registry titled "SAND CL Type-Specific Parameters" and initialize it
with the contents of Table 21. The registration procedure is
Specification Required.
Specifications of new common parameters need to define the associated
CL type, code point (an int16 integer), and the CBOR form and meaning
of the associated value.
Sipos & Deaton Expires 12 March 2027 [Page 74]
Internet-Draft BP SAND September 2026
+===========+======+======================+======================+
| CL Type | Code | Name | Reference |
+===========+======+======================+======================+
| TCPCLv4 |
+-----------+------+----------------------+----------------------+
| 1 | -1 | Message Type Support | Section 5.4.2 of |
| | | | [This specification] |
+-----------+------+----------------------+----------------------+
| 1 | -2 | Session Extension | Section 5.4.2 of |
| | | Type Support | [This specification] |
+-----------+------+----------------------+----------------------+
| 1 | -3 | Transfer Extension | Section 5.4.2 of |
| | | Type Support | [This specification] |
+-----------+------+----------------------+----------------------+
| UDPCLv2 |
+-----------+------+----------------------+----------------------+
| 2 | -1 | Extension Support | Section 5.4.3 of |
| | | | [This specification] |
+-----------+------+----------------------+----------------------+
| CCSDS LTPCL Variants |
+-----------+------+----------------------+----------------------+
| 3,252,253 | -1 | Engine ID | Section 5.4.4 of |
| | | | [This specification] |
+-----------+------+----------------------+----------------------+
| 3,252,253 | -2 | Extension Support | Section 5.4.4 of |
| | | | [This specification] |
+-----------+------+----------------------+----------------------+
Table 21: SAND CL Type-Specific Parameters
9.3.5. SAND Resource Registries
IANA will create, under the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a
registry titled "SAND Resource Parameters" and initialize it with the
contents of Table 22. The registration procedure is Specification
Required.
Specifications of new peer parameters need to define the code point
(an int16 integer) as well as the CBOR form and meaning of the
associated value. Specifications need to define how those CBOR
parameters are used by a node to relate the encoded message to the
node's information bases.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
Sipos & Deaton Expires 12 March 2027 [Page 75]
Internet-Draft BP SAND September 2026
+=============+==========================+======================+
| Code | Name | Reference |
+=============+==========================+======================+
| -32768 to 0 | Reserved | [This specification] |
+-------------+--------------------------+----------------------+
| 1 | Operating Schedule | Section 5.5 of [This |
| | | specification] |
+-------------+--------------------------+----------------------+
| 2 to 32511 | unassigned | |
+-------------+--------------------------+----------------------+
| 32512 to | Reserved for private and | [This specification] |
| 32767 | experimental parameters | |
+-------------+--------------------------+----------------------+
Table 22: SAND Resource Parameters
9.3.6. SAND Local Topology Registries
IANA will create, under the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a
registry titled "SAND Neighbor Parameters" and initialize it with the
contents of Table 23. The registration procedure is Specification
Required.
Specifications of new peer parameters need to define the code point
(an int16 integer) as well as the CBOR form and meaning of the
associated value. Specifications need to define how those CBOR
parameters are used by a node to relate the encoded message to the
node's information bases.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
Sipos & Deaton Expires 12 March 2027 [Page 76]
Internet-Draft BP SAND September 2026
+==============+==========================+======================+
| Code | Name | Reference |
+==============+==========================+======================+
| -32768 to -1 | Reserved | [This specification] |
+--------------+--------------------------+----------------------+
| 0 | Node ID | Section 5.6 of [This |
| | | specification] |
+--------------+--------------------------+----------------------+
| 1 | Reachability | Section 5.6 of [This |
| | | specification] |
+--------------+--------------------------+----------------------+
| 2 | Routing Metrics | Section 5.6 of [This |
| | | specification] |
+--------------+--------------------------+----------------------+
| 3 to 32511 | unassigned | |
+--------------+--------------------------+----------------------+
| 32512 to | Reserved for private and | [This specification] |
| 32767 | experimental parameters | |
+--------------+--------------------------+----------------------+
Table 23: SAND Local Topology Parameters
Sipos & Deaton Expires 12 March 2027 [Page 77]
Internet-Draft BP SAND September 2026
+===========+===========================+================+
| Code | Name | Reference |
+===========+===========================+================+
| -32768 to | Reserved for private and | [This |
| -32513 | experimental type- | specification] |
| | specific parameters | |
+-----------+---------------------------+----------------+
| -32512 to | Delegated to SAND Routing | [This |
| -1 | Metrics Type-Specific | specification] |
| | Parameters registry | |
+-----------+---------------------------+----------------+
| 0 | Routing Type | Section 5.6.1 |
| | | of [This |
| | | specification] |
+-----------+---------------------------+----------------+
| 1 | Direction | Section 5.6.1 |
| | | of [This |
| | | specification] |
+-----------+---------------------------+----------------+
| 2 | Validity Schedule | Section 5.6.1 |
| | | of [This |
| | | specification] |
+-----------+---------------------------+----------------+
| 3 | Termination Point Index | Section 5.6.1 |
| | | of [This |
| | | specification] |
+-----------+---------------------------+----------------+
| 4 to | unassigned | |
| 32511 | | |
+-----------+---------------------------+----------------+
| 32512 to | Reserved for private and | [This |
| 32767 | experimental common | specification] |
| | parameters | |
+-----------+---------------------------+----------------+
Table 24: SAND Routing Metrics Parameters
Sipos & Deaton Expires 12 March 2027 [Page 78]
Internet-Draft BP SAND September 2026
+==============+======================+======================+
| Code | Name | Reference |
+==============+======================+======================+
| -32768 to -1 | Reserved for private | [This specification] |
| | and experimental use | |
+--------------+----------------------+----------------------+
| 0 | Reserved | [This specification] |
+--------------+----------------------+----------------------+
| 1 | SABR | Section 5.6.1.1 of |
| | | [This specification] |
+--------------+----------------------+----------------------+
| 2 to 32767 | unassigned | |
+--------------+----------------------+----------------------+
Table 25: SAND Routing Types
+==============+======+===================+======================+
| Routing Type | Code | Name | Reference |
+==============+======+===================+======================+
| SABR |
+--------------+------+-------------------+----------------------+
| 1 | -1 | Maximum Data Rate | Section 5.6.1.1 of |
| | | | [This specification] |
+--------------+------+-------------------+----------------------+
| 1 | -2 | Delay | Section 5.6.1.1 of |
| | | | [This specification] |
+--------------+------+-------------------+----------------------+
| 1 | -3 | Bit Error Rate | Section 5.6.1.1 of |
| | | | [This specification] |
+--------------+------+-------------------+----------------------+
Table 26: SAND Routing Metrics Type-Specific Parameters
9.3.7. SAND Endpoint Parameters
EDITOR NOTE: registry to-be-created upon publication of this
specification.
IANA will create, under the "Bundle Protocol Secure Advertisement and
Neighborhood Discovery (SAND)" registry group [IANA-BPSAND], a
registry titled "SAND Endpoint Parameters" and initialize it with the
contents of Table 27. The registration procedure is Specification
Required.
Sipos & Deaton Expires 12 March 2027 [Page 79]
Internet-Draft BP SAND September 2026
Specifications of new peer parameters need to define the code point
(an int16 integer) as well as the CBOR form and meaning of the
associated value. Specifications need to define how those CBOR
parameters are used by a node to relate the encoded message to the
node's information bases.
Expert(s) are encouraged to be biased towards approving registrations
unless they are abusive, frivolous, or actively harmful (not merely
aesthetically displeasing, or architecturally dubious).
+==============+==========================+======================+
| Code | Name | Reference |
+==============+==========================+======================+
| -32768 to -1 | Reserved | [This specification] |
+--------------+--------------------------+----------------------+
| 0 | EID Pattern | Section 5.8 of [This |
| | | specification] |
+--------------+--------------------------+----------------------+
| 5 | Payload Security | Section 5.8 of [This |
| | Required | specification] |
+--------------+--------------------------+----------------------+
| 6 to 32511 | unassigned | |
+--------------+--------------------------+----------------------+
| 32512 to | Reserved for private and | [This specification] |
| 32767 | experimental parameters | |
+--------------+--------------------------+----------------------+
Table 27: SAND Endpoint Parameters
10. References
10.1. Normative References
[IANA-BP] IANA, "Bundle Protocol",
<https://www.iana.org/assignments/bundle/>.
[IANA-BPSAND]
IANA, "Bundle Protocol (BP) Secure Advertisement and
Neighborhood Discovery (SAND)",
<https://www.iana.org/assignments/bp-sand/>.
[IANA-LTP] IANA, "Licklider Transmission Protocol (LTP) Parameters",
<https://www.iana.org/assignments/ltp-parameters/>.
[IANA-URI] IANA, "Uniform Resource Identifier (URI) Schemes",
<https://www.iana.org/assignments/uri-schemes/>.
Sipos & Deaton Expires 12 March 2027 [Page 80]
Internet-Draft BP SAND September 2026
[SANA-LTP] SANA, "Licklider Transmission Protocol Client Service
Identifiers", <https://sanaregistry.org/r/ltp_serviceid/>.
[CCSDS-BPv6]
Consultative Committee for Space Data Systems, "CCSDS
Bundle Protocol Specification", CCSDS 734.2-B-1, September
2015, <https://ccsds.org/Pubs/734x2b1.pdf>.
[CCSDS-BPv7-OB]
Consultative Committee for Space Data Systems, "CCSDS
Bundle Protocol Specification (Experimental)",
CCSDS 734.20-O-1, April 2025, <https://ccsds.org/wp-
content/uploads/
gravity_forms/5-448e85c647331d9cbaf66c096458bdd5/2025/06/734x20o1.pdf>.
[CCSDS-BPv7]
Consultative Committee for Space Data Systems, "CCSDS
Bundle Protocol Specification", CCSDS TBA, <TBA>.
[CCSDS-SABR]
Consultative Committee for Space Data Systems, "Schedule-
Aware Bundle Routing", CCSDS 734.3-B-1, July 2019,
<https://public.ccsds.org/Pubs/734x3b1.pdf>.
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
DOI 10.17487/RFC791, September 1981,
<https://www.rfc-editor.org/info/rfc791>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[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/info/rfc2119>.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, DOI 10.17487/RFC5148, February 2008,
<https://www.rfc-editor.org/info/rfc5148>.
[RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram
Convergence Layers for the Delay- and Disruption-Tolerant
Networking (DTN) Bundle Protocol and Licklider
Transmission Protocol (LTP)", RFC 7122,
DOI 10.17487/RFC7122, March 2014,
<https://www.rfc-editor.org/info/rfc7122>.
Sipos & Deaton Expires 12 March 2027 [Page 81]
Internet-Draft BP SAND September 2026
[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant
Networking TCP Convergence-Layer Protocol", RFC 7242,
DOI 10.17487/RFC7242, June 2014,
<https://www.rfc-editor.org/info/rfc7242>.
[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/info/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/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[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/info/rfc9171>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>.
[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/info/rfc9174>.
[RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Header Parameters for Carrying and Referencing X.509
Certificates", RFC 9360, DOI 10.17487/RFC9360, February
2023, <https://www.rfc-editor.org/info/rfc9360>.
Sipos & Deaton Expires 12 March 2027 [Page 82]
Internet-Draft BP SAND September 2026
[I-D.ietf-dtn-bpsec-cose]
Sipos, B., "Bundle Protocol Security (BPSec) COSE
Context", Work in Progress, Internet-Draft, draft-ietf-
dtn-bpsec-cose-17, 3 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
bpsec-cose-17>.
[I-D.ietf-dtn-udpcl]
Sipos, B. and J. Deaton, "Delay-Tolerant Networking UDP
Convergence Layer Protocol Version 2", Work in Progress,
Internet-Draft, draft-ietf-dtn-udpcl-04, 15 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
udpcl-04>.
[I-D.ietf-dtn-btpu]
Taylor, R., "Bundle Transfer Protocol - Unidirectional",
Work in Progress, Internet-Draft, draft-ietf-dtn-btpu-04,
7 September 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-dtn-btpu-04>.
[I-D.ek-dtn-ethernet]
Kline, E., "Bundle Transfer Protocol - Unidirectional
(BTPU) over Ethernet", Work in Progress, Internet-Draft,
draft-ek-dtn-ethernet-06, 6 September 2026,
<https://datatracker.ietf.org/doc/html/draft-ek-dtn-
ethernet-06>.
[I-D.ietf-dtn-eid-pattern]
Sipos, B., "Bundle Protocol Endpoint ID Patterns", Work in
Progress, Internet-Draft, draft-ietf-dtn-eid-pattern-10,
21 August 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-dtn-eid-pattern-10>.
10.2. Informative References
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages",
RFC 1256, DOI 10.17487/RFC1256, September 1991,
<https://www.rfc-editor.org/info/rfc1256>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<https://www.rfc-editor.org/info/rfc3444>.
Sipos & Deaton Expires 12 March 2027 [Page 83]
Internet-Draft BP SAND September 2026
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
DOI 10.17487/RFC3552, July 2003,
<https://www.rfc-editor.org/info/rfc3552>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, DOI 10.17487/RFC4593,
October 2006, <https://www.rfc-editor.org/info/rfc4593>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326,
DOI 10.17487/RFC5326, September 2008,
<https://www.rfc-editor.org/info/rfc5326>.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
<https://www.rfc-editor.org/info/rfc5444>.
Sipos & Deaton Expires 12 March 2027 [Page 84]
Internet-Draft BP SAND September 2026
[RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, DOI 10.17487/RFC6130, April 2011,
<https://www.rfc-editor.org/info/rfc6130>.
[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/info/rfc6480>.
[RFC7908] Sriram, K., Montgomery, D., McPherson, D., Osterweil, E.,
and B. Dickson, "Problem Definition and Classification of
BGP Route Leaks", RFC 7908, DOI 10.17487/RFC7908, June
2016, <https://www.rfc-editor.org/info/rfc7908>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8085] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
March 2017, <https://www.rfc-editor.org/info/rfc8085>.
[RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
DOI 10.17487/RFC8175, June 2017,
<https://www.rfc-editor.org/info/rfc8175>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N.,
Ananthakrishnan, H., and X. Liu, "A YANG Data Model for
Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March
2018, <https://www.rfc-editor.org/info/rfc8345>.
Sipos & Deaton Expires 12 March 2027 [Page 85]
Internet-Draft BP SAND September 2026
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[RFC9164] Richardson, M. and C. Bormann, "Concise Binary Object
Representation (CBOR) Tags for IPv4 and IPv6 Addresses and
Prefixes", RFC 9164, DOI 10.17487/RFC9164, December 2021,
<https://www.rfc-editor.org/info/rfc9164>.
[RFC9542] Eastlake 3rd, D., Abley, J., and Y. Li, "IANA
Considerations and IETF Protocol and Documentation Usage
for IEEE 802 Parameters", BCP 141, RFC 9542,
DOI 10.17487/RFC9542, April 2024,
<https://www.rfc-editor.org/info/rfc9542>.
[I-D.ietf-tvr-requirements]
King, D., Contreras, L. M., Sipos, B., and L. Zhang,
"Time-Variant Routing (TVR) Requirements", Work in
Progress, Internet-Draft, draft-ietf-tvr-requirements-11,
2 July 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-tvr-requirements-11>.
[I-D.irtf-dtnrg-ipnd]
Ellard, D., Altmann, R., Gladd, A., in 't Velt, R., and D.
Brown, "DTN IP Neighbor Discovery (IPND)", Work in
Progress, Internet-Draft, draft-irtf-dtnrg-ipnd-03, 10
November 2015, <https://datatracker.ietf.org/doc/html/
draft-irtf-dtnrg-ipnd-03>.
[I-D.sipos-dtn-edge-zeroconf]
Sipos, B., "Lightweight Bundle Protocol Edge Node with
Zero-Configuration and Zero-State", Work in Progress,
Internet-Draft, draft-sipos-dtn-edge-zeroconf-01, 23
October 2023, <https://datatracker.ietf.org/doc/html/
draft-sipos-dtn-edge-zeroconf-01>.
[github-dtn-demo-agent]
Sipos, B., "BP SAND Example Implementation",
<https://github.com/BrianSipos/dtn-demo-agent/>.
Sipos & Deaton Expires 12 March 2027 [Page 86]
Internet-Draft BP SAND September 2026
Acknowledgments
Thanks to Sarah Heiner at JHU/APL for pre-draft review to make the
document clear and readable in its first draft. Thanks to Leonardo
Babun at JHU/APL for editorial review and feedback. Thanks to
Oleksandr Nazymko at D3TN for trial implementation and editorial
feedback.
Implementation Status
This section is to be removed before publishing as an RFC.
[NOTE to the RFC Editor: please remove this section before
publication, as well as the reference to [RFC7942] and
[github-dtn-demo-agent].]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations can
exist.
An example implementation of the this draft of SAND has been created
as a GitHub project [github-dtn-demo-agent] and is intended to use as
a proof-of-concept and as a possible source of interoperability
testing. This example implementation uses D-Bus as the CL-BP Agent
interface, so it only runs on hosts which provide the Python "dbus"
library.
Authors' Addresses
Brian Sipos
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
United States of America
Email: brian.sipos+ietf@gmail.com
Joshua Deaton
Science Applications International Corporation
Sipos & Deaton Expires 12 March 2027 [Page 87]
Internet-Draft BP SAND September 2026
Email: joshua.e.deaton@nasa.gov
Sipos & Deaton Expires 12 March 2027 [Page 88]