



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:<node>.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:!.<service> or
   ipn:4294967295.<service>.

   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:<node>.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:<node>.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,
              <https://www.rfc-editor.org/rfc/rfc2119>.

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




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, <https://www.rfc-editor.org/rfc/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/rfc/rfc9172>.

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

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, <https://datatracker.ietf.org/doc/html/
              draft-ietf-dtn-bp-sand-02>.

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

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]
