Internet-Draft ipn-update October 2022
Taylor & Birrane Expires 16 April 2023 [Page]
Workgroup:
Delay/Disruption Tolerant Networking
Internet-Draft:
draft-taylor-dtn-ipn-update-02
Updates:
[9171, 7176] (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
R. Taylor
Ori Industries
E. Birrane
JHU/APL

Update to the DTN ipn Endpoint Identifier scheme

Abstract

The 'ipn' URI scheme was first defined in [RFC6260] as a format for endpoint identifiers with the Delay Tolerant Networking Bundle Protocol version 6 (BPv6) [RFC5050], when using Compressed Bundle Header Encoding (CBHE). [RFC7116] requested IANA registries to control the allocation of the numeric identifiers used with the 'ipn' URI scheme. The Bundle Protocol version 7 (BPv7) specification [RFC9171] repeats the definition of the 'ipn' URI scheme, for use with BPv7, reusing the format from [RFC6260]. Because the specification of the 'ipn' URI scheme has been split over several documents, referencing different versions of the Bundle Protocol, some confusion has occurred amongst readers and implementers. This document pulls together the information contained in those previous documents and asserts the specification of the 'ipn' URI scheme for use with BPv7, acting as an update to those previous documents.

A criticism of the existing 'ipn' URI scheme node number allocation strategy as defined in [RFC7116] is that sub-ranges of a single number space are assigned for the use by individual organisations. This allocation strategy results in inefficient encoding of URIs with BPv7. This document extends the format of the 'ipn' URI scheme to include Numbering Authorities, allowing for a more flexible sub-allocation strategy, resulting in a more efficient encoding with BPv7.

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/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.

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 16 April 2023.

Table of Contents

1. Introduction

From the earliest days of experimentation with "store and forward" data transfer with the Bundle Protocol, there has been a need to identify the source and destination of a bundle. Starting with the IRTF standardisation of the experimental Bundle Protocol version 6 (BPv6) [RFC5050], a logical source or destination of bundles is referred to as an Endpoint, with a corresponding Endpoint Identifier (EID). Rather than define yet another identifier format, the IRTF DTN Working Group decided to reuse the existing Universal Resource Identifier (URI) syntax defined in [RFC3986]. However, given the particular on-the-wire encodings of both BPv6 and BPv7, a specific encoding for every supported URI scheme must be specified in the relevant protocol specification.

Initially only encoding support for the textual 'dtn' URI scheme was specified in [RFC5050], however during implementations of BPv6, it became increasingly obvious that there was a desire for a simple way to name the endpoints in a Delay Tolerant Network (DTN) using short numeric identifiers. To address this, [RFC6260] introduced the 'ipn' URI scheme which identifies a DTN endpoint using a concatenation of node and service identifiers, with a suitable encoding for use with BPv6.

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, but beyond space-based applications, terrestrial nodes might also operate with limited power, bandwidth, and/or compute budget. 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' URI scheme for use beyond its historical purpose for space-based DTN architectures.

The publication of the Bundle Protocol version 7 (BPv7) [RFC9171] has resulted 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. This growth in the number and scale of deployments of BPv7 DTNs has been accompanied by a growth in the usage of 'ipn' URI scheme endpoint identifiers, and this has increased usage has highlighted shortcomings in the allocation strategy for such identifiers, as specified in [RFC7116].

This document collates the information contained in previous specifications, clarifying and updating the usage of 'ipn' scheme URIs when used with BPv7, as well as extending the specification of 'ipn' scheme URIs, in a backwards compatible way, to address shortcomings in the assignment of identifiers of specified in [RFC7116], concentrating on ensuring interoperable, scalable deployment of 'ipn' scheme URIs for use with BPv7 DTNs.

2. 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.

3. The 'ipn' URI Scheme as defined in RFC9171

This section describes the specification of the 'ipn' URI scheme as defined in [RFC9171] and is included as convenient reference for the remainder of this document.

A bundle endpoint may have a multiplicity of membership, allowing some EIDs to refer to a group of bundle destinations, and others to refer to only a single bundle destination. The latter are referred to as Singleton endpoints, see Section 3.1 of [RFC9171]. Both [RFC6260] and [RFC9171] specify that all 'ipn' scheme URIs identify Singleton endpoints.

Section 4.2.5.1.2 of [RFC9171] specifies the syntax of an 'ipn' scheme URI, with an identical format to the specification of the 'ipn' URI scheme syntax 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).

3.1. Text Syntax

As specified in [RFC9171], the schema-specific part of an 'ipn' scheme URI 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

3.2. CBOR Encoding

As specified in [RFC9171], a BPv7 endpoint identified by an 'ipn' scheme URI, when encoded in Concise Binary Object Representation (CBOR) [RFC8949], 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].

3.3. Node and Service Numbers

The formulation of 'ipn' scheme URIs dictates a hierarchy, whereby the URI for a particular service is composed of the well-known numeric identifier of the service, prepended with the numeric identifier of the node where the service is expected to exist. This strongly implies that all endpoints named with 'ipn scheme URIs available on a single node must share a common node-nbr, but is not explicitly specified in [RFC9171] nor [RFC6260].

The use of predefined numeric identifiers for well-known services is based on familiarity with TCP and UDP well-known port numbers for services, first introduced in [RFC1340]. Although this behaviour is not required for the correct naming of service endpoints, it has long been considered useful, and is implied in both [RFC6260] and [RFC9171].

The only service that is required to exist for BPv7, as described in Section 4.2.5.1.2 of [RFC9171], is the "administrative endpoint" of a node. This service is used as the destination for administrative control messaging needed for the correct functioning of BPv7, and is required to have a Singleton EID. A similar service is required for BPv6, and the service-nbr zero (0) is allocated for that service when using 'ipn' scheme URIs in Section 3.2.2 of [RFC7116]. [RFC9171] only recommends that the service-nbr zero (0) should be used with BPv7.

3.4. Allocation Ranges

Section 4.2.5.2 of [RFC9171] introduces the concept of the globally unique Node ID of a particular BPv7 node, specifically stating that it must be the Singleton EID of the administrative endpoint of the node. When using a 'ipn' scheme URI as an EID, the value of the service-nbr component of the URI may be reused between the EIDs of services on different nodes. This means that in order for an 'ipn' scheme URI to be used as a Node ID, the node-nbr component must be globally unique within a single interoperating DTN. This uniqueness constraint means that all the node-nbr values must be allocated from a single, global 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-nbr values 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 unique node-nbr values increases. A potential solution to this, as described in Section 3.2.1 of [RFC7116], is to pre-assign ranges of node-nbr values to different authorities, from which they can independently allocate values without risk of duplication.

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 each node-nbr value assigned by that authority. For example: Section 3.2.1 of [RFC7116] allocates [CCSDS] the range [2^14 .. 2^21-1] for node-nbr values for use with BPv6, and if CCSDS choses to continue to use this number range for BPv7, the CBOR encoding of every 'ipn' scheme URI will be at least 7 octets (including 2 octets for the outer array with uri scheme discriminator type 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 a single number space to different sub-allocating authorities is to reduce the total availability of node-nbr values. 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.

4. Updates to RFC9171

This section updates [RFC9171] to clarify the construction and use of 'ipn' scheme URIs when used as EIDs with BPv7, to address the limitations described above.

4.1. 'ipn' URI Scheme Node Numbers for BPv7

The following rules update the specification of node-nbr in Section 4.2.5.1.2 of [RFC9171]:

  1. The value of the node-nbr component of an 'ipn' scheme URI MUST be an unsigned integer greater than or equal to zero (0).
  2. The URI "ipn:0.0" is assigned to the 'null' endpoint, see Section 3.2 of [RFC9171].
  3. The value zero (0) for the node-nbr component of an 'ipn' scheme URI MUST NOT be used except as part of the URI "ipn:0.0".
  4. Values greater than or equal to 2^64 for the node-nbr component of an 'ipn' scheme URI MUST NOT be used, to allow concise unsigned integer (type 0) CBOR encoding.
  5. All 'ipn' scheme URIs for endpoints co-located on a single bundle processing node MUST share the same value for the node-nbr component.

No new IANA registry to control the allocation of values for the node-nbr component of 'ipn' scheme URIs when used as EIDs with BPV7 is defined. Their allocation is solely the concern of the administrator of the particular DTN deployment. To enable interoperation between DTNs under different administrative control a new mechanism is introduced below (Section 6).

4.2. 'ipn' URI Scheme Service Numbers for BPv7

The following rules update the specification of service-nbr in Section 4.2.5.1.2 of [RFC9171]:

  1. The value of the service-nbr component of an 'ipn' scheme URI MUST be an unsigned integer greater than or equal to zero (0).
  2. The value of the service-nbr component of an 'ipn' scheme URI of the EID of an administrative endpoint, as defined in Section 3.2 of [RFC9171], MUST be zero (0).
  3. Values greater than or equal to 2^64 for the service-nbr component of an 'ipn' scheme URI MUST NOT be used, to allow concise unsigned integer (type 0) CBOR encoding.

To support this update, a new IANA "Bundle Protocol Version 7 'ipn' Scheme URI Service Numbers" registry is defined to control the allocation of values for the service-nbr component of an 'ipn' scheme URI when used as EIDs with BPv7, see IANA Considerations (Section 8).

5. Updates to RFC7116

This section renames two of the registries defined in [RFC7116], without change, to clarify their use for the allocation of node and service numbers for BPv6 only.

5.1. 'ipn' URI Scheme Node Numbers for BPv6

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 URI Node Numbers" registry, to clarify that it is for use solely with BPv6, see IANA Considerations (Section 8).

5.2. 'ipn' URI Scheme Service Numbers for BPv6

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 URI Service Numbers" registry, to clarify that it is for use solely with BPv6, see IANA Considerations (Section 8).

6. Update to the 'ipn' URI Scheme

A consequence of their not being a central registry of allocated values for node-nbr components for 'ipn' scheme URIs, and instead leaving their allocation to the administrators of a given DTN deployment, is that if two or more deployments wish to interoperate, there must be agreement between the respective administrators around the policy for the allocation of numbers to avoid duplication. This situation is obviously untenable when building DTNs beyond a fairly small scale.

Underlying the 'ipn' scheme URI node-nbr range assignment for BPv6, described in [RFC7116], is the desire to reduce the administrative burden on a single allocation authority by delegating the authority to assign numbers to a registered set of numbering authorities. Although the range-based mechanism of delegating this authority has been criticised above (Section 3.4), the desire for delegation of numbering to a group of independent authorities in an interoperable way is still valid.

6.1. Numbering Authorities

To address this, this document introduces the concept of Numbering Authorities. A Numbering Authority has a unique numeric identifier, and this identifier is used to discriminate between the values of node-nbr components of 'ipn' scheme URIs allocated by different Numbering Authorities. The use of this identify allows a Numbering Authority to allocate any value to the node-nbr component of an 'ipn' scheme URI, in the full 2^64 unsigned integer range, according to its own policies, as permitted by the rules in the 'ipn' URI Scheme Node Numbers for BPv7 (Section 4.1) section of this document.

A new IANA "Bundle Protocol Version 7 'ipn' Scheme URI Authority Numbers" registry is defined for the registration of Authority Numbers, see IANA Considerations (Section 8). 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 such interoperability is not required.

6.1.1. 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 introduces a Numbering Sub-authority numeric identifier, to be used when required, allocated from a registry controlled by each independent Numbering Authority. In order to avoid unbounded nesting of sub-sub-authorities, making processing in constrained devices overly onerous, only a single level of Numbering Sub-authority is permitted.

6.2. Prefix Encoding

Fundamentally, [RFC9171] 'ipn' scheme URIs are represented as a sequence of identifiers: In the text syntax, the numbers are separated with the '.' delimiter; in CBOR, encoded as an array of unsigned integers. Adding the numeric identifier of the numbering authority, and optional sub-authority, that allocated the node-nbr to the sequence of identifiers allows for a concise encoding.

In the text syntax, the numeric identifiers for the numbering authority, and optional sub-authority, are prepended to the text, separated with the '.' delimiter. For the CBOR encoding, the dimension of the unsigned integer array is increased to include the required numbering authority and sub-authority identifiers.

For example, the URI "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 URI 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

6.2.1. Text Syntax

The text syntax of an 'ipn' scheme URI 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 = number

sub-auth-nbr = number

node-nbr = number

service-nbr = number

number = "0" \ (%x31-39 *DIGIT)  ; No excess leading '0's

nbr-delim = "."

Additional leading zeros ('0') MUST NOT appear in the textual representation of any component of an 'ipn' scheme URI.

6.2.2. CBOR Encoding

A BPv7 endpoint identified by an 'ipn' scheme URI, when encoded in Concise Binary Object Representation (CBOR) [RFC8949], 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].

6.2.3. The Local Numbering Authority

The numeric identifier zero (0) is allocated in the "Bundle Protocol Version 7 'ipn' Scheme URI Authority Numbers" registry for the Local Numbering Authority. When a node processes a BPv7 bundle containing 'ipn' scheme URIs, with a Numbering Authority identifier of zero (0), the Numbering Authority identifier of such URIs MUST be considered to be the same as the Numbering Authority of any 'ipn' scheme URIs used for endpoints existing on the node.

The Local Numbering Authority does not support Numbering Sub-authorities, and therefore any Numbering Sub-authority identifier MUST NOT be included when composing 'ipn' scheme URIs. When a bundle processing agent encounters an 'ipn' scheme URI with Number Authority identifier zero (0) and a Numbering Sub-authority identifier, then the Numbering Sub-authority identifier MUST be ignored.

6.2.4. Backwards Compatibility

Although this update to the 'ipn' URI scheme introduces the ability to include Numbering Authority identifiers, it does not preclude the use of 'ipn' scheme URIs without such an identifier. To allow for backwards compatibility, when a node processes a BPv7 bundle containing 'ipn' scheme URIs without a Numbering Authority identifier, unless the URI identifies 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 (Section 6.2.3).

6.3. 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 should 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 'ipn' scheme URI SHOULD NOT be regarded as some kind of "type field", and used to derive additional information from the other components of the URI. An example of incorrect behaviour would be: "I know authority X allocates node-nbr values 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-nbr values, they remain just numbers, without additional meaning.

7. Security Considerations

TODO

8. IANA Considerations

The following sections detail requests to IANA for new registries, and the renaming of existing registries.

8.1. Bundle Protocol Version 7 'ipn' Scheme URI Authority Numbers registry

IANA is requested to create a new registry entitled "Bundle Protocol Version 7 'ipn' Scheme URI Authority Numbers"

The registration policy for this registry is:

Table 1: Bundle Protocol Version 7 'ipn' Scheme URI 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:

Table 2: Bundle Protocol Version 7 'ipn' Scheme URI Authority Numbers initial values
Value Description Reference
0 The Local Numbering Authority This document (Section 6.2.3)
1 [CCSDS] To be defined - pre-allocated as a courtesy, as they have an existing allocation in Section 3.2.1 of [RFC7116]

8.2. Bundle Protocol Version 7 'ipn' Scheme URI Service Numbers registry

IANA is requested to create a new registry entitled "Bundle Protocol Version 7 'ipn' Scheme URI Service Numbers"

The registration policy for this registry is:

Table 3: Bundle Protocol Version 7 'ipn' Scheme URI 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:

Table 4: Bundle Protocol Version 7 'ipn' Scheme URI Service Numbers initial values
Value Description Reference
0 The administrative endpoint This document

8.3. 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 URI Node Numbers" registry, with no change to its allocation rules or current allocations.

8.4. 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 URI Service Numbers" registry, with no change to its allocation rules or current allocations.

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5234]
Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, , <https://www.rfc-editor.org/rfc/rfc5234>.
[RFC6260]
Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", RFC 6260, DOI 10.17487/RFC6260, , <https://www.rfc-editor.org/rfc/rfc6260>.
[RFC7116]
Scott, K. and M. Blanchet, "Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries", RFC 7116, DOI 10.17487/RFC7116, , <https://www.rfc-editor.org/rfc/rfc7116>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[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, , <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, , <https://www.rfc-editor.org/rfc/rfc8949>.
[RFC9171]
Burleigh, S., Fall, K., Birrane, E., and III., "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, , <https://www.rfc-editor.org/rfc/rfc9171>.

9.2. Informative References

[CCSDS]
"The Consultative Committee for Space Data Systems", <http://www.ccsds.org>.
[RFC1287]
Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby, "Towards the Future Internet Architecture", RFC 1287, DOI 10.17487/RFC1287, , <https://www.rfc-editor.org/rfc/rfc1287>.
[RFC1340]
Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340, DOI 10.17487/RFC1340, , <https://www.rfc-editor.org/rfc/rfc1340>.
[RFC3986]
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, , <https://www.rfc-editor.org/rfc/rfc3986>.
[RFC5050]
Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, , <https://www.rfc-editor.org/rfc/rfc5050>.

Appendix A. Discussion Points

(This whole section is to be removed prior to publication)

A.2. 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?

A.3. 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.

A.4. 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.

A.5. 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.

Authors' Addresses

Rick Taylor
Ori Industries
Ed Birrane
JHU/APL