Updates to the 'ipn' URI Scheme Aalyria Technologies
rtaylor@aalyria.com
The Johns Hopkins University Applied Physics Laboratory
Edward.Birrane@jhuapl.edu
INT dtn DTN ipn BPv7 CBHE Bundle Protocol This document updates the specification of the 'ipn' URI scheme previously defined in RFC 6260 and the IANA registries established in RFC 7116. It also updates the rules for the encoding and decoding of these URIs when used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv7) as defined in RFC 9171. These updates clarify the structure and behavior of the 'ipn' URI scheme, define new encodings of 'ipn' scheme URIs, and establish the registries necessary to manage this scheme.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
Table of Contents
  • .  Introduction
  • .  Conventions and Definitions
  • .  Core Concepts
    • .  The Null ipn URI
    • .  Allocator Identifiers
      • .  Allocator Identifier Ranges
      • .  The Default Allocator
    • .  Node Numbers
      • .  Fully Qualified Node Numbers
    • .  Special Node Numbers
      • .  The Zero Node Number
      • .  LocalNode ipn URIs
      • .  Private Use Node Numbers
    • .  Service Numbers
  • .  Textual Representation of ipn URIs
    • .  'ipn' URI Scheme Text Syntax
  • .  Usage of ipn URIs with BPv7
    • .  Uniqueness Constraints
    • .  The Null Endpoint
    • .  BPv7 Node ID
    • .  LocalNode ipn EIDs
    • .  Private Use ipn EIDs
    • .  Well-Known Service Numbers
    • .  Administrative Endpoints
  • .  CBOR Representation of ipn URIs with BPv7
    • .  ipn EID CBOR Encoding
      • .  Two-Element Scheme-Specific Encoding
      • .  Three-Element Scheme-Specific Encoding
    • .  ipn EID CBOR Decoding
    • .  'ipn' URI Scheme CBOR Syntax
    • .  ipn EID Matching
  • .  Special Considerations
    • .  Scheme Compatibility
    • .  CBOR Representation Interoperability
    • .  Text Representation Compatibility
    • .  Bundle Protocol Version 6 Compatibility
    • .  Late Binding
  • .  Security Considerations
    • .  Reliability and Consistency
    • .  Malicious Construction
    • .  Back-End Transcoding
    • .  Local and Private Use ipn EIDs
    • .  Sensitive Information
    • .  Semantic Attacks
  • .  IANA Considerations
    • .  'ipn' Scheme URI Allocator Identifiers Registry
      • .  Guidance for Designated Experts
    • .  'ipn' Scheme URI Default Allocator Node Numbers Registry
    • .  'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry
      • .  Guidance for Designated Experts
  • . References
    • .  Normative References
    • .  Informative References
  • .  'ipn' URI Scheme Text Representation Examples
    • .  Using the Default Allocator
    • .  Using a Non-Default Allocator
    • .  The Null ipn URI
    • .  The LocalNode ipn URI
  • .  'ipn' URI Scheme CBOR Encoding Examples
    • .  Using the Default Allocator
    • .  Using a Non-Default Allocator
    • .  The Null Endpoint
  • Acknowledgments
  • Authors' Addresses
Introduction The 'ipn' URI scheme was originally defined in and 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) , 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 benefits of integer identifiers make 'ipn' scheme URIs useful for any network 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) 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 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. By updating and , this document updates the specification of the 'ipn' URI scheme in a backwards-compatible way, in order to provide needed improvements both in the scheme itself and in 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 with this scheme.
Although originally developed by the deep-space community for use with the 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 it does not include any topological information describing how to route messages to that resource.
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 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' URI scheme.
Core Concepts Every ipn URI, no matter whether it is expressed with a textual representation or a binary encoding, MUST be considered as a tuple of the following three components:
  • The Allocator Identifier
  • The Node Number
  • The Service Number
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 . The Node Number is a shared identifier assigned to all ipn URIs for resources co-located on a single node. See . The Service Number is an identifier to distinguish between resources on a given node. See . 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 .
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 (the Allocator Identifier, Node Number, and Service Number) set to the value zero (0). No resource identified by the Null ipn URI exists, and any destination identified by such a resource is therefore by definition unreachable.
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: unique, unsigned integers in the range 0 to 232-1. 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 registry, "'ipn' Scheme URI Allocator Identifiers", is defined for the registration of Allocator Identifiers; see . Although the uniqueness of Allocator Identifiers is required to enforce the 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 . 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 Numbers range (), reserved by the Default Allocator () for this purpose, is to be used.
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. This allows an external observer to detect that a group of Allocator Identifiers is 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 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 (CIDR) assignment of Internet addresses described in . In that assignment scheme, an organization (such as an Internet Service Provider (ISP)) 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 size S that is a power of 2, and for a given range of length N bits, with S = 2N, 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: 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. Organization D has a single Allocator Identifier, and hence a range of bit-length 0.
The Default Allocator As of the publication of , the only organization permitted to assign Node Numbers was the Internet Assigned Numbers Authority (IANA), which assigned Node Numbers via the "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 "CBHE Node Numbers" registry. The presumption that Node Numbers are allocated by IANA from a specific registry, unless otherwise specified, is formalized in this update to the 'ipn' URI scheme by designating IANA as the Default Allocator and by assigning the Allocator Identifier zero (0) in the "'ipn' Scheme URI Allocator Identifiers" registry () to the Default Allocator. 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 registry, "'ipn' Scheme URI Default Allocator Node Numbers", is defined to control the allocation of Node Number values by the Default Allocator. This new registry inherits behaviors and existing assignments from the "CBHE Node Numbers" registry, and it reserves some other values as defined in below.
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 232-1. It is RECOMMENDED that Node Number zero (0) not be assigned by an Allocator to avoid confusion with the Null ipn URI ().
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 the examples in this document, FQNNs are written as (Allocator Identifier, Node Number). For example, (977000,100) is the FQNN for a node assigned Node Number 100 by an Allocator with Allocator Identifier 977000.
Special Node Numbers Some special-case Node Numbers are defined by the Default Allocator; see .
The Zero Node Number The Default Allocator assigns the use of Node Number zero (0) solely for identifying the Null ipn URI (). 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.
LocalNode ipn URIs The Default Allocator reserves Node Number 232-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 232-1 refers to a service on the local bundle node. This form of ipn URI is termed a "LocalNode ipn URI".
Private Use Node Numbers The Default Allocator provides a range of Node Numbers that are reserved for Private Use, as defined in . 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. These FQNNs can be considered to be functionally similar to private address space IPv4 addresses, as defined in . Because of this lack of uniqueness, any implementation of a protocol using ipn URIs that resides on the border between administrative domains MUST have suitable mechanisms in place to prevent protocol units using such Private Use Node Numbers to cross between different administrative domains.
Service Numbers A Service Number is an unsigned integer that identifies a particular service operating on a node. A service in this case is some logical function that requires its own resource identifier to distinguish it from other functions operating on the same node.
Textual Representation of ipn URIs All 'ipn' scheme URIs comply with and are therefore represented by a 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. A formal definition is provided below (see ) and can be informally considered as: ipn:[<allocator-identifier>.]<node-number>.<service-number> To keep the text representation concise, the following 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 '.' MAY be omitted.
  3. If the Allocator Identifier is zero (0), and the Node Number is 232-1 (i.e., the URI is a LocalNode ipn URI ()), then the character '!' SHOULD 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 .
'ipn' URI Scheme Text Syntax The text syntax of an ipn URI MUST comply with the following ABNF syntax from and repeats 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 = number node-number = number service-number = number number = "0" / non-zero-number non-zero-number = (%x31-39 *DIGIT) DIGIT = %x30-39
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 BPv6 experimental specification 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 forward from the IRTF BPv6 specification to the IETF BPv7 specification . additionally defined an IANA registry called the "Bundle Protocol URI Scheme Types" registry, which identifies those URI schemes that might be used to represent EIDs. The 'ipn' URI scheme is one such URI scheme. This section identifies the behavior and interpretation of 'ipn' scheme URIs 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".
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 FQNN () of the node. A single bundle processing node MAY have multiple ipn EIDs associated with it. However, all ipn EIDs that share any single 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.
The Null Endpoint defines the concept of the Null endpoint, which is an endpoint that has no members and is identified by a special Null EID. Within the 'ipn' URI scheme, the Null EID is represented by the Null ipn URI (). This means that the URIs dtn:none (), ipn:0.0, and ipn:0.0.0 all refer to the BPv7 Null endpoint.
BPv7 Node ID introduces the concept of a "Node ID" that has the same format as an EID and uniquely identifies a bundle processing node. Any ipn EID can serve as a "Node ID" for the bundle processing node identified by its FQNN (). That is, 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).
LocalNode ipn EIDs When a LocalNode ipn URI () is used as a BPv6 or BPv7 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-routable. 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. Equally, all externally received bundles featuring LocalNode EIDs as a bundle source or bundle destination MUST be discarded as invalid. LocalNode ipn EIDs MUST NOT be present in any other part of a bundle that is transmitted off of the local node. For example, a LocalNode ipn EID MUST NOT be used as a Bundle Protocol Security (BPSec) security source for a bundle transmitted from the local bundle node, because such a source EID would have no meaning at a downstream bundle node. LocalNode ipn EIDs MUST NOT be published in any node identification directory (such as a DNS registration) or presented as part of dynamic peer discovery, as the EID has no valid meaning for other nodes. For example, a LocalNode ipn EID MUST NOT be advertised as the peer Node ID during session negotiation in .
Private Use ipn EIDs Bundles destined for EIDs that use an ipn URI with an FQNN () that is within the Private Use range of the Default Allocator () are not universally unique; therefore, they are only valid within the scope of the current administrative domain. This means that any bundle using a Private Use ipn EID as a bundle source or bundle destination MUST NOT be allowed to cross administrative domains. All implementations that could be deployed as a gateway between administrative domains MUST be sufficiently configurable to ensure that this is enforced, and operators MUST ensure correct configuration. Private Use ipn EIDs MUST NOT be present in any other part of a bundle that is destined for another administrative domain when the lack of uniqueness prevents correct operation. For example, a Private Use ipn EID MUST NOT be used as a BPSec security source for a bundle when the bundle is destined for a different administrative domain.
Well-Known Service Numbers It is convenient for BPv7 services that have a public specification and wide adoption to be identified by a pre-agreed default Service Number, so that unless overridden by explicit configuration, such services can be sensibly assumed to be operating on the well-known Service Number on a particular node. If a different service uses the number, or the service uses a different number, BPv7 will continue to operate, but some configuration may be required to make the individual service operational. A new IANA registry, "'ipn' Scheme URI Well-Known Service Numbers for BPv7", is defined for the registration of well-known BPv7 Service Numbers; see . This registry records the assignments of Service Numbers for well-known services and also explicitly reserves ranges for both experimentation and Private Use.
Administrative Endpoints The service identified by a Service Number of zero (0) MUST be interpreted as the Administrative Endpoint of the node, as defined in . Non-zero Service Numbers MUST NOT be used to identify the Administrative Endpoint of a bundle node in an ipn EID.
CBOR Representation of ipn URIs with BPv7 requires that any URI scheme used to represent BPv7 EIDs MUST define how the scheme-specific part of the URI scheme is encoded with Concise Binary Object Representation (CBOR) . To meet this requirement, this section describes the CBOR encoding and decoding approach for ipn EIDs. The formal definition of the CBOR representation is specified; see .
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, ipn EIDs from 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 .
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 FQNN (), 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 0xEE868_00000064. The resulting two-element array [0xEE868_00000064, 0x01] would be encoded in CBOR as the following 11-octet sequence: 82 # 2-Element Endpoint Encoding 02 # uri-code: 2 ('ipn' URI scheme) 82 # 2-Element ipn EID encoding 1B 000EE86800000064 # Fully Qualified Node Number 01 # Service Number The two-element scheme-specific encoding provides backwards compatibility with the encoding provided in . When used in this way, the encoding of the FQNN replaces the use of the Node Number that was specified in . When the Node Number is allocated by the Default Allocator (), the encoding of the FQNN and the encoding of the Node Number from are identical.
Three-Element Scheme-Specific Encoding In the three-element scheme-specific encoding of an ipn EID:
  1. the first element of the array is the Allocator Identifier,
  2. the second element of the array is the Node Number, and
  3. 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 following 9-octet sequence: 82 # 2-Element Endpoint Encoding 02 # uri-code: 2 ('ipn' URI scheme) 83 # 3-Element ipn EID encoding 1A 000EE868 # Allocator Identifier 64 # Node Number 01 # Service Number The three-element scheme-specific encoding allows for a more efficient representation of ipn EIDs using smaller Allocator Identifiers, and implementations are RECOMMENDED to use this encoding scheme unless explicitly mitigating for interoperability issues; see . When encoding an ipn EID using the Default Allocator () with this encoding scheme, the first element of the array is the value zero (0). In this case, using the equivalent two-element scheme-specific encoding () will result in a more concise CBOR representation; therefore, it is RECOMMENDED that implementations use that encoding instead.
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 { ipn_eid.allocator_identifier := enc_eid[0] >> 32; ipn_eid.node_number := enc_eid[0] & (2^(32-1)); ipn_eid.service_number := enc_eid[1]; }
'ipn' URI Scheme CBOR Syntax When encoded in CBOR , a BPv7 endpoint identified by an ipn URI MUST comply with the following Concise Data Definition Language (CDDL) specification: eid = $eid .within eid-structure eid-structure = [ uri-code: uint, SSP: any ] ; ... Syntax for other uri-code values defined in RFC 9171 ... $eid /= [ uri-code: 2, SSP: ipn-ssp2 / ipn-ssp3 ] ipn-ssp2 = [ fqnn: uint, ; packed value service-number: uint ] ipn-ssp3 = [ allocator-identifier: 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 two-element encoding scheme has been used.
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.
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, particularly in regard to interoperability with implementations that pre-date this specification.
Scheme Compatibility The 'ipn' URI 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 specification "Compressed Bundle Header Encoding (CBHE)" 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 () is also backwards compatible with the encoding of ipn URIs provided in . Any existing implementation compliant with 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 does not make this ipn URI scheme update forwards compatible. Existing implementations for which support of this update is desired MUST be updated to be able to process non-default Allocator Identifiers and three-element scheme-specific encodings. It is RECOMMENDED that BPv7 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.
CBOR Representation Interoperability Care must be taken when deploying implementations that default to using the three-element encoding in networks that include implementations that only support the two-element encoding . Because the existing implementations will reject bundles that use the three-element encoding as malformed, correct forwarding of semantically valid bundles will fail. The used mitigation for this issue depends on the nature of the interoperability required by the deployment. Techniques can include:
  • A configuration option indicating when an implementation must use the two-element encoding for all ipn EIDs when processing bundles destined to a given endpoint. This would be suitable when adding a newer implementation to a network of existing implementations.
  • Selective bundle encapsulation, whereby bundles that are known to originate from implementations that do not support the three-element encoding are tunneled across regions of the network that require the three-element encoding. This would utilize specially configured "gateway nodes" to perform the tunnel encapsulation and decapsulation and would be suitable when joining an existing network to a larger network.
Techniques that do not mitigate the problem include:
  • Heuristic determination of the correct encoding to use when responding to a bundle by examining the incoming bundle. It is not possible to determine whether the two-element encoding is required by the destination when composing a new bundle in response to the receipt of a bundle, such as a status report, because ipn EIDs assigned by the Default Allocator use the two-element encoding, whether or not the implementation supports the three-element encoding.
  • Transcoding bundles at intermediate nodes. requires the bundle primary block to be immutable, and even if ipn EIDs in the primary block do not require rewriting, other blocks including the payload block may include ipn EIDs of which the transcoding node is unaware. Additionally, bundle blocks may be covered by bundle security blocks or bundle integrity blocks , making them immutable.
Text Representation Compatibility The textual representation of ipn URIs is not forwards compatible with . Therefore, care must be taken when deploying implementations or tooling that use the textural representation of ipn URIs and support for non-default Allocator Identifiers is required. For example, specifies that the session initialization message "...SHALL contain the UTF-8 encoded node ID of the entity that sent the SESS_INIT message." In such cases, the considerations that apply to the use of the three-element CBOR encoding also apply to the text representation when a non-default Allocator Identifier is present.
Bundle Protocol Version 6 Compatibility This document updates the use of ipn EIDs for BPv7; however, the 'ipn' URI scheme was originally defined for use with BPv6. This document does not update any of the behaviors, wire-formats, or mechanisms of BPv6. Therefore, ipn EIDs with non-default Allocator Identifiers MUST NOT be used with BPv6, and the Allocator Identifier prefix MUST be omitted from any textural representation. It should be noted that BPv6 has no concept of LocalNode EIDs and will therefore treat such EIDs as routable.
Late Binding mandates the concept of the "late binding" of an EID, whereby the address of the destination of a bundle is resolved from its identifier hop-by-hop as it transits a BPv7 network. 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 MUST NOT be regarded as carrying information relating to location, reachability, or other addressing/routing concerns. An example of incorrect behavior 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.
Security Considerations This section updates the security considerations from to account for the inclusion of Allocator Identifiers in the 'ipn' URI scheme when used with BPv7.
Reliability and Consistency None of the BPv7 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 (BIB) targeting the bundle's primary block, as defined by "Bundle Protocol Security (BPSec)" , is required for this purpose.
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, such as with the use of BPSec and TCP Convergence Layer version 4 (TCPCLv4) with TLS .
Back-End Transcoding The limited expressiveness of URIs of the 'ipn' scheme effectively eliminates the possibility of threats due to errors in back-end transcoding.
Local and Private Use ipn EIDs Both LocalNode () and Private Use () ipn URIs present a risk to the stability of deployed BPv7 networks. If either type of ipn URI is allowed to propagate beyond the domain in which they are valid, then the required uniqueness of ipn URIs no longer holds, and this fact can be abused by a malicious node to prevent the correct functioning of the network as a whole. See Sections and for required behaviors to mitigate against this form of abuse.
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 URIs 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, such as TCPCLv4 .
Semantic Attacks The simplicity of the 'ipn' URI scheme syntax minimizes the possibility of misinterpretation of a URI by a human user.
IANA Considerations The following sections detail the creation of two new IANA registries and the renaming of an existing IANA registry under the "Uniform Resource Identifier (URI) Schemes" registry group. IANA has also updated the reference for the 'ipn' scheme to this document in the "Uniform Resource Identifier (URI) Schemes" registry.
'ipn' Scheme URI Allocator Identifiers Registry IANA has created a new registry titled "'ipn' Scheme URI Allocator Identifiers". Using terms defined in , the registration procedures for this registry are: Registration Procedures for the 'ipn' Scheme URI Allocator Identifiers Registry
Range Registration Procedures Note
0..0xFFFF Expert Review Single Allocator Identifiers only
0x10000..0x3FFFFFFF Expert Review
0x40000000..0x7FFFFFFF Experimental Use
0x80000000..0xFFFFFFFF Reserved Future Expansion
>=0x100000000 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 "Change Controller" fields. It is expected that each identified organization will publish some listing of allocated Node Numbers, the pointer to which is listed in the "Reference" field of the registry. Note that the "Single Allocator Identifiers only" language in the registration procedure for this registry indicates that, within the indicated range, the allocation of a sequence of consecutive Allocator Identifiers to a single organization is prohibited. The initial values in the registry are: Initial Values in the 'ipn' Scheme URI Allocator Identifiers Registry
Name Range (dec) Range (hex) Range Length (Bits) Reference Change Controller
Default Allocator 0 0x0 0 RFC 9758, IETF
Example Range 974848-978943 0xEE000-0xEEFFF 12 bits RFC 9758 IETF
The "Example Range" is assigned for use in examples in documentation and sample code.
Guidance for Designated Experts Due to the nature of the CBOR encoding of unsigned integers used for Allocator Identifiers with BPv7, Allocator Identifiers with a low value number are encoded more efficiently than larger numbers. This makes low value Allocator Identifiers more desirable than larger Allocator Identifiers; therefore, care must be taken when assigning Allocator Identifier ranges to ensure that a single applicant is not granted a large swathe of highly desirable numbers at the expense of other applicants. To this end, designated experts are strongly recommended to familiarize themselves with the CBOR encoding of unsigned integers in .
'ipn' Scheme URI Default Allocator Node Numbers Registry IANA has renamed the "CBHE Node Numbers" registry (defined in ) to the "'ipn' Scheme URI Default Allocator Node Numbers" registry and moved it to the "Uniform Resource Identifier (URI) Schemes" registry group. IANA has added the following note to the "CBHE Node Numbers" registry:
Note: Renamed "CBHE Node Numbers" as "'ipn' Scheme URI Default Allocator Node Numbers" and moved it to <> per RFC 9758.
Using terms defined in , the registration procedures for this registry are: Registration Procedures for the 'ipn' Scheme URI Default Allocator Node Numbers Registry
Range Registration Procedures
1..0x3FFF Private Use
0x4000..0xFFFFFFFE Expert Review
>=0x100000000 Invalid
IANA has registered the following values in the "'ipn' Scheme URI Default Allocator Node Numbers" registry: New Values in the 'ipn' Scheme URI Default Allocator Node Numbers Registry
Value Description Reference
0 Reserved for the Null ipn URI and RFC 9758,
4294967295 Reserved for LocalNode ipn URIs RFC 9758,
As IANA has only renamed the registry, all existing registrations will remain.
'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry IANA has created a new registry titled "'ipn' Scheme URI Well-Known Service Numbers for BPv7". Using terms defined in , the registration procedures for this registry are: Registration Procedures for the 'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry
Range Registration Procedures
1..127 Private Use
128..255 Standards Action
0x0100..0x7FFF Private Use
0x8000..0xFFFF Specification Required
0x10000..0xFFFFFFFF Private Use
>=0x100000000 Reserved for future expansion
The initial values in the registry are: Initial Values in the 'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry
Value Description Reference
0 The Administrative Endpoint and RFC 9758,
0xEEE0..0xEEEF Example Range RFC 9758
The "Example Range" is assigned for use in examples in documentation and sample code.
Guidance for Designated Experts This registry is intended to record the default Service Numbers for well-known, interoperable services that are available and of use to the entire BPv7 community; hence, all ranges not marked for Private Use MUST have a corresponding publicly available specification describing how one interfaces with the service. Services that are specific to a particular deployment or co-operation may require a registry to reduce administrative burden, but do not require an entry in this registry.
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Augmented BNF for Syntax Specifications: ABNF Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] Compressed Bundle Header Encoding (CBHE) This document describes a convention by which Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence-layer" adapters may represent endpoint identifiers in a compressed form within the primary blocks of bundles, provided those endpoint identifiers conform to the structure prescribed by this convention. Compressed Bundle Header Encoding (CBHE) compression is a convergence-layer adaptation. It is opaque to bundle processing. Therefore, it has no impact on the interoperability of different Bundle Protocol implementations, but instead affects only the interoperability of different convergence-layer adaptation implementations. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community. Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries The DTNRG Research Group has defined the experimental Licklider Transmission Protocol (LTP) and the Compressed Bundle Header Encoding (CBHE) mechanism for the InterPlanetary Network ('ipn' URI scheme). Moreover, RFC 5050 defines values for the Bundle Protocol administrative record type. All of these fields are subject to a registry. For the purpose of its research work, the group has created ad hoc registries. As the specifications are stable and have multiple interoperable implementations, the group would like to hand off the registries to IANA for official management. This document describes the necessary IANA actions. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. Concise Binary Object Representation (CBOR) The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Bundle Protocol Version 7 This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. Informative References Address Allocation for Private Internets This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Uniform Resource Identifier (URI): Generic Syntax A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Bundle Protocol Specification This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community. Bundle Protocol Security (BPSec) This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP). Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4 This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms.
'ipn' URI Scheme Text Representation Examples This section provides some example ipn URIs in their textual representation.
Using the Default Allocator Consider the ipn URI identifying Service Number 2 on Node Number 1 allocated by the Default Allocator (0) (). The recommended seven-character representation of this URI would be as follows: ipn:1.2 The nine-character representation of this URI, with the explicit Allocator Identifier, would be as follows: ipn:0.1.2
Using a Non-Default Allocator Consider the ipn URI identifying Service Number 3 on Node Number 1 allocated by Allocator 977000. The 14-character representation of this URI would be as follows: ipn:977000.1.3
The Null ipn URI The Null ipn URI () is represented as: ipn:0.0
The LocalNode ipn URI Consider the ipn URI identifying Service Number 7 on the local node. The recommended seven-character representation of this URI would be as follows: ipn:!.7 The numeric 16-character representation of this URI would be as follows: ipn:4294967295.7
'ipn' URI Scheme CBOR Encoding Examples This section provides some example CBOR encodings of ipn EIDs.
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 recommended 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 encoding 01 # Node Number 01 # Service Number The 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 encoding 00 # Default Allocator 01 # Node Number 01 # Service Number
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 recommended 10-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 encoding 1A 000EE868 # Allocator Identifier 01 # Node Number 01 # Service Number The 13-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 encoding 1B 000EE86800000001 # Fully Qualified Node Number 01 # Service Number
The Null Endpoint The Null EID of ipn:0.0 can be encoded in the following ways: The recommended 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 encoding 00 # Node Number 00 # Service Number The 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 encoding 00 # Default Allocator 00 # Node Number 00 # Service Number
Acknowledgments The following DTN Working Group participants contributed technical material, use cases, and critical technical reviews for this URI scheme update: of the IPNGROUP, , of the Johns Hopkins University Applied Physics Laboratory, of LJCV Electronics, and . Additionally, the authors wish to thank members of the CCSDS SIS-DTN Working Group at large who provided useful reviews and commentary on this document and its implications for the future of networked space exploration.
Authors' Addresses Aalyria Technologies
rtaylor@aalyria.com
The Johns Hopkins University Applied Physics Laboratory
Edward.Birrane@jhuapl.edu