Update to the ipn URI scheme
draft-ietf-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: 11 May 2023                                     7 November 2022

                      Update to the ipn URI scheme
                      draft-ietf-dtn-ipn-update-00

Abstract

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

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

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://ricktaylor.github.io/ipn2/draft-taylor-dtn-ipn-update.html.
   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-dtn-ipn-update/.

Taylor & Birrane           Expires 11 May 2023                  [Page 1]
Internet-Draft                 ipn-update                  November 2022

   Discussion of this document takes place on the Delay/Disruption
   Tolerant Networking Working Group mailing list (mailto:dtn@ietf.org),
   which is archived at https://mailarchive.ietf.org/arch/browse/dtn/.
   Subscribe at https://www.ietf.org/mailman/listinfo/dtn/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ricktaylor/ipn2.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 11 May 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 . . . . . . . . . . . . . . . . .   5
   3.  The 'ipn' URI Scheme as defined in RFC9171  . . . . . . . . .   5
     3.1.  Text Syntax . . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  CBOR Encoding . . . . . . . . . . . . . . . . . . . . . .   6
     3.3.  Node and Service Numbers  . . . . . . . . . . . . . . . .   6
     3.4.  Allocation Ranges . . . . . . . . . . . . . . . . . . . .   7

Taylor & Birrane           Expires 11 May 2023                  [Page 2]
Internet-Draft                 ipn-update                  November 2022

   4.  Updates to RFC9171  . . . . . . . . . . . . . . . . . . . . .   8
     4.1.  'ipn' URI Scheme Node Numbers for BPv7  . . . . . . . . .   8
     4.2.  'ipn' URI Scheme Service Numbers for BPv7 . . . . . . . .   8
   5.  Updates to RFC7116  . . . . . . . . . . . . . . . . . . . . .   9
     5.1.  'ipn' URI Scheme Node Numbers for BPv6  . . . . . . . . .   9
     5.2.  'ipn' URI Scheme Service Numbers for BPv6 . . . . . . . .   9
   6.  Update to the 'ipn' URI Scheme  . . . . . . . . . . . . . . .   9
     6.1.  Numbering Authorities . . . . . . . . . . . . . . . . . .  10
       6.1.1.  Numbering Sub-authorities . . . . . . . . . . . . . .  10
     6.2.  Prefix Encoding . . . . . . . . . . . . . . . . . . . . .  11
       6.2.1.  Text Syntax . . . . . . . . . . . . . . . . . . . . .  11
       6.2.2.  CBOR Encoding . . . . . . . . . . . . . . . . . . . .  12
     6.3.  Backwards Compatibility . . . . . . . . . . . . . . . . .  13
     6.4.  Recommendations . . . . . . . . . . . . . . . . . . . . .  14
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  14
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  14
     8.1.  Bundle Protocol Version 7 'ipn' Scheme URI Authority
           Numbers registry  . . . . . . . . . . . . . . . . . . . .  14
     8.2.  Bundle Protocol Version 7 'ipn' Scheme URI Null Authority
           Node Numbers registry . . . . . . . . . . . . . . . . . .  15
     8.3.  Bundle Protocol Version 7 'ipn' Scheme URI Service Numbers
           registry  . . . . . . . . . . . . . . . . . . . . . . . .  17
     8.4.  CBHE Node Numbers registry  . . . . . . . . . . . . . . .  18
     8.5.  CBHE Service Numbers registry . . . . . . . . . . . . . .  18
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Appendix A.  Discussion Points  . . . . . . . . . . . . . . . . .  20
     A.1.  Why not just keep the number space sub-division as defined
           in RFC7116? . . . . . . . . . . . . . . . . . . . . . . .  20
     A.2.  Why not a new 'ipn3' EID scheme?  . . . . . . . . . . . .  20
     A.3.  Why not use just the 'dtn' scheme for
           interoperability? . . . . . . . . . . . . . . . . . . . .  21
     A.4.  Won't these changes break BPv6 compatibility? . . . . . .  21
     A.5.  Why not have an unbounded number of sub-authorities?  . .  21
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   From the earliest days of experimentation with "store and forward"
   data transfer with the Bundle Protocol there has been a need to
   identify the source and destination of a bundle.  Starting with the
   IRTF standardisation of the experimental Bundle Protocol version 6
   (BPv6) [RFC5050], a logical source or destination of bundles is
   referred to as an Endpoint, with a corresponding Endpoint Identifier
   (EID).  Rather than define yet another identifier format, the IRTF
   DTN Working Group decided to reuse the existing Universal Resource

Taylor & Birrane           Expires 11 May 2023                  [Page 3]
Internet-Draft                 ipn-update                  November 2022

   Identifier (URI) syntax defined in [RFC3986].  However, given the
   particular on-the-wire encodings of both BPv6 and BPv7, a specific
   encoding for every supported URI scheme must be specified in the
   relevant protocol specification.

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

   The acronym IPN was originally a contraction of the term
   "InterPlanetary Network" as the original aim of this scheme was to
   provide a compact namespace for an interoperable space-based DTN
   architecture, but beyond space-based applications, terrestrial nodes
   might also operate with limited power, bandwidth, and/or compute
   budget.  In all cases, concisely encoded numeric identifiers for both
   nodes and services provides processing advantages over more verbose
   naming schemes.  Therefore additional focus has been placed on the
   capabilities of the 'ipn' URI scheme for use beyond its historical
   purpose for space-based DTN architectures.

   The publication of the Bundle Protocol version 7 (BPv7) [RFC9171] has
   resulted in operational deployments of BPv7 nodes for both
   terrestrial and non-terrestrial use cases.  This includes BPv7
   networks operating over the terrestrial Internet and BPv7 networks
   operating in self-contained environments behind a shared
   administrative domain.  This growth in the number and scale of
   deployments of BPv7 DTNs has been accompanied by a growth in the
   usage of 'ipn' URI scheme endpoint identifiers, and this increased
   usage has highlighted shortcomings in the allocation strategy for
   such identifiers, as specified in [RFC7116].

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

Taylor & Birrane           Expires 11 May 2023                  [Page 4]
Internet-Draft                 ipn-update                  November 2022

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

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

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

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

   Section 4.2.5.1.2 of [RFC9171] specifies the syntax of an 'ipn'
   scheme URI, with an identical format to the specification of the
   'ipn' URI scheme syntax in Section 2.1 of [RFC6260], namely as a
   sequence of two unsigned integers.  The first number representing the
   identifier of the node (node-nbr), and the second being the
   identifier of a particular service expected at that node (service-
   nbr).

3.1.  Text Syntax

   As specified in [RFC9171], the schema-specific part of an 'ipn'
   scheme URI must comply with the following ABNF [RFC5234] syntax,
   including the core ABNF syntax rule for DIGIT defined by that
   specification:

   ipn-uri = "ipn:" ipn-hier-part

   ipn-hier-part = node-nbr nbr-delim service-nbr

   node-nbr = 1*DIGIT

   nbr-delim = "."

   service-nbr = 1*DIGIT

Taylor & Birrane           Expires 11 May 2023                  [Page 5]
Internet-Draft                 ipn-update                  November 2022

3.2.  CBOR Encoding

   As specified in [RFC9171], a BPv7 endpoint identified by an 'ipn'
   scheme URI, when encoded in Concise Binary Object Representation
   (CBOR) [RFC8949], must comply with the following Concise Data
   Definition Language (CDDL) [RFC8610] specification:

   eid = $eid .within eid-structure

   eid-structure = [
     uri-code: uint,
     SSP: any
   ]

   ; ... Syntax for uri-code 1 (dtn scheme) omitted ...

   $eid /= [
     uri-code: 2,
     SSP: [
       nodenum: uint,
       servicenum: uint
     ]
   ]

   Because the encoding of node-nbr and service-nbr (specified in the
   CDDL as nodenum and servicenum) are defined as CBOR uint types, both
   values are restricted by this encoding to a range of [0 .. 2^64-1].

3.3.  Node and Service Numbers

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

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

   The only service that is required to exist for BPv7, as described in
   Section 4.2.5.1.2 of [RFC9171], is the "administrative endpoint" of a
   node.  This service is used as the destination for administrative

Taylor & Birrane           Expires 11 May 2023                  [Page 6]
Internet-Draft                 ipn-update                  November 2022

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

3.4.  Allocation Ranges

   Section 4.2.5.2 of [RFC9171] introduces the concept of the globally
   unique Node ID of a particular BPv7 node, specifically stating that
   it must be the Singleton EID of the administrative endpoint of the
   node.  When using a 'ipn' scheme URI as an EID, the value of the
   service-nbr component of the URI may be reused between the EIDs of
   services on different nodes.  This means that in order for an 'ipn'
   scheme URI to be used as a Node ID, the node-nbr component must be
   globally unique within a single interoperating DTN.  This uniqueness
   constraint means that all the node-nbr values must be allocated from
   a single, global namespace.

   The reliance on such a namespace is not problematic when deploying a
   private, self-contained network: If there are few nodes that can ever
   intercommunicate, then those nodes can have node-nbr values allocated
   by the administrator of that network, and there will be no problem
   with uniqueness coming from a serialized, central authority.
   However, as the number of nodes and number of administrative
   authorities in a network scale, the administrative burden of
   assigning unique node-nbr values increases.  A potential solution to
   this, as described in Section 3.2.1 of [RFC7116], is to pre-assign
   ranges of node-nbr values to different authorities, from which they
   can independently allocate values without risk of duplication.

   This division of the number space is an adequate solution for the
   uniqueness problem, but it introduces a new issue: The encoding-
   length of each node-nbr is no longer minimal, as the offset to the
   start of the range assigned to the allocating authority is included
   in each node-nbr value assigned by that authority.  For example:
   Section 3.2.1 of [RFC7116] allocates [CCSDS] the range [2^14 ..
   2^21-1] for node-nbr values for use with BPv6, and if CCSDS choses to
   continue to use this number range for BPv7, the CBOR encoding of
   every 'ipn' scheme URI will be at least 7 octets (including 2 octets
   for the outer array with uri scheme discriminator type code), even
   when interoperability is not required:

Taylor & Birrane           Expires 11 May 2023                  [Page 7]
Internet-Draft                 ipn-update                  November 2022

   82            # array(2)
      02         # uri-code: 2
      82         # array(2)
         19 4000 # node-nbr: 16384
         00      # service-nbr: 0

   Another side-effect of assigning ranges of a single number space to
   different sub-allocating authorities is to reduce the total
   availability of node-nbr values.  Although the current allocation
   strategy defined in [RFC7116] leaves approximately 2^42 numbers
   unallocated, the recommendation to IANA is that these numbers should
   be allocated in blocks of 2^14.  The history of IPv4 address
   allocation, see Section 2.1 of [RFC1287], demonstrates that
   exhaustion of a 2^32 bit number space happens surprisingly quickly.

4.  Updates to RFC9171

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

4.1.  'ipn' URI Scheme Node Numbers for BPv7

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

   1.  The value of the node-nbr component of an 'ipn' scheme URI MUST
       be an unsigned integer greater than or equal to zero (0).

   2.  The URI "ipn:0.0" is assigned to the 'null' endpoint, see
       Section 3.2 of [RFC9171].

   3.  The value zero (0) for the node-nbr component of an 'ipn' scheme
       URI MUST NOT be used except as part of the URI "ipn:0.0".

   4.  Values greater than or equal to 2^64 for the node-nbr component
       of an 'ipn' scheme URI MUST NOT be used, to allow concise
       unsigned integer (type 0) CBOR encoding.

   5.  All 'ipn' scheme URIs for endpoints co-located on a single bundle
       processing node MUST share the same value for the node-nbr
       component.

4.2.  'ipn' URI Scheme Service Numbers for BPv7

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

Taylor & Birrane           Expires 11 May 2023                  [Page 8]
Internet-Draft                 ipn-update                  November 2022

   1.  The value of the service-nbr component of an 'ipn' scheme URI
       MUST be an unsigned integer greater than or equal to zero (0).

   2.  The value of the service-nbr component of an 'ipn' scheme URI of
       the EID of an administrative endpoint, as defined in Section 3.2
       of [RFC9171], MUST be zero (0).

   3.  Values greater than or equal to 2^64 for the service-nbr
       component of an 'ipn' scheme URI MUST NOT be used, to allow
       concise unsigned integer (type 0) CBOR encoding.

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

5.  Updates to RFC7116

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

5.1.  'ipn' URI Scheme Node Numbers for BPv6

   The "CBHE Node Numbers" registry specified in Section 3.2.1 of
   [RFC7116] is renamed without change to the "Bundle Protocol Version 6
   'ipn' Scheme URI Node Numbers" registry, to clarify that it is for
   use solely with BPv6, see IANA Considerations (Section 8).

5.2.  'ipn' URI Scheme Service Numbers for BPv6

   The "CBHE Service Numbers" registry specified in Section 3.2.2 of
   [RFC7116] is renamed without change to the "'Bundle Protocol Version
   6 'ipn' Scheme URI Service Numbers" registry, to clarify that it is
   for use solely with BPv6, see IANA Considerations (Section 8).

6.  Update to the 'ipn' URI Scheme

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

Taylor & Birrane           Expires 11 May 2023                  [Page 9]
Internet-Draft                 ipn-update                  November 2022

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

6.1.  Numbering Authorities

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

   A new IANA "Bundle Protocol Version 7 'ipn' Scheme URI Authority
   Numbers" registry is defined for the registration of Authority
   Numbers, see IANA Considerations (Section 8).  Although the
   uniqueness of Numbering Authority identifiers is required for
   interoperable DTN operations, identifier ranges are explicitly
   reserved for experimentation.

6.1.1.  Numbering Sub-authorities

   Some organisations that register as Numbering Authorities may be
   sufficiently large that acting as a single allocating authority for
   their desired number range becomes administratively untenable, for
   example government agencies.  In this case, the ability to delegate
   number allocation to sub-authorities is desired.  To address this,
   this specification introduces a Numbering Sub-authority numeric
   identifier, to be used when required, allocated from a registry
   controlled by each independent Numbering Authority.  In order to
   avoid unbounded nesting of sub-sub-authorities, making processing in
   constrained devices overly onerous, only a single level of Numbering
   Sub-authority is permitted.

Taylor & Birrane           Expires 11 May 2023                 [Page 10]
Internet-Draft                 ipn-update                  November 2022

6.2.  Prefix Encoding

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

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

   For example, the URI "ipn:2.1.0" uniquely identifies the
   administrative endpoint of the node allocated the node-nbr 1 by the
   numbering authority with identifier 2.  This URI can be concisely
   encoded in CBOR as 6 octets, including 2 octets for the outer array
   with uri-code:

   82       # array(2)
      02    # uri-code: 2
      83    # array(3)
         02 # auth-nbr: 2
         01 # node-nbr: 1
         00 # service-nbr: 0

6.2.1.  Text Syntax

   The text syntax of an 'ipn' scheme URI MUST comply with the following
   ABNF [RFC5234] syntax, including the core ABNF syntax rule for DIGIT
   defined by that specification:

Taylor & Birrane           Expires 11 May 2023                 [Page 11]
Internet-Draft                 ipn-update                  November 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 = number

   sub-auth-nbr = number

   node-nbr = number

   service-nbr = number

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

   nbr-delim = "."

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

6.2.2.  CBOR Encoding

   A BPv7 endpoint identified by an 'ipn' scheme URI, when encoded in
   Concise Binary Object Representation (CBOR) [RFC8949], MUST comply
   with the following Concise Data Definition Language (CDDL) [RFC8610]
   specification:

Taylor & Birrane           Expires 11 May 2023                 [Page 12]
Internet-Draft                 ipn-update                  November 2022

   eid = $eid .within eid-structure

   eid-structure = [
     uri-code: uint,
     SSP: any
   ]

   ; ... Syntax for other uri-code values defined in RFC9171 ...

   $eid /= [
     uri-code: 2,
     SSP: [
       ? authority,
       node-nbr: uint,
       service-nbr: uint
     ]
   ]

   authority = (
     auth-nbr: uint,
     ? sub-auth-nbr: uint
   )

   Because the encoding of auth-nbr, sub-auth-nbr, node-nbr, and
   service-nbr are defined as CBOR uint types, all values are restricted
   by this encoding to a range of [0 .. 2^64-1].

6.3.  Backwards Compatibility

   Although this update to the 'ipn' URI scheme introduces the ability
   to include Numbering Authority identifiers, it does not prohibit the
   use of 'ipn' scheme URIs without such an identifier.  To maintain
   this useful capability, a new IANA "Bundle Protocol Version 7 'ipn'
   Scheme URI Null Authority Node Numbers" registry is defined to
   control the allocation of values for the node-nbr component of 'ipn'
   scheme URIs without a auth-nbr component, when used as EIDs with
   BPV7.  This new registry inherits behaviours and existing assignments
   from the IANA "CBHE Node Numbers" registry, reserves the value zero
   (0), and assigns values in the range [1 .. 2^14-1] as "Private Use",
   as defined in [RFC8126].

   Use of an 'ipn' scheme URI with a "Private Use" value for the node-
   nbr component without an auth-nbr component as an EID with BPv7
   removes any guarantee of uniqueness.  Such EIDs must be considered
   'non-routeable' to the extent that they MUST NOT be permitted to exit
   a single administrative domain.  They can be considered to be
   equivalent to "Private Address Space" IPv4 addresses, as defined in
   [RFC1918].

Taylor & Birrane           Expires 11 May 2023                 [Page 13]
Internet-Draft                 ipn-update                  November 2022

6.4.  Recommendations

   [RFC9171] mandates the concept of "late binding" of an EID, where-by
   the address of the destination of a bundle is resolved from its
   identifier hop by hop as it transits a DTN.  This per-hop binding of
   identifiers to addresses underlines the fact that EIDs are purely
   names, and should not carry any implicit or explicit information
   concerning the current location or reachability of an identified node
   and service.  This removes the need to rename a node as its location
   changes.

   Because of this late binding concept, the authority components of an
   'ipn' scheme URI SHOULD NOT be regarded as some kind of "type field",
   and used to derive additional information from the other components
   of the URI.  An example of incorrect behaviour would be: "I know
   authority X allocates node-nbr values derived from the link-layer
   address of some device on each node, and so I can just send packets
   directly to that link-layer address".  No matter the authority that
   controls the allocation of node-nbr values, they remain just numbers,
   without additional meaning.

7.  Security Considerations

   *TODO*

8.  IANA Considerations

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

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

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

   The registration policy for this registry is:

Taylor & Birrane           Expires 11 May 2023                 [Page 14]
Internet-Draft                 ipn-update                  November 2022

   +================+=========================+
   |     Range      | Registration Policy     |
   +================+=========================+
   |       0        | Reserved                |
   +----------------+-------------------------+
   |  1 .. 2^32-1   | First Come First Served |
   +----------------+-------------------------+
   | 2^32 .. 2^64-1 | Experimental Use        |
   +----------------+-------------------------+
   |    >= 2^64     | Reserved                |
   +----------------+-------------------------+

     Table 1: Bundle Protocol Version 7 'ipn'
           Scheme URI Authority Numbers
              registration policies

   The initial values for the registry are:

   +=======+=============+==========================================+
   | Value | Description | Reference                                |
   +=======+=============+==========================================+
   |   1   | Allocated   | To be defined - pre-allocated as a       |
   |       | to [CCSDS]  | courtesy, as they have an existing       |
   |       |             | allocation in Section 3.2.1 of [RFC7116] |
   +-------+-------------+------------------------------------------+

     Table 2: Bundle Protocol Version 7 'ipn' Scheme URI Authority
                         Numbers initial values

8.2.  Bundle Protocol Version 7 'ipn' Scheme URI Null Authority Node
      Numbers registry

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

   The registration policy for this registry is:

Taylor & Birrane           Expires 11 May 2023                 [Page 15]
Internet-Draft                 ipn-update                  November 2022

   +================+================================+
   |     Range      | Registration Policy            |
   +================+================================+
   |       0        | Reserved                       |
   +----------------+--------------------------------+
   |  1 .. 2^14-1   | Private Use                    |
   +----------------+--------------------------------+
   | 2^14 .. 2^42-1 | First Come First Served        |
   |                | requests for up to 2^14 values |
   +----------------+--------------------------------+
   | 2^14 .. 2^42-1 | Expert Review requests for     |
   |                | more than 2^14 values          |
   +----------------+--------------------------------+
   | 2^42 .. 2^64-1 | Experimental Use               |
   +----------------+--------------------------------+
   |    >= 2^64     | Reserved                       |
   +----------------+--------------------------------+

     Table 3: Bundle Protocol Version 7 'ipn' Scheme
       URI Null Authority Node Numbers registration
                         policies

   The initial values for the registry are:

Taylor & Birrane           Expires 11 May 2023                 [Page 16]
Internet-Draft                 ipn-update                  November 2022

   +=====================+===========================+================+
   |        Value        | Description               | Reference      |
   +=====================+===========================+================+
   |    16384-2097151    | Allocated to the Space    | Inherited from |
   |                     | Assigned Numbers          | [RFC7116]      |
   |                     | Authority (SANA) for use  |                |
   |                     | by Consultative Committee |                |
   |                     | for Space Data Systems    |                |
   |                     | (CCSDS) missions.         |                |
   +---------------------+---------------------------+----------------+
   | 268435456-268451839 | Allocated to Spacely      | Scott Johnson  |
   |                     | Packets, LLC to provide   | - see existing |
   |                     | IPN/IP Gateway services   | allocation in  |
   |                     | to private sector         | CBHE Node      |
   |                     | stakeholders.             | Numbers        |
   |                     |                           | registry.      |
   +---------------------+---------------------------+----------------+
   | 268451840-268468223 | Allocated to SPATIAM      | Alberto        |
   |                     | CORPORATION to provide    | Montilla - see |
   |                     | DTN services to           | existing       |
   |                     | organizations.            | allocation in  |
   |                     |                           | CBHE Node      |
   |                     |                           | Numbers        |
   |                     |                           | registry.      |
   +---------------------+---------------------------+----------------+

         Table 4: Bundle Protocol Version 7 'ipn' Scheme URI Null
                  Authority Node Numbers initial values

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

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

   The registration policy for this registry is:

Taylor & Birrane           Expires 11 May 2023                 [Page 17]
Internet-Draft                 ipn-update                  November 2022

   +================+========================+
   |     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 5: Bundle Protocol Version 7
         'ipn' Scheme URI Service Numbers
              registration policies

   The initial values for the registry are:

   +=======+=============================+===============+
   | Value | Description                 | Reference     |
   +=======+=============================+===============+
   |   0   | The administrative endpoint | This document |
   +-------+-----------------------------+---------------+

     Table 6: Bundle Protocol Version 7 'ipn' Scheme URI
                Service Numbers initial values

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

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

9.  References

9.1.  Normative References

Taylor & Birrane           Expires 11 May 2023                 [Page 18]
Internet-Draft                 ipn-update                  November 2022

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

   [RFC6260]  Burleigh, S., "Compressed Bundle Header Encoding (CBHE)",
              RFC 6260, DOI 10.17487/RFC6260, May 2011,
              <https://www.rfc-editor.org/rfc/rfc6260>.

   [RFC7116]  Scott, K. and M. Blanchet, "Licklider Transmission
              Protocol (LTP), Compressed Bundle Header Encoding (CBHE),
              and Bundle Protocol IANA Registries", RFC 7116,
              DOI 10.17487/RFC7116, 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>.

9.2.  Informative References

   [CCSDS]    "The Consultative Committee for Space Data Systems",
              <http://www.ccsds.org>.

Taylor & Birrane           Expires 11 May 2023                 [Page 19]
Internet-Draft                 ipn-update                  November 2022

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

   [RFC1340]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340,
              DOI 10.17487/RFC1340, July 1992,
              <https://www.rfc-editor.org/rfc/rfc1340>.

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

   [RFC5050]  Scott, K. and S. Burleigh, "Bundle Protocol
              Specification", RFC 5050, DOI 10.17487/RFC5050, November
              2007, <https://www.rfc-editor.org/rfc/rfc5050>.

Appendix A.  Discussion Points

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

A.1.  Why not just keep the number space sub-division as defined in
      RFC7116?

   See Allocation Ranges (Section 3.4).

A.2.  Why not a new 'ipn3' EID scheme?

   Is there really any difference in outcome between the following
   cases?:

   1.  An existing parser receives a bundle with an EID with a 3-ary ipn
       EID

   2.  An existing parser receives a bundle with an EID with an
       unrecognised scheme identifier

Taylor & Birrane           Expires 11 May 2023                 [Page 20]
Internet-Draft                 ipn-update                  November 2022

   In the former case, the parser will recognised the scheme as 'ipn'
   but then fail as the dimension of the subsequent array is not 2.  In
   the latter case the parser will fail one octet earlier when the
   scheme is not recognised.  In both cases, the EID will not be
   recognised as valid, forwarding will be "contraindicated", and the
   process described in Step 2 of Section 5.4 of [RFC9171] should be
   followed.

   It is believed that introducing a new EID scheme will just result in
   fragmentation of support.  'ipn' is popular because it is simple;
   let's not introduce another 'simple' EID scheme to compete with it,
   but rather add just enough support for universal interoperability.
   'ipn' as defined in RFC9171 needs clarification, so why not just add
   the tweaks necessary as long as we don't break back-compatibility?

A.3.  Why not use just the 'dtn' scheme for interoperability?

   Because the 'dtn' scheme definition in RFC9171 is intentionally left
   wide open for further work.  That work has yet to happen and is a
   considered a much more complex task than a simple update to the 'ipn'
   scheme.

A.4.  Won't these changes break BPv6 compatibility?

   Because of the difference in encoding between BPv6 and BPv7, there is
   no on-the-wire compatibility between the versions.  Any 'dual-stack'
   gateway BPA is going to have to encapsulate BPv6 in BPv7 (or vice-
   versa), so the EID of the decapsulating endpoint will have to be used
   in the 'envelope' bundle.  There is no way a BPv7 node can send a
   bundle to a BPv6 node directly using BPv7, so backwards compatibility
   of EIDs between protocol versions is not needed.

A.5.  Why not have an unbounded number of sub-authorities?

   It's possible to encode, and has been considered by the authors, but
   the conclusion was:

   ipn:it.is.really.not.a.great.idea.to.have.unbounded.sequences.of.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.

Taylor & Birrane           Expires 11 May 2023                 [Page 21]
Internet-Draft                 ipn-update                  November 2022

Authors' Addresses

   Rick Taylor
   Ori Industries
   Email: rick.taylor@ori.co

   Ed Birrane
   JHU/APL
   Email: Edward.Birrane@jhuapl.edu

Taylor & Birrane           Expires 11 May 2023                 [Page 22]