Delay/Disruption Tolerant Networking R. Taylor Internet-Draft Aalyria Technologies Updates: 9758 (if approved) 15 March 2026 Intended status: Standards Track Expires: 16 September 2026 BP Address Resolution Protocol draft-taylor-dtn-bp-arp-00 Abstract This document specifies the Bundle Protocol Address Resolution Protocol (BP-ARP), a mechanism for discovering the Node ID of a Bundle Protocol Agent (BPA) that is reachable at a known Convergence Layer (CL) address. BP-ARP enables a BPA to resolve CL-layer adjacency into BP-layer peer relationships, bootstrapping higher- level protocols such as SAND. This document updates RFC 9758 to allow externally received bundles destined to the LocalNode administrative endpoint for registered administrative record types. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://ricktaylor.github.io/bp-arp/draft-taylor-dtn-bp-arp.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-taylor-dtn-bp-arp/. Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (mailto:dtn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dtn/. Subscribe at https://www.ietf.org/mailman/listinfo/dtn/. Source for this draft and an issue tracker can be found at https://github.com/ricktaylor/bp-arp. 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/. Taylor Expires 16 September 2026 [Page 1] Internet-Draft BP-ARP March 2026 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 16 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Relationship to SAND . . . . . . . . . . . . . . . . . . 4 1.3. Design Rationale . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Message Flow . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Addressing . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. RFC 9758 Constraint . . . . . . . . . . . . . . . . . 6 4. Normative Specification . . . . . . . . . . . . . . . . . . . 7 4.1. Administrative Record Type . . . . . . . . . . . . . . . 7 4.2. BP-ARP Request . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Primary Block . . . . . . . . . . . . . . . . . . . . 7 4.2.2. Hop Count Extension Block . . . . . . . . . . . . . . 7 4.2.3. Payload Block . . . . . . . . . . . . . . . . . . . . 7 4.2.4. Transmission . . . . . . . . . . . . . . . . . . . . 8 4.3. BP-ARP Response . . . . . . . . . . . . . . . . . . . . . 8 4.3.1. Primary Block . . . . . . . . . . . . . . . . . . . . 8 4.3.2. Payload Block . . . . . . . . . . . . . . . . . . . . 8 4.3.3. Processing . . . . . . . . . . . . . . . . . . . . . 9 4.4. LocalNode Address Handling . . . . . . . . . . . . . . . 9 4.5. BP-ARP Policy . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5.1. BPSec Authentication . . . . . . . . . . . . . . . . . . 10 5.2. Relaxation of LocalNode Rule . . . . . . . . . . . . . . 10 Taylor Expires 16 September 2026 [Page 2] Internet-Draft BP-ARP March 2026 5.3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.1. Administrative Record Type . . . . . . . . . . . . . . . 11 6.2. No Service Number Required . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Policy Configuration . . . . . . . . . . . . . . . . 12 Appendix B. CLA Interface . . . . . . . . . . . . . . . . . . . 13 Appendix C. Implementation Notes . . . . . . . . . . . . . . . . 13 C.1. Integration with BPA . . . . . . . . . . . . . . . . . . 13 C.2. Generic Implementation . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction 1.1. Problem Statement In Bundle Protocol networks, a Convergence Layer Adapter (CLA) may discover link-layer adjacency with another node without learning that node's Node ID. For example: * A UDP-based CLA receives packets from a previously unknown IP address. * A Bluetooth CLA discovers a nearby device. * A satellite link becomes available to a ground station. In these cases, the CLA knows _how_ to reach the neighbour (CL address) but not _who_ they are (Node ID). Without the Node ID, the BPA cannot: * Install routes to the discovered node. * Make forwarding decisions for bundles destined to that node. * Participate in neighbour discovery protocols like SAND. Additionally, some CL protocols convey only a single Node ID during session establishment. For example, TCPCLv4 [RFC9174] exchanges one Node ID per peer during contact header negotiation. A node that supports multiple Node IDs — such as both an ipn-scheme and a dtn- scheme Node ID — cannot advertise all of its identities through the CL protocol alone. BP-ARP allows discovery of the complete set of Node IDs associated with a peer, regardless of CL protocol limitations. Taylor Expires 16 September 2026 [Page 3] Internet-Draft BP-ARP March 2026 1.2. Relationship to SAND The IETF SAND protocol [I-D.ietf-dtn-bp-sand] provides secure advertisement and neighbourhood discovery at the Bundle Protocol layer. However, SAND requires the ability to send bundles to discovered neighbours. BP-ARP provides the bootstrap mechanism to resolve CL addresses to Node IDs, enabling SAND to operate. CLA discovers CL adjacency (Neighbour) -> BP-ARP resolves Neighbour -> Peer (learns Node ID) -> SAND can exchange topology information with known Peer 1.3. Design Rationale BP-ARP is designed as a BPA-level operation, not a service-level one. The question "what is your Node ID?" is directed at the BPA itself, similar to how ICMP messages in IP are handled by the IP stack rather than applications. BP-ARP resolves the singleton identity of a specific node; it is analogous to ICMP, not IGMP. Group membership discovery for multicast or anycast endpoints is out of scope. For this reason, BP-ARP uses the administrative endpoint rather than a dedicated service endpoint. 2. 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. Bundle Protocol Agent (BPA): The node-level entity that implements the Bundle Protocol. Convergence Layer Adapter (CLA): A component that adapts the Bundle Protocol to a specific underlying transport. Convergence Layer Address (CL Address): A transport-specific address used by a CLA (e.g., IP address + port for TCP/UDP). Endpoint Identifier (EID): A name for a Bundle Protocol endpoint, using either the ipn or dtn URI scheme, as defined in [RFC9171], Section 4.2.5.1. Node ID: The EID that identifies a BPA as a whole, as distinct from Taylor Expires 16 September 2026 [Page 4] Internet-Draft BP-ARP March 2026 any application service endpoints. [RFC9171], Section 3.1 defines the Node ID as the endpoint that identifies the BPA itself. Each URI scheme defines the Node ID as follows: * ipn scheme: The Node ID is the administrative endpoint, formed by setting the service number to 0. For example, ipn:42.0 or ipn:1.42.0 (with allocator). This is defined in [RFC9758], Section 3.3. * dtn scheme: The Node ID is the node name with no demux part. For example, dtn://node42/. This is defined in [RFC9171], Section 4.2.5.1.1. A node MAY have multiple Node IDs across different URI schemes. For example, a node might be identified as both ipn:42.0 and dtn://node42/. Node IDs are by definition singleton endpoints that uniquely identify a single BPA; multicast and anycast EIDs are not Node IDs. Peer: A remote BPA with a known Node ID and reachable via a known CL address. Neighbour: A CL adjacency where the CL address is known but the Node ID is unknown. Address Resolution: The process of discovering the Node ID(s) associated with a Neighbour's CL address. 3. Protocol Overview 3.1. Message Flow Taylor Expires 16 September 2026 [Page 5] Internet-Draft BP-ARP March 2026 Node A Node B (knows B's CL address, (Node ID: ipn:42.0) doesn't know B's Node ID) | | | BP-ARP Request | | src: ipn:17.0 | | dst: ipn:!.0 | | [sent to B's CL address] | |----------------------------------------->| | | | BP-ARP Response | | src: ipn:42.0 | | dst: ipn:17.0 | |<-----------------------------------------| | | Node A learns: | B's Node ID is ipn:42.0 | 3.2. Addressing BP-ARP uses IPN addressing exclusively for the probe mechanism. The ARP Request is sent to the LocalNode administrative endpoint ipn:!.0, and the BP-ARP Response source is the responding node's ipn-scheme Node ID (e.g., ipn:.0). Nodes that do not support IPN addressing cannot participate in BP-ARP. While the probe mechanism requires IPN addressing, the BP-ARP Response payload carries the complete set of Node IDs for the responding node, including dtn-scheme Node IDs (e.g., dtn://node42/) alongside ipn-scheme Node IDs (e.g., ipn:42.0). This enables discovery of all of a node's identities regardless of URI scheme, supporting dual-stack deployments. 3.2.1. RFC 9758 Constraint [RFC9758], Section 3.4.2 defines LocalNode as Node Number 2^32-1 (0xFFFFFFFF), represented as ipn:!. or ipn:4294967295.. However, [RFC9758], Section 5.4 states that "all externally received bundles featuring LocalNode EIDs as a bundle source or bundle destination MUST be discarded as invalid." This means LocalNode (ipn:!.0) cannot be used as the destination for BP-ARP probes under current [RFC9758] rules. This specification updates [RFC9758] to relax this restriction for BP-ARP bundles; see Section 4.4 for the full specification. Taylor Expires 16 September 2026 [Page 6] Internet-Draft BP-ARP March 2026 4. Normative Specification 4.1. Administrative Record Type BP-ARP uses a single Administrative Record type (TBD1) for both requests and responses. The bundle's destination EID distinguishes the two: * A bundle destined to ipn:!.0 is a BP-ARP Request. * A bundle destined to a node's own administrative endpoint is a BP- ARP Response. This distinction is unambiguous: a receiving BPA always knows whether the bundle was addressed to LocalNode or to its own Node ID. 4.2. BP-ARP Request A BP-ARP Request is a bundle with the following properties: 4.2.1. Primary Block * Source EID: The requesting node's administrative endpoint (e.g., ipn:.0). * Destination EID: ipn:!.0 (LocalNode administrative endpoint). * Bundle Processing Control Flags: Administrative record flag MUST be set. 4.2.2. Hop Count Extension Block BP-ARP Request bundles SHOULD include a Hop Count extension block (block type 10, per [RFC9171], Section 4.3.3). The hop limit SHOULD be set to 1. This prevents the BP-ARP Request from being routed beyond the immediate neighbour. 4.2.3. Payload Block The payload block contains an Administrative Record with type TBD1. The payload content is either: * Empty: requesting the complete set of Node IDs from the responding node. * A CBOR array of already-known Node IDs: requesting only Node IDs not included in the list (a delta query). Taylor Expires 16 September 2026 [Page 7] Internet-Draft BP-ARP March 2026 The payload format is defined in Figure 1 using CDDL. 4.2.4. Transmission The bundle MUST be sent via the CLA to the specific CL address of the Neighbour. The bundle MUST NOT be routed through normal RIB lookup. The Hop Count limit of 1 provides defence-in-depth against mis- routing. 4.3. BP-ARP Response Upon receiving a BP-ARP Request, a BPA MUST respond with a BP-ARP Response. 4.3.1. Primary Block * Source EID: The ipn-scheme Node ID of the responding node (e.g., ipn:.0). This MUST NOT be ipn:!.0. * Destination EID: The source EID from the BP-ARP Request. * Bundle Processing Control Flags: Administrative record flag MUST be set. 4.3.2. Payload Block The payload block contains an Administrative Record with type TBD1 (the same type as the request). If the BP-ARP Request payload was empty, the response payload MUST contain a CBOR array of all Node IDs for the responding node, including Node IDs of all supported URI schemes (e.g., both ipn and dtn). If the BP-ARP Request payload contained a list of known Node IDs, the response payload MUST contain only those Node IDs not present in the request (the delta). If the requesting node already knows all Node IDs, the response payload is an empty CBOR array. The response MUST contain only singleton Node IDs that uniquely identify the responding BPA. Multicast, anycast, or other group EIDs MUST NOT be included in the response payload. The payload format is defined in Figure 1 using CDDL: arp-payload = [* eid] eid = $eid ; As defined in RFC 9171 Section 4.2.5.1 Figure 1: BP-ARP Payload Format Taylor Expires 16 September 2026 [Page 8] Internet-Draft BP-ARP March 2026 An example response payload in CBOR diagnostic notation: [ [2, [1, 42, 0]], / ipn:1.42.0 (3-element encoding) / [1, "//node42/"] / dtn://node42/ / ] Figure 2: Example BP-ARP Response Payload This example shows a node reporting both an ipn-scheme and a dtn- scheme Node ID, demonstrating dual-stack identity discovery. 4.3.3. Processing The requesting node associates all Node IDs in the response with the Neighbour's CL address. The Neighbour is promoted to Peer with the discovered Node IDs. Routes MAY be installed for each discovered Node ID. A response to a delta query is additive: the requesting node combines the previously known Node IDs with the newly received Node IDs. 4.4. LocalNode Address Handling This section specifies the update to [RFC9758], Section 5.4. A BPA implementing BP-ARP: * MUST accept bundles destined to ipn:!.0 from external sources if: - The bundle is marked as an administrative record, AND - The administrative record type is BP-ARP (type TBD1). * MUST validate that such bundles are properly formatted. * MUST process valid BP-ARP Requests and generate BP-ARP Responses. * SHOULD apply rate limiting to prevent denial-of-service attacks. * MUST continue to discard other externally received LocalNode destination EIDs unless specifically permitted by a registered administrative record type. Taylor Expires 16 September 2026 [Page 9] Internet-Draft BP-ARP March 2026 4.5. BP-ARP Policy A BPA SHOULD provide a configurable policy that controls whether and when BP-ARP resolution is performed. This allows administrators to select an appropriate trust model for their deployment (see Appendix A for example configurations). 5. Security Considerations 5.1. BPSec Authentication BP-ARP bundles SHOULD be authenticated using BPSec Block Integrity Block (BIB) as defined in [RFC9172]. BP-ARP Request bundles SHOULD include a BIB targeting the payload block, with the requesting node's administrative endpoint as the security source. BP-ARP Response bundles SHOULD include a BIB targeting the payload block, with the responding node's administrative endpoint as the security source. BP-ARP assumes that key material is pre-placed and identity is already established through out-of-band mechanisms. BP-ARP performs address resolution only — mapping a CL address to Node IDs. It does not establish trust relationships, exchange credentials, or perform identity bootstrapping. Deployments requiring credential exchange or identity verification SHOULD use SAND [I-D.ietf-dtn-bp-sand] after BP-ARP resolution. 5.2. Relaxation of LocalNode Rule Accepting external bundles destined to ipn:!.0 introduces potential security risks: Spoofing: A malicious node could send false BP-ARP Responses. Denial of Service: Flooding with BP-ARP Requests could overwhelm a BPA. Information Disclosure: BP-ARP Responses reveal a node's Node IDs. Mitigations include BPSec BIB authentication (Section 5.1), rate limiting on BP-ARP Request processing, validation that BP-ARP Requests are properly formatted administrative records, and policy configuration to disable BP-ARP in sensitive environments. Taylor Expires 16 September 2026 [Page 10] Internet-Draft BP-ARP March 2026 5.3. Trust Model The BP-ARP policy configuration allows administrators to choose appropriate trust levels for their deployment. For example, closed networks may disable BP-ARP entirely and trust only CLA-provided Node IDs, while open networks may use BP-ARP to resolve unknown neighbours. High-security deployments may choose to always verify, even when the CLA provides Node IDs. 6. IANA Considerations 6.1. Administrative Record Type This document requests allocation of a new Bundle Protocol Administrative Record type from the "Bundle Administrative Record Types" registry: +=======+=============+ | Value | Description | +=======+=============+ | TBD1 | BP-ARP | +-------+-------------+ Table 1 A single type is used for both requests and responses. The bundle's destination EID distinguishes the two: bundles destined to ipn:!.0 are requests; bundles destined to a node's own administrative endpoint are responses. 6.2. No Service Number Required BP-ARP uses the existing administrative endpoint (ipn:X.0) and does not require allocation of a new service number. 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Taylor Expires 16 September 2026 [Page 11] Internet-Draft BP-ARP March 2026 [RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . [RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, . [RFC9758] Taylor, R. and E. Birrane III, "Updates to the 'ipn' URI Scheme", RFC 9758, DOI 10.17487/RFC9758, May 2025, . 7.2. Informative References [I-D.ietf-dtn-bp-sand] Sipos, B. and J. Deaton, "Bundle Protocol (BP) Secure Advertisement and Neighborhood Discovery (SAND)", Work in Progress, Internet-Draft, draft-ietf-dtn-bp-sand-02, 18 December 2025, . [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, . Appendix A. Policy Configuration The decision to perform BP-ARP resolution is a BPA configuration option, not a CLA implementation choice. The following table illustrates example policy settings: +===========+====================================================+ | Policy | Behavior | +===========+====================================================+ | as-needed | Only probe if CLA provides no Node IDs (default) | +-----------+----------------------------------------------------+ | always | Always probe, verify/augment CLA-provided Node IDs | +-----------+----------------------------------------------------+ | never | Trust CLA, fail if no Node IDs provided | +-----------+----------------------------------------------------+ Table 2 This separation ensures: * CLAs report facts (what they learned from the CL layer). Taylor Expires 16 September 2026 [Page 12] Internet-Draft BP-ARP March 2026 * Administrators configure policy (trust model for deployment). * The BP-ARP subsystem executes the configured policy. Appendix B. CLA Interface CLAs report discovered adjacencies to the BPA. A CLA provides: * The CL address of the discovered adjacency. * Zero or more Node IDs, if the CLA learned them from the CL layer. When the Node ID list is empty, the CLA has discovered CL adjacency but does not know the Node ID (Neighbour). When the list is non- empty, the CLA has learned one or more Node IDs, which may be incomplete due to CL protocol limitations. For example, TCPCLv4 [RFC9174] exchanges a single Node ID during contact header negotiation; a node with additional Node IDs in other URI schemes cannot advertise them through TCPCLv4 alone. Multi-homing is supported: a single CL address may be associated with multiple Node IDs. Appendix C. Implementation Notes C.1. Integration with BPA The BP-ARP subsystem integrates with the BPA as follows: 1. CLA reports a new adjacency, optionally with a Node ID learned from the CL layer. 2. BPA checks BP-ARP policy configuration. 3. If policy requires probing, the BP-ARP subsystem sends a Request to ipn:!.0 via the CLA. If a Node ID is already known, it may be included in the request payload as a delta query. 4. The BP-ARP subsystem receives a Response and extracts the Node ID from the source field and any additional Node IDs from the payload. 5. The Neighbour is promoted to Peer with all discovered Node IDs. 6. The Routing Information Base (RIB) is updated with routes to the new Peer. Taylor Expires 16 September 2026 [Page 13] Internet-Draft BP-ARP March 2026 C.2. Generic Implementation BP-ARP is implemented generically in the BPA core, not per-CLA: * The discovery probe is a BP-layer bundle (CL-agnostic). * The CLA provides "send to CL address" capability. * The BP-ARP subsystem orchestrates the resolution process. * No duplicate resolution logic is needed in each CLA. Acknowledgments Thanks are due to Erik Kline and Brian Sipos of early review and discussion. Author's Address Rick Taylor Aalyria Technologies Email: rtaylor@aalyria.com Taylor Expires 16 September 2026 [Page 14]