Update to the DTN ipn Endpoint Identifier scheme
draft-taylor-dtn-ipn-update-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Rick Taylor , Edward J. Birrane | ||
| Last updated | 2022-09-15 | ||
| Replaced by | draft-ietf-dtn-ipn-update | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-taylor-dtn-ipn-update-00
Delay/Disruption Tolerant Networking R. Taylor
Internet-Draft Ori Industries
Updates: [9171, 7176] (if approved) E. Birrane
Intended status: Standards Track JHU/APL
Expires: 19 March 2023 15 September 2022
Update to the DTN ipn Endpoint Identifier scheme
draft-taylor-dtn-ipn-update-00
Abstract
The Delay Tolerant Networking 'ipn' Endpoint Identifier scheme was
first defined as Compressed Bundle Header Encoding (CBHE) [RFC6260]
for use with the Bundle Protocol version 6 (BPv6) [RFC5050].
[RFC7116] updated [RFC6260] and requested IANA registries associated
with the ipn scheme when used with BPv6. The Bundle Protocol version
7 (BPv7) specification [RFC9171] also defines an ipn scheme (for use
with BPv7) by reusing the format from [RFC6260]. The evolution and
specification of the ipn scheme has led to confusion over its use and
format between BPv6 and BPv7.
This document defines the ipn scheme as it is to be used with BPv7
and also updates [RFC7116] to make it clear that IANA CBHE registries
are only to be used for BPv6. This document also updates the format
of the BPv7 ipn scheme to include Numbering Authorities and requests
the formation of BPv7 ipn scheme IANA registries.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://ricktaylor.github.io/ipn2/draft-taylor-dtn-ipn-update.html.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-taylor-dtn-ipn-update/.
Discussion of this document takes place on the Delay/Disruption
Tolerant Networking Working Group mailing list (mailto:dtn@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/dtn/.
Subscribe at https://www.ietf.org/mailman/listinfo/dtn/.
Source for this draft and an issue tracker can be found at
https://github.com/ricktaylor/ipn2.
Taylor & Birrane Expires 19 March 2023 [Page 1]
Internet-Draft ipn-update September 2022
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 March 2023.
Copyright Notice
Copyright (c) 2022 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. The Legacy 'ipn' Scheme in RFC9171 . . . . . . . . . . . . . 4
3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Text Encoding . . . . . . . . . . . . . . . . . . . . 5
3.1.2. CBOR Encoding . . . . . . . . . . . . . . . . . . . . 5
3.2. Uniqueness Constraints . . . . . . . . . . . . . . . . . 6
3.3. Global Flat Namespace . . . . . . . . . . . . . . . . . . 6
3.3.1. Allocation Ranges . . . . . . . . . . . . . . . . . . 7
4. Updates to RFC7116 and RFC9171 . . . . . . . . . . . . . . . 7
4.1. BPv7 'ipn' Scheme Node Numbers . . . . . . . . . . . . . 7
4.2. BPv6 'ipn' Scheme Node Numbers . . . . . . . . . . . . . 8
4.3. BPv7 'ipn' Scheme Service Numbers . . . . . . . . . . . . 8
4.4. BPv6 'ipn' Scheme Service Numbers . . . . . . . . . . . . 9
5. The Interoperable BPv7 'ipn' Scheme . . . . . . . . . . . . . 9
Taylor & Birrane Expires 19 March 2023 [Page 2]
Internet-Draft ipn-update September 2022
5.1. Numbering Authorities . . . . . . . . . . . . . . . . . . 9
5.1.1. Numbering Sub-authorities . . . . . . . . . . . . . . 10
5.1.2. The Local Numbering Authority . . . . . . . . . . . . 10
5.1.3. Backwards Compatibility . . . . . . . . . . . . . . . 10
5.2. Prefix Encoding . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. Text Encoding . . . . . . . . . . . . . . . . . . . . 11
5.2.2. CBOR Encoding . . . . . . . . . . . . . . . . . . . . 12
5.3. Recommendations . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7.1. Bundle Protocol Version 7 'ipn' Scheme Local Node Numbers
registry . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2. Bundle Protocol Version 7 'ipn' Scheme Service Numbers
registry . . . . . . . . . . . . . . . . . . . . . . . . 14
7.3. Bundle Protocol Version 7 'ipn' Scheme Authority Numbers
registry . . . . . . . . . . . . . . . . . . . . . . . . 15
7.4. CBHE Node Numbers registry . . . . . . . . . . . . . . . 16
7.5. CBHE Service Numbers registry . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Discussion Points . . . . . . . . . . . . . . . . . 17
A.1. Why define all of the RFC9171 'ipn' scheme node-nbrs as
'Private Use'? . . . . . . . . . . . . . . . . . . . . . 17
A.2. Why not just sub-divide the BPv7 'ipn' node-nbr space like
BPv6? . . . . . . . . . . . . . . . . . . . . . . . . . . 18
A.3. Why not a new 'ipn3' EID scheme? . . . . . . . . . . . . 18
A.4. Why not use just the 'dtn' scheme for
interoperability? . . . . . . . . . . . . . . . . . . . . 18
A.5. Won't these changes break BPv6 compatibility? . . . . . . 19
A.6. Why not have an unbounded number of sub-authorities? . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
From the earliest days of experimentation with "store and forward"
data transfer with the Bundle Protocol, the desire has existed for a
simple way to enumerate the nodes and services in a Delay Tolerant
Network (DTN). With the IRTF standardisation of the experimental
Bundle Protocol version 6 (BPv6) [RFC5050], an associated
specification for numeric node identifiers and numeric service
identifiers was described in Section 2.1 of [RFC6260]. Further,
[RFC6260] also defined the 'ipn' Endpoint Identifier (EID) naming
scheme which identifies a DTN endpoint using node and service
identifiers. The acronym IPN was originally an expansion of the term
"InterPlanetary Network" as the original aim of this scheme was to
provide a compact namespace for an interoperable space-based DTN
Taylor & Birrane Expires 19 March 2023 [Page 3]
Internet-Draft ipn-update September 2022
architecture.
Beyond space-based applications, terrestrial nodes might also operate
with limited power, bandwidth, and/or compute budget. The adoption
of DTN in the IETF, resulting in the publication of the Bundle
Protocol version 7 (BPv7) [RFC9171], will result in operational
deployments of BPv7 nodes for both terrestrial and non-terrestrial
use cases. This includes BPv7 networks operating over the
terrestrial Internet and BPv7 networks operating in self-contained
environments behind a shared administrative domain.
In all cases, concisely encoded numeric identifiers for both nodes
and services provides processing advantages over more verbose naming
schemes. Therefore additional focus has been placed on the
capabilities of the 'ipn' scheme for use beyond its historical
purpose for space-based DTN architectures. This expanded use of the
'ipn' scheme for BPv7 networks requires both some updates to the
'ipn' scheme itself and a clearer distinction between the uses of
'ipn' schemes in BPv6 and BPv7 networks.
This document updates the definition of the 'ipn' scheme (in ways
that are backwards compatible for existing 'ipn' uses) to include
adding an optional naming authority to distinguish node namespaces.
This document also defines new IANA registries associated with both
the updated IPN scheme and the use of node and service identifiers
for use specifically with BPv7.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The Legacy 'ipn' Scheme in RFC9171
This section describes the specification of the 'ipn' EID scheme as
defined in [RFC9171] and is included as convenient reference for the
rest of this document.
Taylor & Birrane Expires 19 March 2023 [Page 4]
Internet-Draft ipn-update September 2022
3.1. Encoding
Section 4.2.5.1.2 of [RFC9171] specifies the 'ipn' EID scheme for
BPv7, with an identical format to the specification of the 'ipn' EID
scheme for BPv6 in Section 2.1 of [RFC6260], namely as a sequence of
two unsigned integers. The first number representing the identifier
of the node (node-nbr), and the second being the identifier of a
particular service expected at that node (service-nbr).
3.1.1. Text Encoding
As specified in [RFC9171], the textual encoding of an 'ipn' scheme
EID must comply with the following ABNF [RFC5234] syntax, including
the core ABNF syntax rule for DIGIT defined by that specification:
ipn-uri = "ipn:" ipn-hier-part
ipn-hier-part = node-nbr nbr-delim service-nbr
node-nbr = 1*DIGIT
nbr-delim = "."
service-nbr = 1*DIGIT
3.1.2. CBOR Encoding
As specified in [RFC9171], when encoded in Concise Binary Object
Representation (CBOR) [RFC8949], an 'ipn' scheme EID must comply with
the following Concise Data Definition Language (CDDL) [RFC8610]
specification:
eid = $eid .within eid-structure
eid-structure = [
uri-code: uint,
SSP: any
]
; ... Syntax for uri-code 1 (dtn scheme) omitted ...
$eid /= [
uri-code: 2,
SSP: [
nodenum: uint,
servicenum: uint
]
]
Taylor & Birrane Expires 19 March 2023 [Page 5]
Internet-Draft ipn-update September 2022
Because the encoding of node-nbr and service-nbr (specified in the
CDDL as nodenum and servicenum) are defined as CBOR uint types, both
values are restricted by this encoding to a range of [0 .. 2^64-1].
3.2. Uniqueness Constraints
As described in Section 4.2.5.2 of [RFC9171], the identifier of a
node (Node ID) must be a singleton endpoint, see Section 3.1 of
[RFC9171]. Section 3.2.2 of [RFC7116] allocates the service-nbr 0 to
the 'Bundle Protocol Administrative Record' for the 'ipn' EID scheme
for BPv6, and Section 4.2.5.1.2 of [RFC9171] derives from this
earlier specification, and more loosely states that the service-nbr
zero (0) MAY identify the 'administrative endpoint' of a node, and in
combination with a valid node-nbr, it can be used as a BPv7 Node ID.
From this we can deduce the following rules:
1. An 'ipn' scheme EID, perhaps with service-nbr 0, MAY be a valid
unique Node ID when used with BPv7.
2. Because the node-nbr component of 'ipn' scheme EIDs of all
services on a node must be identical, when used with BPv7, the
node-nbr component MUST be unique to each node within a given
network.
Because the ipn scheme encodes the Node Id, every 'ipn' scheme EID is
a singleton EID. This means the following: 1. Only a single node
can ever be registered in a given 'ipn' scheme EID at a given time.
1. Every 'ipn' scheme EID to which a node is registered must share
the same node-nbr.
3.3. Global Flat Namespace
Since the legacy ipn scheme encodes the Node ID as the node number,
and the Node ID must be a globally unique identifier, this means that
the legacy ipn scheme node-nbrs must, themselves, be globally unique.
The legacy ipn scheme node-nbr exists in a single, global, flat
namespace.
The reliance on such a namespace is not problematic when deploying a
private, self-contained network: If there are few nodes that can ever
intercommunicate, then those nodes can have node-nbrs allocated by
the administrator of that network and there will be no problem with
uniqueness coming from a serialized, central authority. However, as
the number of nodes and number of administrative authorities in a
network scale, the administrative burden of assigning node-nbrs
increases.
Taylor & Birrane Expires 19 March 2023 [Page 6]
Internet-Draft ipn-update September 2022
3.3.1. Allocation Ranges
A potential solution to this, as described in Section 3.2.1 of
[RFC7116], is to assign ranges of node-nbrs to different authorities,
from which they can independently allocate node-nbrs.
The use of a global, flat namespace (in general) and the use of
predefined allocations (in particular) present two practical problems
relating to encoding efficiency and namespace exhaustion.
This division of the number space is an adequate solution for the
uniqueness problem, but it introduces a new issue: The encoding-
length of each node-nbr is no longer minimal, as the offset to the
start of the range assigned to the allocating authority is included
in the node-nbr. For example: Section 3.2.1 of [RFC7116] allocates
[CCSDS] the range [2^14 .. 2^21-1] for node-nbrs for use with BPv6,
and if CCSDS choses to continue to use this number range for BPv7,
the CBOR encoding of every Node ID will be at least 7 octets
(including 2 octets for the outer array with uri-code), even when
interoperability is not required:
82 # array(2)
02 # uri-code: 2
82 # array(2)
19 4000 # node-nbr: 16384
00 # service-nbr: 0
Another side-effect of assigning ranges of the number space to
different sub-allocating authorities is to reduce the total
availability of node-nbrs. Although the current allocation strategy
defined in [RFC7116] leaves approximately 2^42 numbers unallocated,
the recommendation to IANA is that these numbers should be allocated
in blocks of 2^14. The history of IPv4 address allocation, see
Section 2.1 of [RFC1287], demonstrates that exhaustion of a 2^32 bit
number space happens surprisingly quickly.
4. Updates to RFC7116 and RFC9171
This section updates the use of 'ipn' scheme EIDs when used with BPv7
as specified in [RFC9171] to address some of the limitations
described above, and renames two of the registries defined in
[RFC7116] to clarify their usage with BPv6 only.
4.1. BPv7 'ipn' Scheme Node Numbers
The following rules update or clarify the specification of node-nbr
in Section 4.2.5.1.2 of [RFC9171]:
Taylor & Birrane Expires 19 March 2023 [Page 7]
Internet-Draft ipn-update September 2022
1. The node-nbr component of an 'ipn' scheme EID MUST be an unsigned
integer >= 0.
2. The 'ipn' scheme EID "ipn:0.0" is assigned to the 'null'
endpoint, see Section 3.2 of [RFC9171].
3. If the node-nbr component of an 'ipn' scheme EID is zero (0),
then the service-nbr component MUST be zero (0).
4. Non-zero 'ipn' EID scheme node-nbrs are explicitly 'Private Use',
see Section 4.1 of [RFC8126]. Therefore they MUST NOT be
regarded as unique beyond the administrative domain defined by
the allocating authority, and interoperability with other
administrative domains MUST NOT be assumed.
5. Values >= 2^64 for the node-nbr component of an 'ipn' scheme EID
are 'Reserved', see Section 6 of [RFC8126], to allow concise
unsigned integer (type 0) CBOR encoding.
To support this update, a new IANA "Bundle Protocol Version 7 'ipn'
Scheme Node Numbers" registry is defined for the node-nbr component
of an 'ipn' scheme EID when used with BPv7.
4.2. BPv6 'ipn' Scheme Node Numbers
The "CBHE Node Numbers" registry specified in Section 3.2.1 of
[RFC7116] is renamed without change to the "Bundle Protocol Version 6
'ipn' Scheme Node Numbers" registry, to clarify that it is for use
solely with BPv6, see IANA Considerations (Section 7).
4.3. BPv7 'ipn' Scheme Service Numbers
The following rules update or clarify the specification of service-
nbr in Section 4.2.5.1.2 of [RFC9171], deriving from the definitions
in Section 3.2.2 of [RFC7116]:
1. The service-nbr component of an 'ipn' scheme EID MUST be an
unsigned integer >= 0.
2. The administrative endpoint as defined in Section 3.2 of
[RFC9171] of an 'ipn' scheme EID MUST be service-nbr zero (0).
3. Values >= 2^64 for the service-nbr component of an 'ipn' scheme
EID are 'Reserved', see Section 6 of [RFC8126], to allow concise
unsigned integer (type 0) CBOR encoding.
Taylor & Birrane Expires 19 March 2023 [Page 8]
Internet-Draft ipn-update September 2022
To support this update, a new IANA "Bundle Protocol Version 7 'ipn'
Scheme Service Numbers" registry is defined for the service-nbr
component of an 'ipn' scheme EID when used with BPv7.
4.4. BPv6 'ipn' Scheme Service Numbers
The "CBHE Service Numbers" registry specified in Section 3.2.2 of
[RFC7116] is renamed without change to the "Bundle Protocol Version 6
'ipn' Scheme Service Numbers" registry, to clarify that it is for use
solely with BPv6, see IANA Considerations (Section 7).
5. The Interoperable BPv7 'ipn' Scheme
The consequence of the updates to the 'ipn' EID scheme described
above (Section 4) is to remove any capability to send bundles between
nodes with 'ipn' scheme EIDs enumerated by two different allocating
authorities, as there is no explicit indication of which authority
allocated which corresponding node-nbr, resulting in a violation of
the uniqueness constraints. This situation is obviously untenable
when building DTNs beyond a fairly small scale.
5.1. Numbering Authorities
Underlying the BPv6 'ipn' scheme node-nbr range assignment if
[RFC7116] is the desire to reduce the administrative burden on a
single allocation authority for all node-nbrs by delegating the
authority to assign numbers to a pre-agreed set of numbering
authorities. Although the range-based mechanism of delegating this
authority has been criticised above (Section 3.3.1), the desire for
delegation of numbering to a group of independent authorities in an
interoperable way is still valid.
To address this, this document introduces the concept of Numbering
Authorities. A Numbering Authority has a unique numeric identifier,
but has the authority to allocate any node-nbr in the full 2^64
unsigned integer range according to its own rules. In order to
ensure interoperability between Numbering Authorities, a new IANA
"Bundle Protocol Version 7 'ipn' Scheme Authority Numbers" registry
is defined for the registration of Authority Numbers, see IANA
Considerations (Section 7). Although the uniqueness of Numbering
Authority identifiers is required for interoperable DTN operations,
identifier ranges are explicitly reserved for experimentation and
private use for when interoperability is not required.
The only number allocation constraint placed upon a Numbering
Authority is that the node-nbr zero (0) MUST not be allocated.
Taylor & Birrane Expires 19 March 2023 [Page 9]
Internet-Draft ipn-update September 2022
5.1.1. Numbering Sub-authorities
Some organisations that register as Numbering Authorities may be
sufficiently large that acting as a single allocating authority for
their desired number range becomes administratively untenable, for
example government agencies. In this case, the ability to delegate
number allocation to sub-authorities is desired. To address this,
this specification permits the addition of a Numbering Sub-authority
numeric identifier, when required, from a registry controlled by the
Numbering Authority to the Interoperable BPv7 'ipn' scheme EID.
In order to avoid unbounded sequences of sub-sub-authorities, making
processing in constrained devices overly onerous, only a single
Numbering Sub-authority is permitted in an Interoperable BPv7 'ipn'
scheme EID.
5.1.2. The Local Numbering Authority
The numeric identifier zero (0) is allocated in the "Bundle Protocol
Version 7 'ipn' Scheme Authority Numbers" registry for the Local
Numbering Authority. When a bundle processing agent processes a
bundle containing EIDs using the Interoperable BPv7 'ipn' scheme,
with a Numbering Authority identifier of zero (0), the Numbering
Authority identifier of such EIDs MUST considered to be the same as
the Numbering Authority of the 'ipn' scheme NodeId of the bundle
processing agent.
The Local Numbering Authority does not support Numbering Sub-
authorities, and therefore any Numbering Sub-authority identifier
MUST NOT be included when composing Interoperable BPv7 'ipn' scheme
EIDs. When a bundle processing agent encounters an Interoperable
BPv7 'ipn' scheme EID with Number Authority identifier zero (0) and a
Numbering Sub-authority identifier, then the Numbering Sub-authority
identifier MUST be ignored.
5.1.3. Backwards Compatibility
Although the Interoperable BPv7 'ipn' EID scheme introduces the
ability to include Numbering Authority identifiers, it does not
preclude the use of BPv7 'ipn' scheme EIDs without such an
identifier. To allow for backwards compatibility, when a bundle
processing agent processes a BPv7 bundle containing 'ipn' scheme EIDs
without a Numbering Authority identifier, unless the EID is the
'null' endpoint (ipn:0.0), the Numbering Authority identifier MUST
considered to be zero (0), and therefore treated in the the same
manner as the Local Numbering Authority (Section 5.1.2).
Taylor & Birrane Expires 19 March 2023 [Page 10]
Internet-Draft ipn-update September 2022
5.2. Prefix Encoding
Fundamentally, [RFC9171] 'ipn' scheme EIDs are represented as a
sequence of unsigned integers: In the text encoding, the numbers are
separated with the '.' delimiter; in CBOR, encoded as an array of
unsigned integers. Adding the numeric identifier of the numbering
authority, possibly with sub-authorities, that allocated the
subsequent node-nbr as a prefix to EIDs allows for a concise encoding
of a suitable discriminator, without reducing the total availability
of node-nbrs.
In the text encoding, this is as simple as pre-pending numeric
identifiers for the numbering authorities, separated with the '.'
delimiter, to the text. For the CBOR encoding, this is achieved by
increasing the dimension of the array of unsigned integers to include
the relevant numbering authority identifiers.
For example, the EID "ipn:2.1.0" uniquely identifies the
administrative endpoint of the node allocated the node-nbr 1 by the
numbering authority with identifier 2. This EID can be concisely
encoded in CBOR as 6 octets, including 2 octets for the outer array
with uri-code:
82 # array(2)
02 # uri-code: 2
83 # array(3)
02 # auth-nbr: 2
01 # node-nbr: 1
00 # service-nbr: 0
This prefixing method is be extended to allow numbering authorities
to delegate allocation of numbers to sub-authorities as they see fit,
by appending further sub-authority identifiers to the prefix.
5.2.1. Text Encoding
The textual encoding of an 'ipn' scheme EID MUST comply with the
following ABNF [RFC5234] syntax, including the core ABNF syntax rule
for DIGIT defined by that specification:
Taylor & Birrane Expires 19 March 2023 [Page 11]
Internet-Draft ipn-update September 2022
ipn-uri = "ipn:" ipn-hier-part
ipn-hier-part = auth-part? node-nbr nbr-delim service-nbr
auth-part = auth-nbr nbr-delim sub-auth-part?
sub-auth-part = sub-auth-nbr nbr-delim
auth-nbr = 1*DIGIT
sub-auth-nbr = 1*DIGIT
node-nbr = 1*DIGIT
service-nbr = 1*DIGIT
nbr-delim = "."
5.2.2. CBOR Encoding
When encoded in Concise Binary Object Representation (CBOR)
[RFC8949], an 'ipn' scheme EID MUST comply with the following Concise
Data Definition Language (CDDL) [RFC8610] specification:
eid = $eid .within eid-structure
eid-structure = [
uri-code: uint,
SSP: any
]
; ... Syntax for other uri-code values defined in RFC9171 ...
$eid /= [
uri-code: 2,
SSP: [
? authority,
node-nbr: uint,
service-nbr: uint
]
authority = (
auth-nbr: uint,
? sub-auth-nbr: uint
)
]
Taylor & Birrane Expires 19 March 2023 [Page 12]
Internet-Draft ipn-update September 2022
Because the encoding of auth-nbr, sub-auth-nbr, node-nbr, and
service-nbr are defined as CBOR uint types, all values are restricted
by this encoding to a range of [0 .. 2^64-1].
5.3. Recommendations
[RFC9171] mandates the concept of "late binding" of an EID, where-by
the address of the destination of a bundle is resolved from its
identifier hop by hop as it transits a DTN. This per-hop binding of
identifiers to addresses underlines the fact that EIDs are purely
names, and may not carry any implicit or explicit information
concerning the current location or reachability of an identified node
and service. This removes the need to rename a node as its location
changes.
Because of this late binding concept, the authority components of an
interoperable 'ipn' scheme EID SHOULD NOT be regarded as some kind of
"type field", and used to derive additional information from the
other components of the EID. An example of incorrect behaviour would
be: "I know authority X allocates node-nbrs derived from the MAC
address of some link-layer device on each node, and so I can just
send packets directly to that MAC address". No matter the authority
that controls the allocation of node-nbrs, they remain just numbers,
without additional meaning.
6. Security Considerations
*TODO*
7. IANA Considerations
The following sections detail requests to IANA for new registries,
and the renaming of existing registries.
7.1. Bundle Protocol Version 7 'ipn' Scheme Local Node Numbers registry
IANA is requested to create a new registry entitled "Bundle Protocol
Version 7 'ipn' Scheme Local Node Numbers" with the following
assignments:
Taylor & Birrane Expires 19 March 2023 [Page 13]
Internet-Draft ipn-update September 2022
+=============+===================+===============+
| Value | Description | Reference |
+=============+===================+===============+
| 0 | The null endpoint | This document |
+-------------+-------------------+---------------+
| 1 .. 2^64-1 | Private Use | This document |
+-------------+-------------------+---------------+
| >= 2^64 | Reserved | This document |
+-------------+-------------------+---------------+
Table 1: Bundle Protocol Version 7 'ipn' Scheme
Local Node Numbers
All possible values are assigned.
7.2. Bundle Protocol Version 7 'ipn' Scheme Service Numbers registry
IANA is requested to create a new registry entitled "Bundle Protocol
Version 7 'ipn' Scheme Service Numbers"
The registration policy for this registry is:
+================+========================+
| Range | Registration Policy |
+================+========================+
| 0 .. 23 | RFC Required |
+----------------+------------------------+
| 24 .. 4095 | Specification Required |
+----------------+------------------------+
| 4096 .. 2^32-1 | Private Use |
+----------------+------------------------+
| 2^32 .. 2^64-1 | Experimental Use |
+----------------+------------------------+
| >= 2^64 | Reserved |
+----------------+------------------------+
Table 2: Bundle Protocol Version 7
'ipn' Scheme Service Numbers
registration policies
The initial values for the registry are:
Taylor & Birrane Expires 19 March 2023 [Page 14]
Internet-Draft ipn-update September 2022
+=======+=============================+===============+
| Value | Description | Reference |
+=======+=============================+===============+
| 0 | The administrative endpoint | This document |
+-------+-----------------------------+---------------+
Table 3: Bundle Protocol Version 7 'ipn' Scheme
Service Numbers initial values
7.3. Bundle Protocol Version 7 'ipn' Scheme Authority Numbers registry
IANA is requested to create a new registry entitled "Bundle Protocol
Version 7 'ipn' Scheme Authority Numbers"
The registration policy for this registry is:
+================+=========================+
| Range | Registration Policy |
+================+=========================+
| 0 .. 2^16-1 | First Come First Served |
+----------------+-------------------------+
| 2^16 .. 2^32-1 | Private Use |
+----------------+-------------------------+
| 2^32 .. 2^64-1 | Experimental Use |
+----------------+-------------------------+
| >= 2^64 | Reserved |
+----------------+-------------------------+
Table 4: Bundle Protocol Version 7 'ipn'
Scheme Authority Numbers registration
policies
The initial values for the registry are:
+=======+===============================+=================+
| Value | Description | Reference |
+=======+===============================+=================+
| 0 | The Local Numbering Authority | This document |
| | | (Section 5.1.2) |
+-------+-------------------------------+-----------------+
Table 5: Bundle Protocol Version 7 'ipn' Scheme
Authority Numbers initial values
Taylor & Birrane Expires 19 March 2023 [Page 15]
Internet-Draft ipn-update September 2022
7.4. CBHE Node Numbers registry
IANA is request to rename the "CBHE Node Numbers" registry defined in
Section 3.2.1 of [RFC7116] to the "Bundle Protocol Version 6 'ipn'
Scheme Node Numbers", with no change to its allocation rules or
current allocations.
7.5. CBHE Service Numbers registry
IANA is requested to rename the "CBHE Service Numbers" registry
defined in Section 3.2.2 of [RFC7116] to the "Bundle Protocol Version
6 'ipn' Scheme Service Numbers", with no change to its allocation
rules or current allocations.
8. References
8.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>.
[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>.
[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>.
Taylor & Birrane Expires 19 March 2023 [Page 16]
Internet-Draft ipn-update September 2022
[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>.
8.2. Informative References
[CCSDS] "The Consultative Committee for Space Data Systems",
<http://www.ccsds.org>.
[RFC1287] Clark, D., Chapin, L., Cerf, V., Braden, R., and R. Hobby,
"Towards the Future Internet Architecture", RFC 1287,
DOI 10.17487/RFC1287, December 1991,
<https://www.rfc-editor.org/rfc/rfc1287>.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/rfc/rfc5050>.
[RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)",
RFC 6260, DOI 10.17487/RFC6260, May 2011,
<https://www.rfc-editor.org/rfc/rfc6260>.
Appendix A. Discussion Points
_(This whole section is to be removed prior to publication)_
A.1. Why define all of the RFC9171 'ipn' scheme node-nbrs as 'Private
Use'?
Because there is currently no BPv7 standard specifying that they are
not, and current implementations already assume that they can just
use node-nbrs as they like.
The de-facto standard, at of time of writing, is that DTNs using the
'ipn' EID scheme are not interoperable, or have pre-agreed an
allocation scheme between communities participating in a joint DTN.
This pre-agreement is just a shared administrative domain, probably
with range-based sub-allocation scheme which results in inefficient
encoding, and is still not universally interoperable, but this update
does not break those implementations.
Taylor & Birrane Expires 19 March 2023 [Page 17]
Internet-Draft ipn-update September 2022
Even with this update, when ipn EIDs are used without an auth-nbr,
there is no guarantee of interoperability, and they are therefore
"Private Use".
A.2. Why not just sub-divide the BPv7 'ipn' node-nbr space like BPv6?
See Allocation Ranges (Section 3.3.1).
A.3. Why not a new 'ipn3' EID scheme?
Is there really any difference in outcome between the following
cases?:
1. An existing parser receives a bundle with an EID with a 3-ary ipn
EID
2. An existing parser receives a bundle with an EID with an
unrecognised scheme identifier
In the former case, the parser will recognised the scheme as 'ipn'
but then fail as the dimension of the subsequent array is not 2. In
the latter case the parser will fail one octet earlier when the
scheme is not recognised. In both cases, the EID will not be
recognised as valid, forwarding will be "contraindicated", and the
process described in Step 2 of Section 5.4 of [RFC9171] should be
followed.
It is believed that introducing a new EID scheme will just result in
fragmentation of support. 'ipn' is popular because it is simple;
let's not introduce another 'simple' EID scheme to compete with it,
but rather add just enough support for universal interoperability.
'ipn' as defined in RFC9171 needs clarification, so why not just add
the tweaks necessary as long as we don't break back-compatibility?
A.4. Why not use just the 'dtn' scheme for interoperability?
Because the 'dtn' scheme definition in RFC9171 is intentionally left
wide open for further work. That work has yet to happen and is a
considered a much more complex task than a simple update to the 'ipn'
scheme.
Taylor & Birrane Expires 19 March 2023 [Page 18]
Internet-Draft ipn-update September 2022
A.5. Won't these changes break BPv6 compatibility?
Because of the difference in encoding between BPv6 and BPv7, there is
no on-the-wire compatibility between the versions. Any 'dual-stack'
gateway BPA is going to have to encapsulate BPv6 in BPv7 (or vice-
versa), so the EID of the decapsulating endpoint will have to be used
in the 'envelope' bundle. There is no way a BPv7 node can send a
bundle to a BPv6 node directly using BPv7, so backwards compatibility
of EIDs between protocol versions is not needed.
A.6. Why not have an unbounded number of sub-authorities?
It's possible to encode, and has been considered by the authors, but
the conclusion was:
ipn:it.is.really.not.a.great.idea.to.have.unbounded.sequences.of.iden
tifiers.when.it.comes.to.processing.EIDs.in.constrained.environments.
0
An optional, single sub-authority seemed like a sensible idea, but
feel free to argue on the list for more.
Acknowledgments
TODO acknowledge.
Authors' Addresses
Rick Taylor
Ori Industries
Email: rick.taylor@ori.co
Ed Birrane
JHU/APL
Email: Edward.Birrane@jhuapl.edu
Taylor & Birrane Expires 19 March 2023 [Page 19]