Internet DRAFT - draft-ietf-dtn-ipn-update
draft-ietf-dtn-ipn-update
Delay/Disruption Tolerant Networking R. Taylor
Internet-Draft Ori Industries
Updates: [9171, 7176] (if approved) E. Birrane
Intended status: Standards Track JHU/APL
Expires: 16 October 2023 14 April 2023
Update to the ipn URI scheme
draft-ietf-dtn-ipn-update-02
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/.
Taylor & Birrane Expires 16 October 2023 [Page 1]
Internet-Draft ipn-update April 2023
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 16 October 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Core Concepts . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. The Null ipn URI . . . . . . . . . . . . . . . . . . . . 5
3.2. Allocator Identifiers . . . . . . . . . . . . . . . . . . 6
3.2.1. Allocator Identifier Ranges . . . . . . . . . . . . . 6
3.2.2. The Default Allocator . . . . . . . . . . . . . . . . 8
3.3. Node Numbers . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1. Fully-qualified Node Numbers . . . . . . . . . . . . 8
3.4. Special Node Numbers . . . . . . . . . . . . . . . . . . 9
3.4.1. The Zero Node Number . . . . . . . . . . . . . . . . 9
3.4.2. LocalNode ipn URIs . . . . . . . . . . . . . . . . . 9
3.4.3. Private Use Node Numbers . . . . . . . . . . . . . . 9
3.5. Service Numbers . . . . . . . . . . . . . . . . . . . . . 10
4. Textual Encoding of ipn URIs . . . . . . . . . . . . . . . . 10
5. Usage of ipn URIs with BPv7 . . . . . . . . . . . . . . . . . 11
5.1. Uniqueness Constraints . . . . . . . . . . . . . . . . . 11
5.2. The Null Endpoint . . . . . . . . . . . . . . . . . . . . 11
5.3. BPv7 Node ID . . . . . . . . . . . . . . . . . . . . . . 11
5.4. LocalNode ipn EIDs . . . . . . . . . . . . . . . . . . . 12
5.5. Private Use Endpoints . . . . . . . . . . . . . . . . . . 12
5.6. Administrative Endpoints . . . . . . . . . . . . . . . . 12
6. Encoding ipn URIs with BPv7 . . . . . . . . . . . . . . . . . 12
6.1. ipn EID CBOR Encoding . . . . . . . . . . . . . . . . . . 13
6.1.1. Two-Element Scheme-Specific Encoding . . . . . . . . 13
Taylor & Birrane Expires 16 October 2023 [Page 2]
Internet-Draft ipn-update April 2023
6.1.2. Three-Element Scheme-Specific Encoding . . . . . . . 14
6.2. ipn EID CBOR Decoding . . . . . . . . . . . . . . . . . . 14
6.3. ipn EID Matching . . . . . . . . . . . . . . . . . . . . 15
7. Special Considerations . . . . . . . . . . . . . . . . . . . 15
7.1. Scheme Compatibility . . . . . . . . . . . . . . . . . . 16
7.2. Late Binding . . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Reliability and consistency . . . . . . . . . . . . . . . 17
8.2. Malicious construction . . . . . . . . . . . . . . . . . 17
8.3. Back-end transcoding . . . . . . . . . . . . . . . . . . 17
8.4. Rare IP address formats . . . . . . . . . . . . . . . . . 17
8.5. Sensitive information . . . . . . . . . . . . . . . . . . 17
8.6. Semantic attacks . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. 'ipn' Scheme URI Allocator Identifiers registry . . . . . 18
9.1.1. Guidance for Designated Experts . . . . . . . . . . . 19
9.2. 'ipn' Scheme URI Default Allocator Node Numbers
registry . . . . . . . . . . . . . . . . . . . . . . . . 20
9.3. 'ipn' Scheme URI Service Numbers registry . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
10.1. Normative References . . . . . . . . . . . . . . . . . . 24
10.2. Informative References . . . . . . . . . . . . . . . . . 25
Appendix A. ipn URI Scheme Text Syntax . . . . . . . . . . . . . 26
Appendix B. ipn URI Scheme Text Representation Examples . . . . 26
B.1. Using the Default Allocator . . . . . . . . . . . . . . . 26
B.2. Using a non-default Allocator . . . . . . . . . . . . . . 27
B.3. The Null ipn URI . . . . . . . . . . . . . . . . . . . . 27
B.4. A LocalNode ipn URI . . . . . . . . . . . . . . . . . . . 27
Appendix C. ipn URI Scheme CBOR Encoding . . . . . . . . . . . . 27
Appendix D. ipn URI Scheme CBOR Encoding Examples . . . . . . . 28
D.1. Using the Default Allocator . . . . . . . . . . . . . . . 28
D.2. Using a non-default Allocator . . . . . . . . . . . . . . 29
D.3. The 'null' Endpoint . . . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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-
Taylor & Birrane Expires 16 October 2023 [Page 3]
Internet-Draft ipn-update April 2023
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.
Taylor & Birrane Expires 16 October 2023 [Page 4]
Internet-Draft ipn-update April 2023
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
* 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 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.
Taylor & Birrane Expires 16 October 2023 [Page 5]
Internet-Draft ipn-update April 2023
3.2. Allocator Identifiers
An Allocator is any organization (e.g., vendor, manufacturer, co-
operative, or other entity) that wishes to assign Node Numbers for
use with the ipn URI scheme. 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.
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.
Taylor & Birrane Expires 16 October 2023 [Page 6]
Internet-Draft ipn-update April 2023
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. Every Allocator Identifier in the range MUST be valid.
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.
An example of the use of Allocator Identifier ranges for three
organizations (A, B, and C) is as follows:
+==============+=====================+=============+===============+
| Organization | Range Length (Bits) | Range (dec) | Range (hex) |
+==============+=====================+=============+===============+
| Org A | 7 bits | 36864-36991 | 0x9000-0x907F |
+--------------+---------------------+-------------+---------------+
| Org B | 4 bits | 36992-37007 | 0x9080-0x908F |
+--------------+---------------------+-------------+---------------+
| Org C | 1 bit | 37008-37009 | 0x9090-0x9091 |
+--------------+---------------------+-------------+---------------+
Table 1: Allocator Identifier Range Assignment Example
With these assignments, any Allocator Identifier whose most-
significant 25 bits match 0x9000 belong to organization A.
Similarly, any Allocator Identifier whose most-significant 28 bits
match 0x9080 belong to organization B and any Allocator Identifier
whose most-significant 31 bits are 0x9090 belong to organization C.
Taylor & Birrane Expires 16 October 2023 [Page 7]
Internet-Draft ipn-update April 2023
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 a 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 that sent the original message. Historically the
identifier of the sending node has been colloquially referred to as
the "node number" or "node identifier".
Taylor & Birrane Expires 16 October 2023 [Page 8]
Internet-Draft ipn-update April 2023
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. (2,100) is the FQNN for a node
assigned Node Number 100 by an Allocator with Allocator Identifier 2.
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].
Taylor & Birrane Expires 16 October 2023 [Page 9]
Internet-Draft ipn-update April 2023
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. If the Allocator Identifier is zero (0), then the <allocator-
identifier> and . MUST be omitted.
2. All leading 0 characters MUST be omitted.
3. If 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
4294967295, although both forms are valid encodings.
Examples of the textual representation of ipn URIs can be found in
Appendix B (Appendix B).
Taylor & Birrane Expires 16 October 2023 [Page 10]
Internet-Draft ipn-update April 2023
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:1.100.1, ipn:1.100.2, and ipn:1.100.3 MUST all refer
to services registered on the bundle processing node identified with
FQNN (1,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).
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.
Taylor & Birrane Expires 16 October 2023 [Page 11]
Internet-Draft ipn-update April 2023
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).
Taylor & Birrane Expires 16 October 2023 [Page 12]
Internet-Draft ipn-update April 2023
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:1.100.1 has an FQNN of (1.100) which
would be encoded as 0x0100000064. The resulting two-element array
[0x0100000064, 0x01] would be encoded in CBOR as the 11 octet value
0x821B000000010000006401.
Taylor & Birrane Expires 16 October 2023 [Page 13]
Internet-Draft ipn-update April 2023
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:1.100.1 would result in the three-
element array of [1,100,1] which would be encoded in CBOR as the 5
octet value 0x8301186401.
The three-element scheme-specific encoding allows for a more
efficient representation of ipn EIDs using smaller Allocator
Identifiers. In the examples in Appendix D (Appendix D), the two-
element encoding of ipn:1.100.1 was more then double the size of the
three-element encoding.
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.
Taylor & Birrane Expires 16 October 2023 [Page 14]
Internet-Draft ipn-update April 2023
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:1.100.1 can be represented as either
the two-element encoding of 0x821B000000010000006401 or the three-
element encoding of 0x8301186401. 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:1.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.
Taylor & Birrane Expires 16 October 2023 [Page 15]
Internet-Draft ipn-update April 2023
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.
Taylor & Birrane Expires 16 October 2023 [Page 16]
Internet-Draft ipn-update April 2023
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.
Taylor & Birrane Expires 16 October 2023 [Page 17]
Internet-Draft ipn-update April 2023
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:
+================+==================================================+
| Range | Registration Policy |
+================+==================================================+
| 0 .. 2^16-1 | Expert Review, Single Allocator Identifiers only |
+----------------+--------------------------------------------------+
| 2^16 .. | Expert Review |
| 2^30-1 | |
+----------------+--------------------------------------------------+
| 2^30 .. | Experimentation |
| 2^31-1 | |
+----------------+--------------------------------------------------+
| 2^31 .. | Reserved, Future Expansion |
| 2^32-1 | |
+----------------+--------------------------------------------------+
| >= 2^32 | Reserved |
+----------------+--------------------------------------------------+
Table 2: 'ipn' Scheme URI Numbering Allocator Identifiers
registration policies
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.
Allocator Identifiers are identified in the registry by the "Value"
field, which is of the format XXXXXXXX/N. In this format, N
represents the power of two representing the Allocator Identifier
range length, with N=0 indicating a single Allocator Identifier
(length of 2^0 = 1), with N=1 indicating a range of 2 Allocator
Taylor & Birrane Expires 16 October 2023 [Page 18]
Internet-Draft ipn-update April 2023
Identifiers (length of 2^1 = 2), and so on. XXXXXXXX is the
hexadecimal representation of the most-significant 32-N bits of the
first Allocator Identifier, with leading 0s elided. The least-
significant N bits of the first Allocator Identifier MUST be assigned
to all 0.
The initial values for the registry are:
+=======+===================+===============+==================+
| Value | Name | Reference | Point of Contact |
+=======+===================+===============+==================+
| 0/0 | Default Allocator | This document | IANA |
+-------+-------------------+---------------+------------------+
| 1/0 | CCSDS | TBD | www.sana.org |
+-------+-------------------+---------------+------------------+
Table 3: 'ipn' Scheme URI Allocator Identifiers initial values
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. Ensure that the requesting entity represents an organization and
not an individual.
2. 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.
3. 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).
4. Ensure that every value in the range 0 - 2^16-1 is a single
Allocator Identifier and not a range of Allocator Identifiers -
meaning that the value of N in the representation XXXXXXXX/N is
always 0.
Taylor & Birrane Expires 16 October 2023 [Page 19]
Internet-Draft ipn-update April 2023
5. Ensure that Allocator Identifier value assignments reflect
encoding needs. Experts should always prefer Allocator
Identifier values greater than or equal to 2^16 for
organizations, unless a compelling need statement is provided by
the organization for a smaller encoding. Allocator Identifier
values less than 25 should not be provided unless an organization
has a requirement to produce very small encodings.
6. Ensure that the name in the registry field appropriately
identifies the requesting organization.
7. Ensure that assigning any Allocator Identifier or Allocator
Identifier range would not create overlaps.
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:
+================+=================================================+
| 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 |
+----------------+-------------------------------------------------+
Table 4: 'ipn' Scheme URI Default Allocator Node Numbers
registration policies
The initial values for the registry remain as is, namely:
+===================+=====================+===============+=========+
| Value | Hex |Description |Reference|
+===================+=====================+===============+=========+
| 16384-2097151 | 0x4000-0x1FFFFF |Allocated to |Inherited|
| | |the Space |from |
| | |Assigned |[RFC7116]|
| | |Numbers | |
Taylor & Birrane Expires 16 October 2023 [Page 20]
Internet-Draft ipn-update April 2023
| | |Authority | |
| | |(SANA) for use | |
| | |by | |
| | |Consultative | |
| | |Committee for | |
| | |Space Data | |
| | |Systems | |
| | |(CCSDS) | |
| | |missions. | |
+-------------------+---------------------+---------------+---------+
|268435456-268451839|0x10000000-0x10003FFF|Allocated to |Scott |
| | |Spacely |Johnson |
| | |Packets, LLC | |
| | |to provide | |
| | |IPN/IP Gateway | |
| | |services to | |
| | |private sector | |
| | |stakeholders. | |
+-------------------+---------------------+---------------+---------+
|268451840-268468223|0x10004000-0x10007FFF|Allocated to |Alberto |
| | |SPATIAM |Montilla |
| | |CORPORATION to | |
| | |provide DTN | |
| | |services to | |
| | |organizations. | |
+-------------------+---------------------+---------------+---------+
|268468224-268484607|0x10008000-0x1000BFFF|Allocated to |Julia |
| | |Phoenix R&D |Longtin |
| | |GMBH to | |
| | |provide DTN | |
| | |services for | |
| | |secure | |
| | |messaging. | |
+-------------------+---------------------+---------------+---------+
|268484608-268500991|0x1000C000-0x1000FFFF|Allocated to |Samo |
| | |LateLab AB for |Grasic |
| | |various | |
| | |terrestrial | |
| | |DTN | |
| | |deployments | |
| | |and services. | |
+-------------------+---------------------+---------------+---------+
|268500992-268517375|0x10010000-0x10013FFF|Allocated to |Bostjan |
| | |MEIS d.o.o. |Grasic |
| | |from Slovenia | |
| | |for various | |
| | |terrestrial | |
| | |DTN testbeds. | |
Taylor & Birrane Expires 16 October 2023 [Page 21]
Internet-Draft ipn-update April 2023
+-------------------+---------------------+---------------+---------+
|268517376-268533759|0x10014000-0x10017FFF|Allocated to |Oscar |
| | |Digital Health |Garcia |
| | |Information | |
| | |Network Inc. | |
| | |for Space | |
| | |applications | |
| | |in digital | |
| | |health and | |
| | |terrestrial | |
| | |DTN services. | |
+-------------------+---------------------+---------------+---------+
|268533760-268550143|0x10018000-0x1001BFFF|Allocated to |Larissa |
| | |Shirokuma-AI |Suzuki |
| | |for artificial | |
| | |intelligence- | |
| | |driven space | |
| | |applications | |
| | |and | |
| | |terrestrial | |
| | |DTN services | |
| | |in the fields | |
| | |of healthcare, | |
| | |robotics, | |
| | |wearables and | |
| | |edge devices, | |
| | |information | |
| | |processing and | |
| | |discovery. | |
+-------------------+---------------------+---------------+---------+
|268550144-268566527|0x1001C000-0x1001FFFF|Assigned to |Jorge |
| | |LJCV |Amodio |
| | |Electronics | |
| | |for | |
| | |Development of | |
| | |an | |
| | |Experimental | |
| | |R&D DTN, STEM | |
| | |Education, | |
| | |space and | |
| | |terrestrial | |
| | |applications. | |
+-------------------+---------------------+---------------+---------+
Table 5: 'ipn' Scheme URI Default Allocator Node Numbers initial
values
Taylor & Birrane Expires 16 October 2023 [Page 22]
Internet-Draft ipn-update April 2023
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:
+================+========================+
| Range | Registration Policy |
+================+========================+
| 0 .. 23 | RFC Required |
+----------------+------------------------+
| 24 .. 2^15-1 | Specification Required |
+----------------+------------------------+
| 2^15 .. 2^31-1 | Private Use |
+----------------+------------------------+
| >= 2^31 | Reserved |
+----------------+------------------------+
Table 6: 'ipn' Scheme URI Service
Numbers registration policies
The current values for the registry remain, and are rewritten as:
Taylor & Birrane Expires 16 October 2023 [Page 23]
Internet-Draft ipn-update April 2023
+=======+=========+================================+============+
| Value | Version | Description | Reference |
+=======+=========+================================+============+
| 0 | BPv6, | The Administrative Endpoint | [RFC7116], |
| | BPv7 | | This |
| | | | document |
+-------+---------+--------------------------------+------------+
| 1 | BPv6 | CCSDS File Delivery Service | [CFDP] |
+-------+---------+--------------------------------+------------+
| 2 | BPv6 | Reserved | [RFC7116] |
+-------+---------+--------------------------------+------------+
| 2 | BPv7 | Unassigned | |
+-------+---------+--------------------------------+------------+
| 3 .. | BPv6, | Unassigned | |
| 63 | BPv7 | | |
+-------+---------+--------------------------------+------------+
| 64 .. | BPv6 | Allocated to the Space | [RFC7116] |
| 1023 | | Assigned Numbers Authority | |
| | | (SANA) for use by Consultative | |
| | | Committee for Space Data | |
| | | Systems (CCSDS) missions | |
+-------+---------+--------------------------------+------------+
| 64 .. | BPv7 | Unassigned | |
| 1023 | | | |
+-------+---------+--------------------------------+------------+
Table 7: 'ipn' Scheme URI Service Numbers initial values
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, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <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, January 2008,
<https://www.rfc-editor.org/rfc/rfc5234>.
Taylor & Birrane Expires 16 October 2023 [Page 24]
Internet-Draft ipn-update April 2023
[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, February 2014,
<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, June 2017,
<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,
May 2017, <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,
June 2019, <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, December 2020,
<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,
January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.
10.2. Informative References
[CFDP] The Consultative Committee for Space Data Systems, "CCSDS
FILE DELIVERY PROTOCOL (CFDP)", January 2007,
<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,
February 1996, <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, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
Taylor & Birrane Expires 16 October 2023 [Page 25]
Internet-Draft ipn-update April 2023
[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, August
2006, <https://www.rfc-editor.org/rfc/rfc4632>.
[RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)",
RFC 6260, DOI 10.17487/RFC6260, May 2011,
<https://www.rfc-editor.org/rfc/rfc6260>.
[RFC9172] Birrane, E., III., and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <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).
Taylor & Birrane Expires 16 October 2023 [Page 26]
Internet-Draft ipn-update April 2023
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 100.
The complete 11 character representation of this URI would be as
follows:
ipn:100.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:
Taylor & Birrane Expires 16 October 2023 [Page 27]
Internet-Draft ipn-update April 2023
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:
Taylor & Birrane Expires 16 October 2023 [Page 28]
Internet-Draft ipn-update April 2023
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:100.1.1. This textual representation of an
ipn EID identifies Service Number 1 on Node Number 1 allocated by
Allocator 100.
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 0000006400000001 # Fully-qualified Node Number
01 # Service Number
The complete seven 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
18 64 # 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:
Taylor & Birrane Expires 16 October 2023 [Page 29]
Internet-Draft ipn-update April 2023
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
Email: rick.taylor@ori.co
Ed Birrane
JHU/APL
Email: Edward.Birrane@jhuapl.edu
Taylor & Birrane Expires 16 October 2023 [Page 30]
