Internet-Draft ipn-update May 2023
Taylor & Birrane Expires 12 November 2023 [Page]
Workgroup:
Delay/Disruption Tolerant Networking
Internet-Draft:
draft-ietf-dtn-ipn-update-03
Updates:
[9171, 7176] (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
R. Taylor
Ori Industries
E. Birrane
JHU/APL

Update to the ipn URI scheme

Abstract

This document updates both the specification of the ipn URI scheme previously defined in [RFC7116] and the rules for encoding of these URIs when used as an Endpoint Identifier (EID) in Bundle Protocol Version 7 (BPv7) as defined in [RFC9171]. These updates update and clarify the structure and behavior of the ipn URI scheme, define encodings of ipn scheme URIs, and establish the registries necessary to manage this scheme.

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-ietf-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 12 November 2023.

Table of Contents

1. Introduction

The ipn URI scheme was originally defined in [RFC7116] as a way to identify network nodes and node services using concisely-encoded integers that can be processed faster and with fewer resources than other verbose identifier schemes. The scheme was designed for use with the experimental Bundle Protocol version 6 (BPv6, [RFC5050]) and IPN was defined as an acronym for the term "InterPlanetary Network" in reference to its intended use for deep-space networking. Since then, the efficiency benefit of integer identifiers makes ipn scheme URIs useful for any networks operating with limited power, bandwidth, and/or compute budget. Therefore the term IPN is now used as a non-acronymous name.

Similar to the experimental BPv6, the standardized Bundle Protocol version 7 (BPv7, [RFC9171]) codifies support for the use of the ipn URI scheme for the specification of bundle Endpoint Identifiers (EIDs). The publication of BPv7 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. The growth in the number and scale of deployments of BPv7 DTNs has been accompanied by a growth in the usage of the ipn URI scheme which has highlighted areas to improve the structure, moderation, and management of this scheme.

This document updates the specification of the ipn URI scheme, in a backwards-compatible way, to provide needed improvements both in the scheme itself and its usage to specify EIDs with BPv7. Specifically, this document introduces a hierarchical structure for the assignment of ipn scheme URIs, clarifies the behavior and interpretation of ipn scheme URIs, defines efficient encodings of ipn scheme URIs, and updates/defines the registries associated for this scheme.

Although originally developed by the deep space community for use with Bundle Protocol, the ipn URI scheme is sufficiently generic to be used in other environments where a concise unique representation of a resource on a particular node is required.

It is important to remember that like most other URI schemes, the ipn URI scheme defines a unique identifier of a resource, and does not include any topological information describing how to route messages to that resource.

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.

For the remainder of this document the term "ipn URI" is used to refer to a URI that uses the ipn scheme.

3. Core Concepts

All ipn URIs, no matter the textual representation or binary encoding, MUST be considered as a tuple of the following three components:

The Allocator Identifier indicates the entity responsible for assigning Node Numbers to individual resource nodes, maintaining uniqueness whilst avoiding the need for a single registry for all assigned Node Numbers. See Allocator Identifiers (Section 3.2).

The Node Number is a shared identifier assigned to all ipn URIs for resources co-located on a single node. See Node Numbers (Section 3.3).

The Service Number identifies the particular type of service of a resource. See Service Numbers (Section 3.5).

The combination of these three components guarantees that every correctly constructed ipn URI uniquely identifies a single resource. Additionally, the combination of the Allocator identifier and the Node Number provides a mechanism to uniquely identify the node on which a particular resource is expected to exist. See Fully-qualified Node Number (Section 3.3.1).

When considered from the perspective of BPv7, a Node Number is shared by all endpoints co-located on a single bundle processing node, and a Service Number identifies a certain type of bundle processing service.

3.1. The Null ipn URI

It has been found that there is value in defining a unique 'null' ipn URI to indicate "nowhere". This ipn URI is termed the "Null ipn URI", and has all three components: Allocator Identifier, Node Number, and Service Number, set to the value zero (0). No resource identified by Null ipn URI exists, and is therefore by definition unreachable.

3.2. Allocator Identifiers

An Allocator is any organization that wishes to assign Node Numbers for use with the ipn URI scheme, and has the facilities and governance to manage a public registry of assigned Node Numbers. The authorization to assign these numbers is provided through the assignment of an Allocator Identifier by IANA. Regardless of other attributes of an Allocator, such as a name, point of contact, or other identifying information, Allocators are identified by Allocator Identifiers: a unique, unsigned integer.

The Allocator Identifier MUST be the sole mechanism used to identify the Allocator that has assigned the Node Number in an ipn URI. An Allocator may have multiple assigned Allocator Identifiers, but a given Allocator Identifier MUST only be associated with a single Allocator.

A new IANA "'ipn' Scheme URI Allocator Identifiers" registry is defined for the registration of Allocator Identifiers, see 'ipn' Scheme URI Allocator Identifiers registry (Section 9.1). Although the uniqueness of Allocator identifiers is required to enforce uniqueness of ipn URIs, some identifiers are explicitly reserved for experimentation or future use.

Each Allocator assigns Node Numbers according to its own policies, without risk of creating an identical ipn URI, as permitted by the rules in the Node Numbers (Section 3.3) section of this document. Other than ensuring that any Node Numbers it allocates are unique amongst all Node Numbers it assigns, an Allocator does not need to coordinate its allocations with other Allocators.

If a system does not require interoperable deployment of ipn scheme URIs, then the Private Use Node Number range, reserved by the Default Allocator (Section 3.2.2) for this purpose SHOULD be used.

3.2.1. Allocator Identifier Ranges

Some organizations with internal hierarchies may wish to delegate the allocation of Node Numbers to one or more of their sub-organizations. Rather than assigning unique Allocator Identifiers to each sub-organization on a first-come first-served basis, there are operational benefits in assigning Allocator Identifiers to such an organization in a structured way so that an external observer can detect that a group of Allocator Identifiers are organizationally associated.

An Allocator Identifier range is a set of consecutive Allocator Identifiers associated with the same Allocator. Each individual Allocator Identifier in a given range SHOULD be assigned to a distinct sub-organization of the Allocator. Assigning identifiers in this way allows external observers to both associate individual Allocator Identifiers with a single organization and to usefully differentiate amongst sub-organizations.

The practice of associating a consecutive range of numbers with a single organization is inspired by the Classless Inter-domain Routing assignment of Internet Addresses described in [RFC4632]. In that assignment scheme, an organization (such as an Internet Service Provider) is assigned a network prefix such that all addresses sharing that same prefix are considered to be associated with that organization.

Each Allocator Identifier range is identified by the first Allocator Identifier in the range and the number of consecutive identifiers in the range.

Allocator Identifier ranges differ from CIDR addresses in two important ways.

  1. Allocator Identifiers are used to identify organizations and are not, themselves, addresses.
  2. Allocator Identifiers may be less than 32 bits in length.

In order to differentiate between Allocator Identifier ranges using efficient bitwise operations, all ranges MUST be of a length that is a power of 2, and for given range of length N bits, the least-significant N bits of the first Allocator Identifier MUST be all 0.

An example of the use of Allocator Identifier ranges for four organizations (A, B, C, and D) is as follows:

Table 1: Allocator Identifier Range Assignment Example
Organization Range (dec) Range (hex) Range Length (Bits)
Org A 974848 .. 974975 0xEE000 .. 0xEE07F 7 bits
Org B 974976 .. 974991 0xEE080 .. 0xEE08F 4 bits
Org C 974992 .. 974993 0xEE090 .. 0xEE091 1 bit
Org D 974994 0xEE092 0 bits

With these assignments, any Allocator Identifier whose most-significant 25 bits match 0xEE000 belong to organization A. Similarly, any Allocator Identifier whose most-significant 28 bits match 0xEE080 belong to organization B and any Allocator Identifier whose most-significant 31 bits are 0xEE090 belong to organization C. Organisation D has a single Allocator Identifier, and hence a range of bit-length 0.

3.2.2. The Default Allocator

As of the publication of [RFC7116], the only organization permitted to assign Node Numbers was the Internet Assigned Numbers Authority (IANA) which assigned Node Numbers via the IANA "CBHE Node Numbers" registry. This means that all ipn URIs created prior to the addition of Allocator Identifiers are assumed to have Node Number allocations that comply with the IANA "CBHE Node Numbers" registry.

The presumption that, unless otherwise specified, Node Numbers are allocated by IANA from a specific registry is formalized in this update to the ipn URI scheme by designating IANA as the "Default Allocator", and assigned the Allocator identifier zero (0) in the 'ipn' Scheme URI Allocator Identifiers registry (Section 9.1). In any case where an encoded ipn URI does not explicitly include an Allocator Identifier, an implementation MUST assume that the Node Number has been allocated by the Default Allocator.

A new IANA "'ipn' Scheme URI Default Allocator Node Numbers" registry is defined to control the allocation of Node Numbers values by the Default Allocator. This new registry inherits behaviours and existing assignments from the IANA "CBHE Node Numbers" registry, and reserves some other values as defined in the Special Node Numbers (Section 3.4) section below.

3.3. Node Numbers

A Node Number identifies a node that hosts a resource in the context of an Allocator. A Node Number is an unsigned integer. A single Node Number assigned by a single Allocator MUST refer to a single node.

All Node Number assignments, by all Allocators, MUST be in the range 0 to 2^32-1.

It is RECOMMENDED that Node Number zero (0) not be assigned by an Allocator to avoid confusion with the Null ipn URI (Section 3.1).

3.3.1. Fully-qualified Node Numbers

One of the advantages of ipn URis is the ability to easily split the identity of a particular service from the node upon which the service exists. For example a message received from one particular ipn URI may require a response to be sent to a different service on the same node that sent the original message. Historically the identifier of the sending node has been colloquially referred to as the "node number" or "node identifier".

To avoid future confusion, when referring to the identifier of a particular node the term "Fully-qualified Node Number" (FQNN) MUST be used to refer to the combination of the Node Number component and Allocator Identifier component of an ipn URI that uniquely identifies a particular node. In other words, an FQNN is the unique identifier of a particular node that supports services identified by ipn URIs.

In examples in this document, FQNNs are written as (Allocator Identifier, Node Number), e.g. (977000,100) is the FQNN for a node assigned Node Number 100 by an Allocator with Allocator Identifier 977000.

3.4. Special Node Numbers

Some special-case Node Numbers are defined by the Default Allocator, see 'ipn' Scheme URI Default Allocator Node Numbers registry (Section 9.2).

3.4.1. The Zero Node Number

The Default Allocator assigns the use of Node Number zero (0) solely for identifying the Null ipn URI (Section 3.1).

This means that any ipn URI with a zero (0) Allocator Identifier and a zero (0) Node Number, but a non-zero Service Number component is invalid. Such ipn URIs MUST NOT be composed, and processors of such ipn URIs MUST consider them as the Null ipn URI.

3.4.2. LocalNode ipn URIs

The Default Allocator reserves Node Number 2^32-1 (0xFFFFFFFFF) to specify resources on the local node, rather than on any specific individual node.

This means that any ipn URI with a zero (0) Allocator Identifier and a Node Number of 2^32-1 refers to a service on the local bundle node. ipn URIs of this form are termed "LocalNode ipn URIs".

3.4.3. Private Use Node Numbers

The Default Allocator provides a range of Node Numbers that are reserved for "Private Use", as defined in [RFC8126].

Any ipn URI with a zero (0) Allocator Identifier and a Node Number reserved for "Private Use" is not guaranteed to be unique beyond a single administrative domain. An administrative domain, as used here, is defined as the set of nodes that share a unique allocation of FQNNs from the "Private Use" range. They can be considered to be equivalent to "Private Address Space" IPv4 addresses, as defined in [RFC1918].

3.5. Service Numbers

A Service Number identifies a particular service operating on a node. The purpose of the Service Number is to provide well-known numeric identifiers for types of service in a network. A Service Number is an unsigned integer.

A new IANA "'ipn' Scheme URI Service Numbers" registry is defined for the registration of Service Numbers, see 'ipn' Scheme URI Service Numbers registry (Section 9.3). This registry defines standardized Service Numbers for services such as an administrative or well-known protocol service endpoints. This registry also defines ranges explicitly reserved for both experimentation and ad-hoc service identification.

4. Textual Encoding of ipn URIs

All ipn scheme URIs comply with [RFC3986], and are therefore represented by scheme identifier, and a scheme-specific part. The scheme identifier is: ipn, and the scheme-specific parts are represented as a sequence of numeric components separated with the . character. It is formally defined in Appendix A (Appendix A), and can be informally considered as:

ipn:[<allocator-identifier>.]<node-number>.<service-number>

To keep the text representation concise, the follow rules apply:

  1. All leading 0 characters MUST be omitted. A single 0 is valid.
  2. If the Allocator Identifier is zero (0), then the <allocator-identifier> and . MUST be omitted.
  3. If the Allocator Identifier is zero (0), and the Node Number is 2^32-1, i.e. the URI is an ipn LocalNode URI (Section 3.4.2), then the character ! MAY be used instead of the digits 4294967295, although both forms are valid encodings.

Examples of the textual representation of ipn URIs can be found in Appendix B (Appendix B).

5. Usage of ipn URIs with BPv7

From the earliest days of experimentation with the Bundle Protocol there has been a need to identify the source and destination of a bundle. The IRTF standardisation of the experimental BPv6 termed the logical source or destination of a bundle as an "Endpoint" identified by an "Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This definition and representation of EIDs was carried from the IRTF BPv6 specification to the IETF BPv7 specification. BPv7 additionally defined an IANA registry called the "Bundle Protocol URI Scheme Types" registry which identifies those URI schemes than might be used to represent EIDs. The ipn URI scheme is one such URI scheme.

This section identifies the behavior and interpretation of ipn URI schemes that MUST be followed when using this URI scheme to represent EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is termed an "ipn EID".

5.1. Uniqueness Constraints

An ipn EID MUST identify a singleton endpoint. The bundle processing node that is the sole member of that endpoint MUST be the node identified by the Fully-qualified Node Number (Section 3.3.1) of the node.

A single bundle processing node MAY have multiple ipn EIDs associated with it. However, every ipn EID that shares a FQNN MUST refer to the same bundle processing node.

For example, ipn:977000.100.1, ipn:977000.100.2, and ipn:977000.100.3 MUST all refer to services registered on the bundle processing node identified with FQNN (977000,100). None of these EIDs could be registered on any other bundle processing node.

5.2. The Null Endpoint

Section 3.2 of [RFC9171] defines the concept of the 'null' endpoint, which is an endpoint that has no members and which is identified by a special 'null' EID.

Within the ipn URI scheme, the 'null' EID is represented by the Null ipn URI (Section 3.1). This means that the URIs dtn:none (Section 4.2.5.1.1 of [RFC9171]) and ipn:0.0 both refer to the BPv7 'null' endpoint.

5.3. BPv7 Node ID

Section 4.2.5.2 of [RFC9171] introduces the concept of a "Node ID" that has the same format as an EID and that uniquely identifies a bundle processing node.

Any ipn EID can serve as a "Node ID" for the bundle processing node identified by its Fully-qualified Node Number (Section 3.3.1). For example, any ipn EID of the form ipn:A.B.C may be used as the Source Node ID of any bundle created by the bundle processing node identified by the FQNN (A,B).

5.4. LocalNode ipn EIDs

When a LocalNode ipn URI (Section 3.4.2) is used as a BPv7 or BPv6 EID it is termed a "LocalNode ipn EID".

Because a LocalNode ipn EID only has meaning on the local bundle node, any such EID MUST be considered 'non-routeable'. This means that any bundle using a LocalNode ipn EID as a bundle source or bundle destination MUST NOT be allowed to leave the local node. Similarly, LocalNode ipn EIDs SHOULD NOT be present in any other part of a bundle that is transmitted off of the local node. For example, a LocalNode ipn EID SHOULD NOT be used as a Bundle Protocol Security [RFC9172] security source EID for a bundle transmitted from the local bundle node, because such a source EID would have no meaning at a downstream bundle node.

5.5. Private Use Endpoints

Bundles destined for EIDs that use an ipn URI with an Fully-qualified Node Number (Section 3.3.1) that is within the "Private Use" range of the Default Allocator MUST be considered 'non-routeable'.

This means that they MUST NOT be permitted to exit a single administrative domain, see Private Use (Section 3.4.3).

5.6. Administrative Endpoints

The service type identified by a Service Number of zero (0) MUST be interpreted as the administrative endpoint of the node, as defined in Section 3.2 of [RFC9171].

Non-zero Service Numbers MUST NOT be used to identify the administrative endpoint of a bundle node in an ipn EID.

6. Encoding ipn URIs with BPv7

Section 4.2.5.1 of [RFC9171] requires that any URI scheme used to represent BPv7 EIDs MUST define how the scheme-specific part of the URI scheme is CBOR encoded. To meet this requirement, this section describes the CBOR encoding and decoding approach for ipn EIDs. The formal definition of these encodings is presented in Appendix C (Appendix C).

While there is a single, canonical, textual representation of an ipn URI, there may exist multiple encodings for that URI. For example, Section 2.1 of [RFC3986] defines a percent-encoding mechanism for a URI text string. Alternatively, Section 3.4.5.3 of [RFC8949] allows for the encoding of URIs as CBOR text strings identified with a CBOR tag value of 32.

6.1. ipn EID CBOR Encoding

Generic URI approaches to encoding ipn EIDs are unlikely to be efficient because they do not consider the underlying structure of the ipn URI scheme. Since the creation of the ipn URI scheme was motivated by the need for concise identification and rapid processing, the encoding of ipn EIDs maintains these properties.

Fundamentally, [RFC9171] ipn EIDs are represented as a sequence of identifiers. In the text syntax, the numbers are separated with the . delimiter; in CBOR, this ordered series of numbers can be represented by an array. Therefore, when encoding ipn EIDs for use with BPv7, the scheme-specific part of an ipn URI MUST be represented as a CBOR array of either two (2) or three (3) elements. Each element of the array MUST be encoded as a single CBOR unsigned integer.

The structure and mechanisms of the two-element and three-element encodings are described below, and examples of the different encodings are provided in Appendix D (Appendix D).

6.1.1. Two-Element Scheme-Specific Encoding

In the two-element scheme-specific encoding of an ipn EID, the first element of the array is an encoding of the Fully-qualified Node Number (Section 3.3.1) and the second element of the array is the ipn EID Service Number.

The FQNN encoding MUST be a 64 bit unsigned integer constructed in the following way:

  1. The least significant 32 bits MUST represent the Node Number associated with the ipn EID.
  2. The most significant 32 bits MUST represent the Allocator Identifier associated with the ipn EID.

For example the ipn EID of ipn:977000.100.1 has an FQNN of (977000,100) which would be encoded as 0xEE86800000064. The resulting two-element array [0xEE86800000064, 0x01] would be encoded in CBOR as the 11 octet value 0x821B000EE8680000006401.

The two-element scheme-specific encoding provides for backwards compatibility with the encoding provided in Section 4.2.5.1.2 of [RFC9171]. When used in this way, the encoding of the FQNN replaces the use of the "Node Number" that was specified in RFC9171. When the Node Number is allocated by the Default Allocator, then the encoding of the FQNN and the RFC9171 encoding of the "Node Number" are identical.

This encoding scheme MUST be implemented by any BPv7 bundle processing node that supports ipn URIs for the specification of BPv7 EIDs.

6.1.2. Three-Element Scheme-Specific Encoding

In the three-element scheme-specific encoding of an ipn EID, the first element of the array is the Allocator Identifier, the second element of the array is Node Number, and the third element of the array is the Service Number.

For example, the ipn EID of ipn:977000.100.1 would result in the three-element array of [977000,100,1] which would be encoded in CBOR as the 9 octet value 0x831A000EE868186401.

The three-element scheme-specific encoding allows for a more efficient representation of ipn EIDs using smaller Allocator Identifiers.

When encoding an ipn EID using the Default Allocator with this encoding scheme, the first element of the array MUST be the value zero (0). In this case using the two-element encoding will result in a more concise CBOR representation, and it is RECOMMENDED that implementations do so.

6.2. ipn EID CBOR Decoding

The presence of different scheme-specific encodings does not introduce any decoding ambiguity.

An ipn EID CBOR decoder can reconstruct an ipn EID using the following logic. In this description, the term enc_eid refers to the CBOR encoded ipn EID, and the term ipn_eid refers to the decoded ipn EID.

if enc_eid.len() == 3
{
  ipn_eid.allocator_identifier := enc_eid[0];
  ipn_eid.node_number := enc_eid[1];
  ipn_eid.service_number := enc_eid[2];
}
else if enc_eid.len() == 2
{
  let N := enc_eid[0];
  ipn_eid.service_number := enc_eid[1];

  if N >= 2^32
  {
    ipn_eid.allocator_identifier := N >> 32;
    ipn_eid.node_number := N & (2^32-1);
  }
  else
  {
    ipn_eid.allocator_identifier := 0;
    ipn_eid.node_number := N;
  }
}

6.3. ipn EID Matching

Regardless of whether the two-element or three-element scheme-specific encoding is used, ipn EID matching MUST be performed on the decoded EID information itself. Different encodings of the same ipn EID MUST be treated as equivalent when performing EID-specific functions.

For example, the ipn EID of ipn:977000.100.1 can be represented as either the two-element encoding of 0x821B000EE8680000006401 or the three-element encoding of 0x831A000EE868186401. While message integrity and other syntax-based checks may treat these values differently, any EID-based comparisons MUST treat these values the same - as representing the ipn EID ipn:977000.100.1.

7. Special Considerations

The ipn URI scheme provides a compact and hierarchical mechanism for identifying services on network nodes. There is a significant amount of utility in the ipn URI scheme approach to identification. However, implementers should take into consideration the following observations on the use of the ipn URI scheme.

7.1. Scheme Compatibility

The ipn scheme update that has been presented in this document preserves backwards compatibility with any ipn URI scheme going back to the provisional definition of the ipn scheme in the experimental Compressed Bundle Header Encoding [RFC6260] in 2011. This means that any ipn URI that was valid prior to the publication of this update remains a valid ipn URI.

Similarly, the two-element scheme-specific encoding (Section 6.1.1) is also backwards compatible with the encoding of ipn URIs provided in [RFC9171]. Any existing BPv7-compliant implementation will produce an ipn URI encoding in compliance with this specification.

The introduction of optional non-default Allocator Identifiers and a three-element scheme-specific encoding make this ipn URI scheme update not forwards compatible. Existing software MUST be updated to be able to process non-default Allocator Identifiers and three-element scheme-specific encodings. It is RECOMMENDED that BP implementations upgrade to process these new features to benefit from the scalability provided by Allocator Identifiers and the encoding efficiencies provided by the three-element encoding.

7.2. Late Binding

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

The concept of "late binding" is preserved in this ipn URI scheme. Elements of an ipn URI SHOULD NOT be regarded as carrying information relating to location, reachability, or other addressing/routing concern.

An example of incorrect behaviour would be to assume that a given Allocator assigns Node Numbers derived from link-layer addresses and to interpret the Node Number component of an ipn URI directly as a link-layer address. No matter the mechanism an Allocator uses for the assignment of Node Numbers, they remain just numbers, without additional meaning.

8. Security Considerations

This section updates the security considerations from Section 4.2.5.1.2 of [RFC9171] to account for the inclusion of Allocator Identifiers in the ipn URI scheme.

8.1. Reliability and consistency

None of the BP endpoints identified by ipn EIDs are guaranteed to be reachable at any time, and the identity of the processing entities operating on those endpoints is never guaranteed by the Bundle Protocol itself. Verification of the signature provided by the Block Integrity Block targeting the bundle's primary block, as defined by Bundle Protocol Security [RFC9172], is required for this purpose.

8.2. Malicious construction

Malicious construction of a conformant ipn URI is limited to the malicious selection of Allocator Identifiers, Node Numbers, and Service Numbers. That is, a maliciously constructed ipn EID could be used to direct a bundle to an endpoint that might be damaged by the arrival of that bundle or, alternatively, to declare a false source for a bundle and thereby cause incorrect processing at a node that receives the bundle. In both cases (and indeed in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way.

8.3. Back-end transcoding

The limited expressiveness of URIs of the ipn scheme effectively eliminates the possibility of threat due to errors in back-end transcoding.

8.4. Rare IP address formats

Not relevant, as IP addresses do not appear anywhere in conformant ipn URIs.

8.5. Sensitive information

Because ipn URIs are used only to represent the numeric identities of resources, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of ipn EIDs could be used to support traffic analysis; where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs.

8.6. Semantic attacks

The simplicity of ipn URI scheme syntax minimizes the possibility of misinterpretation of a URI by a human user.

9. IANA Considerations

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

9.1. 'ipn' Scheme URI Allocator Identifiers registry

IANA is requested to create a new registry entitled "'ipn' Scheme URI Allocator Identifiers". The registration policy for this registry is:

Table 2: 'ipn' Scheme URI Numbering Allocator Identifiers registration policies
Range Registration Policy
0 .. 2^16-1 Expert Review, Single Allocator Identifiers only
2^16 .. 2^30-1 Expert Review
2^30 .. 2^31-1 Experimentation
2^31 .. 2^32-1 Reserved, Future Expansion
>= 2^32 Reserved

Each entry in this registry associates one or more Allocator Identifiers with a single organization. Within the registry, the organization is identified using the "Name" and "Point of Contact" fields. It is expected that each identified organization publishes some listing of allocated node numbers - the pointer to which is listed in the "Reference" field of the registry.

The initial values for the registry are:

Table 3: 'ipn' Scheme URI Allocator Identifiers initial values
Organization Range (dec) Range (hex) Range Length (Bits) Reference Point of Contact
Default Allocator 0 0x0 0 This document IANA
CCSDS 1 0x1 0 TBD www.sana.org
Example Range 974848 .. 978943 0xEE000 .. 0xEEFFF 12 bits This document IANA

The "Example Range" is assigned for use in examples in documentation.

9.1.1. Guidance for Designated Experts

New assignments within this registry require review by a Designated Expert (DE). This section provides guidance to the DE when performing their reviews. Specifically, a DE is expected to perform the following activities.

  1. Avoid overloading: Determine that the requesting organization will reasonably provide operational Node Numbers for itself or others beyond that which is already provided by the Default Allocator.
  2. Avoid duplication: Ensure that the requesting organization does not already provide the same Node Numbers under the auspices of some other registered Allocator (except in the cases of allocating a range of Allocator Identifiers).
9.1.1.1. Note to be removed prior to publication

The working group is satisfied with the technical specification in this document, but there are reservations amongst the WG around the governance of the assignment of Allocator Identifiers, and is engaging with the IESG/IANA to ensure best practice is followed. The intent is to use mechanism similar to those in place for IP addresses (RFC1881, RFC3513, RFC1466,…), AS numbers and domains (RFC1591).

9.2. 'ipn' Scheme URI Default Allocator Node Numbers registry

IANA is requested to rename the "CBHE Node Numbers" registry defined in Section 3.2.1 of [RFC7116] to the "'ipn' Scheme URI Default Allocator Node Numbers" registry.

The registration policy for this registry is updated to be:

Table 4: 'ipn' Scheme URI Default Allocator Node Numbers registration policies
Range Registration Policy
0 Reserved for the Null ipn URI (Section 3.1)
1 .. 2^14-1 Private Use
2^14 .. 2^32-2 Expert Review
2^32-1 Reserved for LocalNode ipn URIs (Section 3.4.2)
>= 2^32 Invalid

The initial values for the registry remain as is, namely:

Table 5: 'ipn' Scheme URI Default Allocator Node Numbers initial values
Value (dec) Value (hex) Description Reference
16384 .. 2097151 0x4000 .. 0x1FFFFF Allocated to the Space Assigned Numbers Authority (SANA) for use by Consultative Committee for Space Data Systems (CCSDS) missions. Inherited from [RFC7116]
268435456 .. 268451839 0x10000000 .. 0x10003FFF Allocated to Spacely Packets, LLC to provide IPN/IP Gateway services to private sector stakeholders. Scott Johnson
268451840 .. 268468223 0x10004000 .. 0x10007FFF Allocated to SPATIAM CORPORATION to provide DTN services to organizations. Alberto Montilla
268468224 .. 268484607 0x10008000 .. 0x1000BFFF Allocated to Phoenix R&D GMBH to provide DTN services for secure messaging. Julia Longtin
268484608 .. 268500991 0x1000C000 .. 0x1000FFFF Allocated to LateLab AB for various terrestrial DTN deployments and services. Samo Grasic
268500992 .. 268517375 0x10010000 .. 0x10013FFF Allocated to MEIS d.o.o. from Slovenia for various terrestrial DTN testbeds. Bostjan Grasic
268517376 .. 268533759 0x10014000 .. 0x10017FFF Allocated to Digital Health Information Network Inc. for Space applications in digital health and terrestrial DTN services. Oscar Garcia
268533760 .. 268550143 0x10018000 .. 0x1001BFFF Allocated to Shirokuma-AI for artificial intelligence-driven space applications and terrestrial DTN services in the fields of healthcare, robotics, wearables and edge devices, information processing and discovery. Larissa Suzuki
268550144-268566527 0x1001C000-0x1001FFFF Assigned to LJCV Electronics for Development of an Experimental R&D DTN, STEM Education, space and terrestrial applications. Jorge Amodio

9.3. 'ipn' Scheme URI Service Numbers registry

IANA is requested to rename the "CBHE Service Numbers" registry defined in Section 3.2.2 of [RFC7116] to the "'ipn' Scheme URI Service Numbers" registry.

The registration policy for this registry is updated to be:

Table 6: 'ipn' Scheme URI Service Numbers registration policies
Range Registration Policy
0 .. 23 RFC Required
24 .. 2^15-1 Specification Required
2^15 .. 2^31-1 Private Use
>= 2^31 Reserved

The current values for the registry remain, and are rewritten as:

Table 7: 'ipn' Scheme URI Service Numbers initial values
Value Version Description Reference
0 BPv6, BPv7 The Administrative Endpoint [RFC7116], This document
1 BPv6 CCSDS File Delivery Service [CFDP]
1 BPv7 Unassigned  
2 BPv6 Reserved [RFC7116]
2 BPv7 Unassigned  
3 .. 63 BPv6, BPv7 Unassigned  
64 .. 1023 BPv6 Allocated to the Space Assigned Numbers Authority (SANA) for use by Consultative Committee for Space Data Systems (CCSDS) missions [RFC7116]
64 .. 1023 BPv7 Unassigned  

10. References

10.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>.
[RFC5050]
Scott, K. and S. Burleigh, "Bundle Protocol Specification", RFC 5050, DOI 10.17487/RFC5050, , <https://www.rfc-editor.org/rfc/rfc5050>.
[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>.
[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>.
[RFC8126]
Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, , <https://www.rfc-editor.org/rfc/rfc8126>.
[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>.

10.2. Informative References

[CFDP]
The Consultative Committee for Space Data Systems, "CCSDS FILE DELIVERY PROTOCOL (CFDP)", , <https://public.ccsds.org/Pubs/727x0b4s.pdf>.
[RFC1918]
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, , <https://www.rfc-editor.org/rfc/rfc1918>.
[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>.
[RFC4632]
Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, , <https://www.rfc-editor.org/rfc/rfc4632>.
[RFC6260]
Burleigh, S., "Compressed Bundle Header Encoding (CBHE)", RFC 6260, DOI 10.17487/RFC6260, , <https://www.rfc-editor.org/rfc/rfc6260>.
[RFC9172]
Birrane, E., III., and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, , <https://www.rfc-editor.org/rfc/rfc9172>.

Appendix A. ipn URI Scheme Text Syntax

The text syntax of an ipn 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 = fqnn "." service-number

fqnn = "!" / allocator-part

allocator-part = (allocator-identifier ".")? node-number

allocator-identifier = non-zero-number

node-number = number

service-number = number

number = "0" \ non-zero-number

non-zero-number = (%x31-39 *DIGIT)

Appendix B. ipn URI Scheme Text Representation Examples

This section provides some example ipn URIs in their textual representation.

B.1. Using the Default Allocator

Consider the ipn URI identifying Service Number 2 on Node Number 1 allocated by the Default Allocator (0).

The complete seven character representation of this URI would be as follows:

ipn:1.2

B.2. Using a non-default Allocator

Consider the ipn URI identifying Service Number 1 on Node Number 1 allocated by Allocator 977000.

The complete 14 character representation of this URI would be as follows:

ipn:977000.1.2

B.3. The Null ipn URI

The Null ipn URI (Section 3.1) is represented as:

ipn:0.0

B.4. A LocalNode ipn URI

Consider the ipn URI identifying Service Number 7 on the local node.

The complete seven character representation of this URI would be as follows:

ipn:!.7

Appendix C. ipn URI Scheme CBOR Encoding

A BPv7 endpoint identified by an ipn 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: ipn-ssp2 / ipn-ssp3
]
ipn-ssp2 = [
  fqnn: uint,  ; packed value
  service-number: uint
]
ipn-ssp3 = [
  authority-number: uint .lt 4294967296,
  node-number: uint .lt 4294967296,
  service-number: uint
]

Note: The node-number component will be the numeric representation of the concatenation of the Allocator Identifier and Node Number when the 2-element encoding scheme has been used.

Appendix D. ipn URI Scheme CBOR Encoding Examples

This section provides some example CBOR encodings of ipn EIDs.

D.1. Using the Default Allocator

Consider the ipn EID ipn:1.1. This textual representation of an ipn EID identifies Service Number 1 on Node Number 1 allocated by the Default Allocator (0).

The complete five octet encoding of this EID using the two-element scheme-specific encoding would be as follows:

82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 (IPN URI scheme)
   82    # 2 Element ipn EID scheme-specific encoding
      01 # Node Number
      01 # Service Number

The complete six octet encoding of this EID using the three-element scheme-specific encoding would be as follows:

82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 (IPN URI scheme)
   83    # 3 Element ipn EID scheme-specific encoding
      00 # Default Allocator
      01 # Node Number
      01 # Service Number

D.2. Using a non-default Allocator

Consider the ipn EID ipn:977000.1.1. This textual representation of an ipn EID identifies Service Number 1 on Node Number 1 allocated by Allocator 977000.

The complete thirteen octet encoding of this EID using the two-element scheme-specific encoding would be as follows:

82                        # 2-Element Endpoint Encoding
   02                     # uri-code: 2 (IPN URI scheme)
   82                     # 2 Element ipn EID scheme-specific encoding
      1B 000EE86800000001 # Fully-qualified Node Number
      01                  # Service Number

The complete ten octet encoding of this EID using the three-element scheme-specific encoding would be as follows:

82                # 2-Element Endpoint Encoding
   02             # uri-code: 2 (IPN URI scheme)
   83             # 3 Element ipn EID scheme-specific encoding
      1A 000EE868 # Allocator Identifier
      01          # Node Number
      01          # Service Number

D.3. The 'null' Endpoint

The 'null' EID of ipn:0.0 can be encoded in the following ways:

The complete five octet encoding of the 'null' ipn EID using the two-element scheme-specific encoding would be as follows:

82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 (IPN URI scheme)
   82    # 2 Element ipn EID scheme-specific encoding
      00 # Node Number
      00 # Service Number

The complete six octet encoding of the 'null'' ipn EID using the three-element scheme-specific encoding would be as follows:

82       # 2-Element Endpoint Encoding
   02    # uri-code: 2 (IPN URI scheme)
   83    # 3 Element ipn EID scheme-specific encoding
      00 # Default Allocator
      00 # Node Number
      00 # Service Number

Acknowledgments

The following DTNWG participants contributed technical material, use cases, and critical technical review for this URI scheme update: Scott Burleigh of the IPNGROUP, Keith Scott, Brian Sipos of the Johns Hopkins University Applied Physics Laboratory, and Jorge Amodio of LJCV Electronics.

Additionally, the authors wish to thank members of the CCSDS SIS-DTN working group at large who provided useful review and commentary on this document and its implications for the future of networked space exploration.

Authors' Addresses

Rick Taylor
Ori Industries
Ed Birrane
JHU/APL