Update to the DTN ipn Endpoint Identifier scheme
Internet-Draft draft-taylor-dtn-ipn-update-01
Rick Taylor
Ori Industries
rick.taylor@ori.co
Ed Birrane
JHU/APL
Edward.Birrane@jhuapl.edu
15 September 2022
Transport
Delay/Disruption Tolerant Networking
DTN
ipn
BPv7
CBHE
Bundle Protocol
The Delay Tolerant Networking 'ipn' Endpoint Identifier scheme was first defined as Compressed Bundle Header Encoding (CBHE) [RFC6260] for use with the Bundle Protocol version 6 (BPv6) [RFC5050]. [RFC7116] updated [RFC6260] and requested IANA registries associated with the ipn scheme when used with BPv6. The Bundle Protocol version 7 (BPv7) specification [RFC9171] also defines an ipn scheme (for use with BPv7) by reusing the format from [RFC6260]. The evolution and specification of the ipn scheme has led to confusion over its use and format between BPv6 and BPv7.
This document defines the ipn scheme as it is to be used with BPv7 and also updates [RFC7116] to make it clear that IANA CBHE registries are only to be used for BPv6. This document also updates the format of the BPv7 ipn scheme to include Numbering Authorities and requests the formation of BPv7 ipn scheme IANA registries.
About This Document
The latest revision of this draft can be found at https://ricktaylor.github.io/ipn2/draft-taylor-dtn-ipn-update.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-taylor-dtn-ipn-update/.
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/ipn2.
Introduction
From the earliest days of experimentation with "store and forward" data transfer with the Bundle Protocol, the desire has existed for a simple way to enumerate the nodes and services in a Delay Tolerant Network (DTN). With the IRTF standardisation of the experimental Bundle Protocol version 6 (BPv6) [RFC5050], an associated specification for numeric node identifiers and numeric service identifiers was described in Section 2.1 of [RFC6260]. Further, [RFC6260] also defined the 'ipn' Endpoint Identifier (EID) naming scheme which identifies a DTN endpoint using node and service identifiers. The acronym IPN was originally an expansion of the term "InterPlanetary Network" as the original aim of this scheme was to provide a compact namespace for an interoperable space-based DTN architecture.
Beyond space-based applications, terrestrial nodes might also operate with limited power, bandwidth, and/or compute budget. The adoption of DTN in the IETF, resulting in the publication of the Bundle Protocol version 7 (BPv7) [RFC9171], will result in operational deployments of BPv7 nodes for both terrestrial and non-terrestrial use cases. This includes BPv7 networks operating over the terrestrial Internet and BPv7 networks operating in self-contained environments behind a shared administrative domain.
In all cases, concisely encoded numeric identifiers for both nodes and services provides processing advantages over more verbose naming schemes. Therefore additional focus has been placed on the capabilities of the 'ipn' scheme for use beyond its historical purpose for space-based DTN architectures. This expanded use of the 'ipn' scheme for BPv7 networks requires both some updates to the 'ipn' scheme itself and a clearer distinction between the uses of 'ipn' schemes in BPv6 and BPv7 networks.
This document updates the definition of the 'ipn' scheme (in ways that are backwards compatible for existing 'ipn' uses) to include adding an optional naming authority to distinguish node namespaces. This document also defines new IANA registries associated with both the updated IPN scheme and the use of node and service identifiers for use specifically with BPv7.
Conventions and Definitions
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.
The Legacy 'ipn' Scheme in RFC9171
This section describes the specification of the 'ipn' EID scheme as defined in [RFC9171] and is included as convenient reference for the rest of this document.
Encoding
Section 4.2.5.1.2 of [RFC9171] specifies the 'ipn' EID scheme for BPv7, with an identical format to the specification of the 'ipn' EID scheme for BPv6 in Section 2.1 of [RFC6260], namely as a sequence of two unsigned integers. The first number representing the identifier of the node (node-nbr), and the second being the identifier of a particular service expected at that node (service-nbr).
Text Encoding
As specified in [RFC9171], the textual encoding of an 'ipn' scheme EID must comply with the following ABNF [RFC5234] syntax, including the core ABNF syntax rule for DIGIT defined by that specification:

ipn-uri = "ipn:" ipn-hier-part

ipn-hier-part = node-nbr nbr-delim service-nbr

node-nbr = 1*DIGIT

nbr-delim = "."

service-nbr = 1*DIGIT

CBOR Encoding
As specified in [RFC9171], when encoded in Concise Binary Object Representation (CBOR) [RFC8949], an 'ipn' scheme EID must comply with the following Concise Data Definition Language (CDDL) [RFC8610] specification:

eid = $eid .within eid-structure

eid-structure = [
  uri-code: uint,
  SSP: any
]

; ... Syntax for uri-code 1 (dtn scheme) omitted ...

$eid /= [
  uri-code: 2,
  SSP: [
    nodenum: uint,
    servicenum: uint
  ]
]

Because the encoding of node-nbr and service-nbr (specified in the CDDL as nodenum and servicenum) are defined as CBOR uint types, both values are restricted by this encoding to a range of [0 .. 2^64-1].
Uniqueness Constraints
As described in Section 4.2.5.2 of [RFC9171], the identifier of a node (Node ID) must be a singleton endpoint, see Section 3.1 of [RFC9171]. Section 3.2.2 of [RFC7116] allocates the service-nbr 0 to the 'Bundle Protocol Administrative Record' for the 'ipn' EID scheme for BPv6, and Section 4.2.5.1.2 of [RFC9171] derives from this earlier specification, and more loosely states that the service-nbr zero (0) MAY identify the 'administrative endpoint' of a node, and in combination with a valid node-nbr, it can be used as a BPv7 Node ID.
From this we can deduce the following rules:
1. An 'ipn' scheme EID, perhaps with service-nbr 0, MAY be a valid unique Node ID when used with BPv7.
2. Because the node-nbr component of 'ipn' scheme EIDs of all services on a node must be identical, when used with BPv7, the node-nbr component MUST be unique to each node within a given network.
Because the ipn scheme encodes the Node Id, every 'ipn' scheme EID is a singleton EID. This means the following: 1. Only a single node can ever be registered in a given 'ipn' scheme EID at a given time. 1. Every 'ipn' scheme EID to which a node is registered must share the same node-nbr.
Global Flat Namespace
Since the legacy ipn scheme encodes the Node ID as the node number, and the Node ID must be a globally unique identifier, this means that the legacy ipn scheme node-nbrs must, themselves, be globally unique. The legacy ipn scheme node-nbr exists in a single, global, flat namespace.
The reliance on such a namespace is not problematic when deploying a private, self-contained network: If there are few nodes that can ever intercommunicate, then those nodes can have node-nbrs allocated by the administrator of that network and there will be no problem with uniqueness coming from a serialized, central authority. However, as the number of nodes and number of administrative authorities in a network scale, the administrative burden of assigning node-nbrs increases.
Allocation Ranges
A potential solution to this, as described in Section 3.2.1 of [RFC7116], is to assign ranges of node-nbrs to different authorities, from which they can independently allocate node-nbrs.
The use of a global, flat namespace (in general) and the use of predefined allocations (in particular) present two practical problems relating to encoding efficiency and namespace exhaustion.
This division of the number space is an adequate solution for the uniqueness problem, but it introduces a new issue: The encoding-length of each node-nbr is no longer minimal, as the offset to the start of the range assigned to the allocating authority is included in the node-nbr. For example: Section 3.2.1 of [RFC7116] allocates [CCSDS] the range [2^14 .. 2^21-1] for node-nbrs for use with BPv6, and if CCSDS choses to continue to use this number range for BPv7, the CBOR encoding of every Node ID will be at least 7 octets (including 2 octets for the outer array with uri-code), even when interoperability is not required:

82            # array(2)
   02         # uri-code: 2
   82         # array(2)
      19 4000 # node-nbr: 16384
      00      # service-nbr: 0

Another side-effect of assigning ranges of the number space to different sub-allocating authorities is to reduce the total availability of node-nbrs. Although the current allocation strategy defined in [RFC7116] leaves approximately 2^42 numbers unallocated, the recommendation to IANA is that these numbers should be allocated in blocks of 2^14. The history of IPv4 address allocation, see Section 2.1 of [RFC1287], demonstrates that exhaustion of a 2^32 bit number space happens surprisingly quickly.
Updates to RFC7116 and RFC9171
This section updates the use of 'ipn' scheme EIDs when used with BPv7 as specified in [RFC9171] to address some of the limitations described above, and renames two of the registries defined in [RFC7116] to clarify their usage with BPv6 only.
BPv7 'ipn' Scheme Node Numbers
The following rules update or clarify the specification of node-nbr in Section 4.2.5.1.2 of [RFC9171]:
1. The node-nbr component of an 'ipn' scheme EID MUST be an unsigned integer >= 0.
2. The 'ipn' scheme EID "ipn:0.0" is assigned to the 'null' endpoint, see Section 3.2 of [RFC9171].
3. If the node-nbr component of an 'ipn' scheme EID is zero (0), then the service-nbr component MUST be zero (0).
4. Values >= 2^64 for the node-nbr component of an 'ipn' scheme EID are 'Reserved', see Section 6 of [RFC8126], to allow concise unsigned integer (type 0) CBOR encoding.
BPv6 'ipn' Scheme Node Numbers
The "CBHE Node Numbers" registry specified in Section 3.2.1 of [RFC7116] is renamed without change to the "Bundle Protocol Version 6 'ipn' Scheme Node Numbers" registry, to clarify that it is for use solely with BPv6, see IANA Considerations.
BPv7 'ipn' Scheme Service Numbers
The following rules update or clarify the specification of service-nbr in Section 4.2.5.1.2 of [RFC9171], deriving from the definitions in Section 3.2.2 of [RFC7116]:
1. The service-nbr component of an 'ipn' scheme EID MUST be an unsigned integer >= 0.
2. The administrative endpoint as defined in Section 3.2 of [RFC9171] of an 'ipn' scheme EID MUST be service-nbr zero (0).
3. Values >= 2^64 for the service-nbr component of an 'ipn' scheme EID are 'Reserved', see Section 6 of [RFC8126], to allow concise unsigned integer (type 0) CBOR encoding.
To support this update, a new IANA "Bundle Protocol Version 7 'ipn' Scheme Service Numbers" registry is defined for the service-nbr component of an 'ipn' scheme EID when used with BPv7.
BPv6 'ipn' Scheme Service Numbers
The "CBHE Service Numbers" registry specified in Section 3.2.2 of [RFC7116] is renamed without change to the "Bundle Protocol Version 6 'ipn' Scheme Service Numbers" registry, to clarify that it is for use solely with BPv6, see IANA Considerations.
The Interoperable BPv7 'ipn' Scheme
The consequence of the updates to the 'ipn' EID scheme described above is to remove any capability to send bundles between nodes with 'ipn' scheme EIDs enumerated by two different allocating authorities, as there is no explicit indication of which authority allocated which corresponding node-nbr, resulting in a violation of the uniqueness constraints. This situation is obviously untenable when building DTNs beyond a fairly small scale.
Numbering Authorities
Underlying the BPv6 'ipn' scheme node-nbr range assignment if [RFC7116] is the desire to reduce the administrative burden on a single allocation authority for all node-nbrs by delegating the authority to assign numbers to a pre-agreed set of numbering authorities. Although the range-based mechanism of delegating this authority has been criticised above, the desire for delegation of numbering to a group of independent authorities in an interoperable way is still valid.
To address this, this document introduces the concept of Numbering Authorities. A Numbering Authority has a unique numeric identifier, but has the authority to allocate any node-nbr in the full 2^64 unsigned integer range according to its own rules. In order to ensure interoperability between Numbering Authorities, a new IANA "Bundle Protocol Version 7 'ipn' Scheme Authority Numbers" registry is defined for the registration of Authority Numbers, see IANA Considerations. Although the uniqueness of Numbering Authority identifiers is required for interoperable DTN operations, identifier ranges are explicitly reserved for experimentation and private use for when interoperability is not required.
To ensure interoperability, Numbering Authorities MUST allocate node numbers according to the following rules:
1. The node-nbr zero (0) MUST not be allocated, to avoid potential confusion with the 'null' endpoint.
2. Values >= 2^64 for the node-nbr component of an 'ipn' scheme EID MUST NOT be allocated, to ensure concise unsigned integer (type 0) CBOR encoding.
Numbering Sub-authorities
Some organisations that register as Numbering Authorities may be sufficiently large that acting as a single allocating authority for their desired number range becomes administratively untenable, for example government agencies. In this case, the ability to delegate number allocation to sub-authorities is desired. To address this, this specification permits the addition of a Numbering Sub-authority numeric identifier, when required, from a registry controlled by the Numbering Authority to the Interoperable BPv7 'ipn' scheme EID.
In order to avoid unbounded sequences of sub-sub-authorities, making processing in constrained devices overly onerous, only a single Numbering Sub-authority is permitted in an Interoperable BPv7 'ipn' scheme EID.
The Local Numbering Authority
The numeric identifier zero (0) is allocated in the "Bundle Protocol Version 7 'ipn' Scheme Authority Numbers" registry for the Local Numbering Authority. When a bundle processing agent processes a bundle containing EIDs using the Interoperable BPv7 'ipn' scheme, with a Numbering Authority identifier of zero (0), the Numbering Authority identifier of such EIDs MUST considered to be the same as the Numbering Authority of the 'ipn' scheme NodeId of the bundle processing agent.
The Local Numbering Authority does not support Numbering Sub-authorities, and therefore any Numbering Sub-authority identifier MUST NOT be included when composing Interoperable BPv7 'ipn' scheme EIDs. When a bundle processing agent encounters an Interoperable BPv7 'ipn' scheme EID with Number Authority identifier zero (0) and a Numbering Sub-authority identifier, then the Numbering Sub-authority identifier MUST be ignored.
Backwards Compatibility
Although the Interoperable BPv7 'ipn' EID scheme introduces the ability to include Numbering Authority identifiers, it does not preclude the use of BPv7 'ipn' scheme EIDs without such an identifier. To allow for backwards compatibility, when a bundle processing agent processes a BPv7 bundle containing 'ipn' scheme EIDs without a Numbering Authority identifier, unless the EID is the 'null' endpoint (ipn:0.0), the Numbering Authority identifier MUST considered to be zero (0), and therefore treated in the the same manner as the Local Numbering Authority.
Prefix Encoding
Fundamentally, [RFC9171] 'ipn' scheme EIDs are represented as a sequence of unsigned integers: In the text encoding, the numbers are separated with the '.' delimiter; in CBOR, encoded as an array of unsigned integers. Adding the numeric identifier of the numbering authority, possibly with sub-authorities, that allocated the subsequent node-nbr as a prefix to EIDs allows for a concise encoding of a suitable discriminator, without reducing the total availability of node-nbrs.
In the text encoding, this is as simple as pre-pending numeric identifiers for the numbering authorities, separated with the '.' delimiter, to the text. For the CBOR encoding, this is achieved by increasing the dimension of the array of unsigned integers to include the relevant numbering authority identifiers.
For example, the EID "ipn:2.1.0" uniquely identifies the administrative endpoint of the node allocated the node-nbr 1 by the numbering authority with identifier 2. This EID can be concisely encoded in CBOR as 6 octets, including 2 octets for the outer array with uri-code:

82       # array(2)
   02    # uri-code: 2
   83    # array(3)
      02 # auth-nbr: 2
      01 # node-nbr: 1
      00 # service-nbr: 0

This prefixing method is be extended to allow numbering authorities to delegate allocation of numbers to sub-authorities as they see fit, by appending further sub-authority identifiers to the prefix.
Text Encoding
The textual encoding of an 'ipn' scheme EID MUST comply with the following ABNF [RFC5234] syntax, including the core ABNF syntax rule for DIGIT defined by that specification:

ipn-uri = "ipn:" ipn-hier-part

ipn-hier-part = auth-part? node-nbr nbr-delim service-nbr

auth-part = auth-nbr nbr-delim sub-auth-part?

sub-auth-part = sub-auth-nbr nbr-delim

auth-nbr = 1*DIGIT

sub-auth-nbr = 1*DIGIT

node-nbr = 1*DIGIT

service-nbr = 1*DIGIT

nbr-delim = "."

CBOR Encoding
When encoded in Concise Binary Object Representation (CBOR) [RFC8949], an 'ipn' scheme EID MUST comply with the following Concise Data Definition Language (CDDL) [RFC8610] specification:

eid = $eid .within eid-structure

eid-structure = [
  uri-code: uint,
  SSP: any
]

; ... Syntax for other uri-code values defined in RFC9171 ...

$eid /= [
  uri-code: 2,
  SSP: [
    ? authority,
    node-nbr: uint,
    service-nbr: uint
  ]
  authority = (
    auth-nbr: uint,
    ? sub-auth-nbr: uint
  )
]

Because the encoding of auth-nbr, sub-auth-nbr, node-nbr, and service-nbr are defined as CBOR uint types, all values are restricted by this encoding to a range of [0 .. 2^64-1].
Recommendations
[RFC9171] mandates the concept of "late binding" of an EID, where-by the address of the destination of a bundle is resolved from its identifier hop by hop as it transits a DTN. This per-hop binding of identifiers to addresses underlines the fact that EIDs are purely names, and may not carry any implicit or explicit information concerning the current location or reachability of an identified node and service. This removes the need to rename a node as its location changes.
Because of this late binding concept, the authority components of an interoperable 'ipn' scheme EID SHOULD NOT be regarded as some kind of "type field", and used to derive additional information from the other components of the EID. An example of incorrect behaviour would be: "I know authority X allocates node-nbrs derived from the MAC address of some link-layer device on each node, and so I can just send packets directly to that MAC address". No matter the authority that controls the allocation of node-nbrs, they remain just numbers, without additional meaning.
Security Considerations
TODO
IANA Considerations
The following sections detail requests to IANA for new registries, and the renaming of existing registries.
Bundle Protocol Version 7 'ipn' Scheme Service Numbers registry
IANA is requested to create a new registry entitled "Bundle Protocol Version 7 'ipn' Scheme Service Numbers"
The registration policy for this registry is:
Bundle Protocol Version 7 'ipn' Scheme Service Numbers registration policies
Range | Registration Policy
0 .. 23 | RFC Required
24 .. 4095 | Specification Required
4096 .. 2^32-1 | Private Use
2^32 .. 2^64-1 | Experimental Use
>= 2^64 | Reserved
The initial values for the registry are:
Bundle Protocol Version 7 'ipn' Scheme Service Numbers initial values
Value | Description | Reference
0 | The administrative endpoint | This document
Bundle Protocol Version 7 'ipn' Scheme Authority Numbers registry
IANA is requested to create a new registry entitled "Bundle Protocol Version 7 'ipn' Scheme Authority Numbers"
The registration policy for this registry is:
Bundle Protocol Version 7 'ipn' Scheme Authority Numbers registration policies
Range | Registration Policy
0 .. 2^16-1 | First Come First Served
2^16 .. 2^32-1 | Private Use
2^32 .. 2^64-1 | Experimental Use
>= 2^64 | Reserved
The initial values for the registry are:
Bundle Protocol Version 7 'ipn' Scheme Authority Numbers initial values
Value | Description | Reference
0 | The Local Numbering Authority | This document
CBHE Node Numbers registry
IANA is request to rename the "CBHE Node Numbers" registry defined in Section 3.2.1 of [RFC7116] to the "Bundle Protocol Version 6 'ipn' Scheme Node Numbers", with no change to its allocation rules or current allocations.
CBHE Service Numbers registry
IANA is requested to rename the "CBHE Service Numbers" registry defined in Section 3.2.2 of [RFC7116] to the "Bundle Protocol Version 6 'ipn' Scheme Service Numbers", with no change to its allocation rules or current allocations.
References
Normative References
[RFC8126]

Guidelines for Writing an IANA Considerations Section in RFCs
M. Cotton
B. Leiba
T. Narten
June 2017
BCP 26
RFC 8126
DOI 10.17487/RFC8126
[RFC7116]

Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries
K. Scott
M. Blanchet
February 2014
RFC 7116
DOI 10.17487/RFC7116
[RFC9171]

Bundle Protocol Version 7
S. Burleigh
K. Fall
E. Birrane
III
January 2022
RFC 9171
DOI 10.17487/RFC9171
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC5234]

Augmented BNF for Syntax Specifications: ABNF
D. Crocker, Ed.
P. Overell
January 2008
STD 68
RFC 5234
DOI 10.17487/RFC5234
[RFC8949]

Concise Binary Object Representation (CBOR)
C. Bormann
P. Hoffman
December 2020
STD 94
RFC 8949
DOI 10.17487/RFC8949
[RFC8610]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
Informative References
[RFC1287]

Towards the Future Internet Architecture
D. Clark
L. Chapin
V. Cerf
R. Braden
R. Hobby
December 1991
RFC 1287
DOI 10.17487/RFC1287
[CCSDS]

The Consultative Committee for Space Data Systems
[RFC6260]

Compressed Bundle Header Encoding (CBHE)
S. Burleigh
May 2011
RFC 6260
DOI 10.17487/RFC6260
[RFC5050]

Bundle Protocol Specification
K. Scott
S. Burleigh
November 2007
RFC 5050
DOI 10.17487/RFC5050
Discussion Points
(This whole section is to be removed prior to publication)
Why not just sub-divide the BPv7 'ipn' node-nbr space like BPv6?
See Allocation Ranges.
Why not a new 'ipn3' EID scheme?
Is there really any difference in outcome between the following cases?:
1. An existing parser receives a bundle with an EID with a 3-ary ipn EID
2. An existing parser receives a bundle with an EID with an unrecognised scheme identifier
In the former case, the parser will recognised the scheme as 'ipn' but then fail as the dimension of the subsequent array is not 2. In the latter case the parser will fail one octet earlier when the scheme is not recognised. In both cases, the EID will not be recognised as valid, forwarding will be "contraindicated", and the process described in Step 2 of Section 5.4 of [RFC9171] should be followed.
It is believed that introducing a new EID scheme will just result in fragmentation of support. 'ipn' is popular because it is simple; let's not introduce another 'simple' EID scheme to compete with it, but rather add just enough support for universal interoperability. 'ipn' as defined in RFC9171 needs clarification, so why not just add the tweaks necessary as long as we don't break back-compatibility?
Why not use just the 'dtn' scheme for interoperability?
Because the 'dtn' scheme definition in RFC9171 is intentionally left wide open for further work. That work has yet to happen and is a considered a much more complex task than a simple update to the 'ipn' scheme.
Won't these changes break BPv6 compatibility?
Because of the difference in encoding between BPv6 and BPv7, there is no on-the-wire compatibility between the versions. Any 'dual-stack' gateway BPA is going to have to encapsulate BPv6 in BPv7 (or vice-versa), so the EID of the decapsulating endpoint will have to be used in the 'envelope' bundle. There is no way a BPv7 node can send a bundle to a BPv6 node directly using BPv7, so backwards compatibility of EIDs between protocol versions is not needed.
Why not have an unbounded number of sub-authorities?
It's possible to encode, and has been considered by the authors, but the conclusion was:
ipn:it.is.really.not.a.great.idea.to.have.unbounded.sequences.of.identifiers.when.it.comes.to.processing.EIDs.in.constrained.environments.0
An optional, single sub-authority seemed like a sensible idea, but feel free to argue on the list for more.
Acknowledgments
TODO acknowledge.