RFC 9758

Updates to the 'ipn' URI Scheme

📅 published May 2025, from ietf

Updates to the 'ipn' URI Scheme 🦋

  • RFC number: 9758 💖
  • Authors: R. Taylor (Aalyria Technologies) and E. Birrane, III (JHU/APL) 👑
  • Category: Standards Track, so this is official Internet protocol business 💅
  • Date: May 2025 🌸
  • Updates: RFC 6260, RFC 7116, and RFC 9171 ✨
  • ISSN: 2070-1721

Okay bestie, this RFC is a glow-up for the ipn URI scheme. It improves the scheme that RFC 6260 defined, updates the IANA registries from RFC 7116, and changes how these URIs get encoded and decoded as Endpoint Identifiers (EIDs) in BPv7 (RFC 9171). 🧚

Abstract ✨

Okay so this document updates the ipn URI scheme that was first defined in RFC 6260, plus the IANA registries that RFC 7116 set up. 💅 It also updates the rules for encoding and decoding these URIs when they're used as an Endpoint Identifier (EID) in Bundle Protocol version 7 (BPv7), which is defined in RFC 9171. The vibe is clarity: the structure and behavior of the ipn scheme get spelled out, there are new encodings for ipn scheme URIs, and the registries needed to manage the whole thing get established. Iconic. 🎀

Status of This Memo 🌈

This is an Internet Standards Track document. 💖

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). For more info on Internet Standards, check out Section 2 of RFC 7841. ✨

If you want the current status, any errata, or a way to send feedback on this document, go to https://www.rfc-editor.org/info/rfc9758. 🫶

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. 🌸

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at https://trustee.ietf.org/license-info. These are the rules in effect on the date this document was published. Read them carefully, bestie, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as the Revised BSD License describes. 🙈

Table of Contents 🧚

   1.  Introduction
   2.  Conventions and Definitions
   3.  Core Concepts
     3.1.  The Null ipn URI
     3.2.  Allocator Identifiers
       3.2.1.  Allocator Identifier Ranges
       3.2.2.  The Default Allocator
     3.3.  Node Numbers
       3.3.1.  Fully Qualified Node Numbers
     3.4.  Special Node Numbers
       3.4.1.  The Zero Node Number
       3.4.2.  LocalNode ipn URIs
       3.4.3.  Private Use Node Numbers
     3.5.  Service Numbers
   4.  Textual Representation of ipn URIs
     4.1.  'ipn' URI Scheme Text Syntax
   5.  Usage of ipn URIs with BPv7
     5.1.  Uniqueness Constraints
     5.2.  The Null Endpoint
     5.3.  BPv7 Node ID
     5.4.  LocalNode ipn EIDs
     5.5.  Private Use ipn EIDs
     5.6.  Well-Known Service Numbers
     5.7.  Administrative Endpoints
   6.  CBOR Representation of ipn URIs with BPv7
     6.1.  ipn EID CBOR Encoding
       6.1.1.  Two-Element Scheme-Specific Encoding
       6.1.2.  Three-Element Scheme-Specific Encoding
     6.2.  ipn EID CBOR Decoding
     6.3.  'ipn' URI Scheme CBOR Syntax
     6.4.  ipn EID Matching
   7.  Special Considerations
     7.1.  Scheme Compatibility
     7.2.  CBOR Representation Interoperability
     7.3.  Text Representation Compatibility
     7.4.  Bundle Protocol Version 6 Compatibility
     7.5.  Late Binding
   8.  Security Considerations
     8.1.  Reliability and Consistency
     8.2.  Malicious Construction
     8.3.  Back-End Transcoding
     8.4.  Local and Private Use ipn EIDs
     8.5.  Sensitive Information
     8.6.  Semantic Attacks
   9.  IANA Considerations
     9.1.  'ipn' Scheme URI Allocator Identifiers Registry
       9.1.1.  Guidance for Designated Experts
     9.2.  'ipn' Scheme URI Default Allocator Node Numbers Registry
     9.3.  'ipn' Scheme URI Well-Known Service Numbers for BPv7
           Registry
       9.3.1.  Guidance for Designated Experts
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Appendix A.  'ipn' URI Scheme Text Representation Examples
     A.1.  Using the Default Allocator
     A.2.  Using a Non-Default Allocator
     A.3.  The Null ipn URI
     A.4.  The LocalNode ipn URI
   Appendix B.  'ipn' URI Scheme CBOR Encoding Examples
     B.1.  Using the Default Allocator
     B.2.  Using a Non-Default Allocator
     B.3.  The Null Endpoint
   Acknowledgments
   Authors' Addresses

1. Introduction 🌸

Okay, the ipn URI scheme started out in RFC 6260 and RFC 7116 as a way to identify network nodes and the services on them. The trick is that it uses concisely encoded integers, which get processed faster and need fewer resources than other verbose identifier schemes. 🧠 It was designed for the experimental Bundle Protocol version 6 (BPv6) from RFC 5050, and "IPN" was originally an acronym for "InterPlanetary Network," because the plan was deep-space networking. 🚀 Since then, the efficiency of integer identifiers has made ipn scheme URIs useful for any network that's working with limited power, bandwidth, and/or compute budget. So "IPN" is now used as a non-acronymous name. Main character energy. ✨

Similar to the experimental BPv6, the standardized Bundle Protocol version 7 (BPv7) from RFC 9171 officially supports using the ipn URI scheme to specify bundle Endpoint Identifiers (EIDs). 💅 BPv7 is now running in real deployments, both for terrestrial and non-terrestrial use cases. That includes BPv7 networks running over the terrestrial Internet, and BPv7 networks running in self-contained environments inside a shared administrative domain. 🌈 As the number and scale of these deployments grew, so did the use of the ipn URI scheme, which made it clear that the structure, moderation, and management of the scheme needed some love. 🫶

By updating RFC 7116 and RFC 9171 (which is what [RFC7116] and [RFC9171] mean here), this document updates the ipn URI scheme spec in a backwards-compatible way. 🎀 The goal is to add the improvements the scheme needs, both in the scheme itself and in how it's used to specify EIDs with BPv7. Specifically, this document:

  • introduces a hierarchical structure for the assignment of 'ipn' scheme URIs,
  • clarifies the behavior and interpretation of 'ipn' scheme URIs,
  • defines efficient encodings of 'ipn' scheme URIs, and
  • updates/defines the registries associated with this scheme.

Originally, the deep-space community built the ipn URI scheme for the Bundle Protocol, but it's generic enough to work in other environments where you need a concise, unique representation of a resource on a particular node. 🦋

Remember, bestie: like most other URI schemes, the ipn URI scheme defines a unique identifier for a resource. It does NOT include any topological information about how to route messages to that resource. Routing is a whole different party. 🙈

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 rest of this document, the term "ipn URI" refers to a URI that uses the 'ipn' URI scheme. 🍓

3. Core Concepts 💅

Every ipn URI MUST be considered as a tuple of the following three components, no matter whether it's written as text or encoded in binary: ✨

  • The Allocator Identifier
  • The Node Number
  • The Service Number

The Allocator Identifier tells you which entity is responsible for assigning Node Numbers to individual resource nodes. This keeps everything unique without needing one single registry for all the assigned Node Numbers. See Section 3.2. 👑

The Node Number is a shared identifier given to all ipn URIs for resources that live together on a single node. See Section 3.3. 🌸

The Service Number is an identifier that tells apart the resources on a given node. See Section 3.5. 🧚

Put these three together and every correctly built ipn URI uniquely identifies a single resource. 🎀 And the Allocator Identifier plus the Node Number gives you a way to uniquely identify the node where a particular resource is expected to exist. See Section 3.3.1. Slay. 💖

3.1. The Null ipn URI 🌙

There's real value in defining a unique Null ipn URI that means "nowhere." 🙈 It's called the "Null ipn URI," and all three components (the Allocator Identifier, Node Number, and Service Number) are set to the value zero (0). No resource identified by the Null ipn URI exists, so any destination identified by it is, by definition, unreachable. Not it. 💀

3.2. Allocator Identifiers 🦋

An Allocator is any organization that wants to assign Node Numbers for use with the 'ipn' URI scheme, and that has the facilities and governance to manage a public registry of the assigned Node Numbers. 🏢 The authority to assign these numbers comes from IANA, which gives them an Allocator Identifier. No matter what else an Allocator has going on (like a name, point of contact, or other identifying info), Allocators are identified by their Allocator Identifiers: unique, unsigned integers in the range 0 to 2^(32-1). 🔢

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

There's a new IANA registry, "'ipn' Scheme URI Allocator Identifiers", for registering Allocator Identifiers. See Section 9.1. Uniqueness of Allocator Identifiers is required to enforce uniqueness of ipn URIs, and some identifiers are explicitly reserved for experimentation or future use. 🧪

Each Allocator assigns Node Numbers according to its own policies, without risking an identical ipn URI, as long as it follows the rules in Section 3.3. Other than making sure the Node Numbers it allocates are unique among all the Node Numbers it assigns, an Allocator doesn't need to coordinate its allocations with other Allocators. Independent queen behavior. 👑✨

If a system doesn't need interoperable deployment of 'ipn' scheme URIs, then the Private Use Node Numbers range (Section 3.4.3) is to be used. That range is reserved by the Default Allocator (Section 3.2.2) for exactly this purpose. 🌈

3.2.1. Allocator Identifier Ranges ✨

okay so some orgs have big internal hierarchies (think a company with a bunch of departments 💼), and they might want to hand off Node Number allocation to their sub-orgs. Instead of giving each sub-org a random Allocator Identifier first-come-first-served, there are real operational perks to assigning them in a structured way. That way an outside observer can tell a group of Allocator Identifiers belongs to the same org. iykyk 🫶

An Allocator Identifier range is a set of consecutive Allocator Identifiers that all belong to the same Allocator. Each individual Allocator Identifier in a range SHOULD be assigned to a distinct sub-organization of the Allocator. Doing it this way lets outside observers link individual Allocator Identifiers to one org AND tell the sub-orgs apart. main character organizing 👑

This whole vibe is inspired by CIDR (Classless Inter-Domain Routing) address assignment from [RFC4632]. In CIDR, an org (like an ISP) gets a network prefix, and every address sharing that prefix is considered part of that org 🌐

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

Allocator Identifier ranges differ from CIDR addresses in two big 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.

To tell ranges apart with efficient bitwise operations, all ranges MUST be of a size S that is a power of 2, and for a given range of length N bits, with S = 2^N, the least-significant N bits of the first Allocator Identifier MUST be all 0. 🧮

Here's an example with four orgs (A, B, C, and D):

 +==============+=============+=============+=====================+
 | Organization | Range (dec) | Range (hex) | Range Length (Bits) |
 +==============+=============+=============+=====================+
 | Org A        | 974848 ..   | 0xEE000 ..  | 7 bits              |
 |              | 974975      | 0xEE07F     |                     |
 +--------------+-------------+-------------+---------------------+
 | Org B        | 974976 ..   | 0xEE080 ..  | 4 bits              |
 |              | 974991      | 0xEE08F     |                     |
 +--------------+-------------+-------------+---------------------+
 | Org C        | 974992 ..   | 0xEE090 ..  | 1 bit               |
 |              | 974993      | 0xEE091     |                     |
 +--------------+-------------+-------------+---------------------+
 | Org D        | 974994      | 0xEE092     | 0 bits              |
 +--------------+-------------+-------------+---------------------+

       Table 1: Allocator Identifier Range Assignment Example

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

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 "CBHE Node Numbers" registry. So all ipn URIs created before Allocator Identifiers were added are assumed to have Node Number allocations that comply with the "CBHE Node Numbers" registry 📜

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

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

3.3. Node Numbers

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

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

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

3.3.1. Fully Qualified Node Numbers

One of the big perks of ipn URIs is being able to split the identity of a particular service from the node it lives on. For example, a message received from one particular ipn URI may need a response sent to a different service on the same node that sent the original message. Historically, the identifier of the sending node has been colloquially called the "node number" or "node identifier". 🧚

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

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

3.4. Special Node Numbers

Some special-case Node Numbers are defined by the Default Allocator; see 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.

⚠️ Zero Node Number plus non-zero Service Number = invalid. Do not compose these. Processors must treat 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. This form of ipn URI is termed a "LocalNode ipn URI".

3.4.3. Private Use Node Numbers

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

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

Because of this lack of uniqueness, any implementation of a protocol using ipn URIs that resides on the border between administrative domains MUST have suitable mechanisms in place to prevent protocol units using such Private Use Node Numbers from crossing between different administrative domains. 🛡️

3.5. Service Numbers

A Service Number is an unsigned integer that identifies a particular service operating on a node. A service in this case is some logical function that requires its own resource identifier to distinguish it from other functions operating on the same node. 🧩

4. Textual Representation of ipn URIs ✨

All 'ipn' scheme URIs comply with [RFC3986] and are therefore represented by a scheme identifier and a scheme-specific part. The scheme identifier is ipn, and the scheme-specific parts are represented as a sequence of numeric components separated with the '.' character. A formal definition is provided below (see Section 4.1), and it can be informally considered as:

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

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

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

Examples of the textual representation of ipn URIs can be found in Appendix A. 🍓

4.1. 'ipn' URI Scheme Text Syntax

The text syntax of an ipn URI MUST comply with the following ABNF syntax from [RFC5234], and it repeats the core ABNF syntax rule for DIGIT defined by that specification:

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

ipn-hier-part = fqnn "." service-number

fqnn = "!" / allocator-part

allocator-part = [allocator-identifier "."] node-number

allocator-identifier = number

node-number = number

service-number = number

number = "0" / non-zero-number

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

DIGIT = %x30-39

5. Usage of ipn URIs with BPv7

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

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

5.1. Uniqueness Constraints 🔐

Okay bestie, rule number one: an ipn EID MUST identify a singleton endpoint 💅. The bundle processing node that is the sole member of that endpoint MUST be the node identified by the FQNN (Section 3.3.1) of the node.

A single bundle processing node MAY have multiple ipn EIDs attached to it 🦋. Still, every ipn EID that shares any one FQNN MUST point at the same bundle processing node. No drama allowed 🙅‍♀️

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

5.2. The Null Endpoint 🫥

Section 3.2 of [RFC9171] is where the Null endpoint lives. It's an endpoint with zero members, and it's identified by a special Null EID. Very minimalist, very mysterious 🖤

Inside the ipn URI scheme, that Null EID gets written as the Null ipn URI (Section 3.1). So dtn:none (Section 4.2.5.1.1 of [RFC9171]), ipn:0.0, and ipn:0.0.0 all refer to the BPv7 Null endpoint. Three names, one vibe 🌸

5.3. BPv7 Node ID 🪪

Section 4.2.5.2 of [RFC9171] brings in the idea of a "Node ID". It looks exactly like an EID and it uniquely identifies a bundle processing node, so it's basically that node's ID card 💖

Any ipn EID can work as a "Node ID" for the bundle processing node identified by its FQNN (Section 3.3.1). So any ipn EID shaped like 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). It's giving "one identity, many outfits" 👗

5.4. LocalNode ipn EIDs 🏠

When a LocalNode ipn URI (Section 3.4.2) gets used as a BPv6 or BPv7 EID, it's officially called a "LocalNode ipn EID" 🧚

Here's the tea: a LocalNode ipn EID only means something on the local bundle node, so it MUST be considered non-routable 🚫. That means any bundle using one as a bundle source or bundle destination MUST NOT be allowed to leave the local node. And the flip side is that any externally received bundle featuring LocalNode EIDs as a bundle source or bundle destination MUST be discarded as invalid. Bye bye 👋

LocalNode ipn EIDs MUST NOT be present in any other part of a bundle that gets transmitted off of the local node. For example, a LocalNode ipn EID MUST NOT be used as a Bundle Protocol Security (BPSec) [RFC9172] security source for a bundle sent out from the local bundle node, because that source EID would mean absolutely nothing to a downstream bundle node 🙈

LocalNode ipn EIDs MUST NOT be published in any node identification directory (like a DNS registration) or shown as part of dynamic peer discovery, since the EID has no valid meaning for other nodes. For example, a LocalNode ipn EID MUST NOT be advertised as the peer Node ID during session negotiation in [RFC9174]. Keep it local, babe 🤫

5.5. Private Use ipn EIDs 🕵️‍♀️

Bundles headed for EIDs that use an ipn URI with an FQNN (Section 3.3.1) inside the Private Use range of the Default Allocator (Section 3.2.2) are not universally unique. So they're only valid inside the current administrative domain, like a secret club with a very strict guest list 🎀

That means any bundle using a Private Use ipn EID as a bundle source or bundle destination MUST NOT be allowed to cross administrative domains. Every implementation that could be deployed as a gateway between administrative domains MUST be configurable enough to make sure this gets enforced, and operators MUST ensure correct configuration. Not optional, not a vibe check, a whole requirement 😤

Private Use ipn EIDs MUST NOT be present in any other part of a bundle that is destined for another administrative domain when the lack of uniqueness would break correct operation. For example, a Private Use ipn EID MUST NOT be used as a BPSec [RFC9172] security source for a bundle when that bundle is headed to a different administrative domain 🚧

5.6. Well-Known Service Numbers 🌈

It's super convenient when BPv7 services that have a public specification and wide adoption get identified by a pre-agreed default Service Number 💜. Unless someone explicitly overrides it in configuration, these services can be sensibly assumed to be running on the well-known Service Number on a particular node. Predictable and cute 🥰

If a different service uses that number, or the service uses a different number, BPv7 will keep on operating. Some configuration might be needed to get the individual service working though, so don't panic 🫶

A new IANA registry, "'ipn' Scheme URI Well-Known Service Numbers for BPv7", is defined for registering well-known BPv7 Service Numbers; see Section 9.3. This registry records which Service Numbers belong to well-known services, and it also explicitly reserves ranges for both experimentation and Private Use. Organized queen behavior 👑

5.7. Administrative Endpoints 🛎️

The service identified by a Service Number of zero (0) MUST be interpreted as the Administrative Endpoint of the node, as defined in Section 3.2 of [RFC9171]. Zero is the VIP slot 🏆

Non-zero Service Numbers MUST NOT be used to identify the Administrative Endpoint of a bundle node in an ipn EID. So don't try to sneak in a different number and call it admin, it won't work 💅

6. CBOR Representation of ipn URIs with BPv7 🎁

Section 4.2.5.1 of [RFC9171] says that any URI scheme used to represent BPv7 EIDs MUST define how its scheme-specific part gets encoded with Concise Binary Object Representation (CBOR) [RFC8949]. To meet that requirement, this section explains the CBOR encoding and decoding approach for ipn EIDs. The formal definition of the CBOR representation is in Section 6.3, so stick around for that 🧠

6.1. ipn EID CBOR Encoding 🧁

Generic URI approaches to encoding ipn EIDs probably won't be efficient, because they ignore the underlying structure of the ipn URI scheme. The ipn scheme was built for concise identification and rapid processing, so the encoding keeps those properties front and center ⚡

Fundamentally, ipn EIDs from [RFC9171] are represented as a sequence of identifiers. In text syntax, the numbers are separated by the . delimiter. In CBOR, that ordered series of numbers can be represented by an array. So when encoding ipn EIDs for 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. Clean and structured, like a perfectly organized closet 🗄️

The two-element and three-element encodings each have their own structure and mechanism, which we'll break down below. Examples of the different encodings are in Appendix B 📚

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 FQNN (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 built like this:

  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 ipn:977000.100.1 has an FQNN of (977000,100), which would be encoded as 0xEE868_00000064. The resulting two-element array [0xEE868_00000064, 0x01] would be encoded in CBOR as the following 11-octet sequence:

82                        # 2-Element Endpoint Encoding
   02                     # uri-code: 2 ('ipn' URI scheme)
   82                     # 2-Element ipn EID encoding
      1B 000EE86800000064 # Fully Qualified Node Number
      01                  # Service Number

The two-element scheme-specific encoding keeps backwards compatibility with the encoding in Section 4.2.5.1.2 of [RFC9171]. When you use it this way, the FQNN encoding takes over from the Node Number that [RFC9171] specified. And when the Node Number is allocated by the Default Allocator (Section 3.2.2), the FQNN encoding and the [RFC9171] Node Number encoding come out identical. Full continuity, no plot holes 🫶

6.1.2. Three-Element Scheme-Specific Encoding 🦋

In the three-element scheme-specific encoding of an ipn EID:

  1. the first element of the array is the Allocator Identifier,
  2. the second element of the array is the Node Number, and
  3. the third element of the array is the Service Number.

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

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

The three-element scheme-specific encoding gives a more efficient representation of ipn EIDs using smaller Allocator Identifiers. Implementations are RECOMMENDED to use this encoding scheme unless they're explicitly mitigating interoperability issues; see Section 7.1. Efficiency queen 👑

When encoding an ipn EID that uses the Default Allocator (Section 3.2.2) with this encoding scheme, the first element of the array is the value zero (0). In that case, the equivalent two-element scheme-specific encoding (Section 6.1.1) gives a more concise CBOR representation, so it is RECOMMENDED that implementations use that encoding instead 💅

6.2. ipn EID CBOR Decoding 🔓

The presence of different scheme-specific encodings does not introduce any decoding ambiguity. No confusion, no chaos ✨

An ipn EID CBOR decoder can rebuild an ipn EID using the logic below. In this description, the term enc_eid refers to the CBOR-encoded ipn EID, and the term ipn_eid refers to the decoded ipn EID 🧐

if enc_eid.len() == 3
{
  ipn_eid.allocator_identifier := enc_eid[0];
  ipn_eid.node_number := enc_eid[1];
  ipn_eid.service_number := enc_eid[2];
}
else if enc_eid.len() == 2
{
  ipn_eid.allocator_identifier := enc_eid[0] >> 32;
  ipn_eid.node_number := enc_eid[0] & (2^(32-1));
  ipn_eid.service_number := enc_eid[1];
}

6.3. 'ipn' URI Scheme CBOR Syntax 📜

When encoded in CBOR [RFC8949], a BPv7 endpoint identified by an ipn URI MUST comply with the following Concise Data Definition Language (CDDL) [RFC8610] specification. This is the official blueprint, so bookmark it 🔖

eid = $eid .within eid-structure

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

; ... Syntax for other uri-code values defined in RFC 9171 ...

$eid /= [
  uri-code: 2,
  SSP: ipn-ssp2 / ipn-ssp3
]
ipn-ssp2 = [
  fqnn: uint,  ; packed value
  service-number: uint
]
ipn-ssp3 = [
  allocator-identifier: uint .lt 4294967296,
  node-number: uint .lt 4294967296,
  service-number: uint
]

Note: The node-number component will be the numeric representation of the concatenation of the Allocator Identifier and Node Number when the two-element encoding scheme has been used. Quick heads-up, it's a little plot twist 🌀

6.4. ipn EID Matching 🪞

No matter 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. Same EID, different outfit, still the same girl 💜

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

7. Special Considerations ✨

Okay so the ipn URI scheme is giving compact and hierarchical identification for services on network nodes 🦋 There is honestly a ton of utility in this approach. BUT implementers should totally keep the following observations in mind, especially when they're dealing with interoperability with implementations that pre-date this specification 💅

7.1. Scheme Compatibility

The ipn URI scheme update in this document keeps backwards compatibility with every ipn URI scheme going back to the provisional definition of ipn in the experimental specification "Compressed Bundle Header Encoding (CBHE)" [RFC6260] from 2011 🌸 So any ipn URI that was valid before this update came out is still a valid ipn URI. Periodt ✨

The two-element scheme-specific encoding (Section 6.1.1) is also backwards compatible with the ipn URI encoding given in [RFC9171] 🫶 Any existing implementation that complies with [RFC9171] will produce an ipn URI encoding that complies with this specification.

Now the tea: adding optional non-default Allocator Identifiers and a three-element scheme-specific encoding does NOT make this update forwards compatible 😭 Existing implementations that you want to support this update MUST be updated so they can process non-default Allocator Identifiers and three-element scheme-specific encodings. It is RECOMMENDED that BPv7 implementations upgrade to process these new features, so they can get the scalability that Allocator Identifiers provide and the encoding efficiencies of the three-element encoding 🔥

7.2. CBOR Representation Interoperability

Care must be taken when deploying implementations that default to the three-element encoding in networks that also include implementations that only support the two-element encoding [RFC9171] 💀 The existing implementations will reject bundles that use the three-element encoding as malformed, so correct forwarding of semantically valid bundles will fail. How you fix this depends on the kind of interoperability your deployment needs. Techniques can include:

  • A configuration option that tells an implementation when it must use the two-element encoding for all ipn EIDs when processing bundles destined to a given endpoint. This would be suitable when adding a newer implementation to a network of existing implementations 🍓
  • Selective bundle encapsulation, where bundles known to come from implementations that don't support the three-element encoding are tunneled across the parts of the network that require the three-element encoding. This would use specially configured "gateway nodes" to do the tunnel encapsulation and decapsulation, and it would be suitable when joining an existing network to a larger network 🧚

Techniques that do NOT mitigate the problem include:

  • Heuristic determination of the correct encoding to use when responding to a bundle, by examining the incoming bundle. It is not possible to determine whether the destination requires the two-element encoding when composing a new bundle in response to a received bundle, such as a status report. That's because ipn EIDs assigned by the Default Allocator use the two-element encoding, whether or not the implementation supports the three-element encoding 🙈
  • Transcoding bundles at intermediate nodes. [RFC9171] requires the bundle primary block to be immutable. Even if the ipn EIDs in the primary block don't need rewriting, other blocks, including the payload block, may include ipn EIDs that the transcoding node doesn't know about. Also, bundle blocks may be covered by bundle security blocks or bundle integrity blocks [RFC9172], which makes them immutable 🔒

7.3. Text Representation Compatibility

The textual representation of ipn URIs is not forwards compatible with [RFC9171] 🎀 So care must be taken when deploying implementations or tooling that use the textual representation of ipn URIs, and support for non-default Allocator Identifiers is required. For example, Section 4.6 of [RFC9174] specifies that the session initialization message "...SHALL contain the UTF-8 encoded node ID of the entity that sent the SESS_INIT message." In those cases, the considerations that apply to the three-element CBOR encoding also apply to the text representation when a non-default Allocator Identifier is present ✨

7.4. Bundle Protocol Version 6 Compatibility

This document updates the use of ipn EIDs for BPv7 🌈 However, the ipn URI scheme was originally defined for use with BPv6. This document doesn't update any of the behaviors, wire formats, or mechanisms of BPv6. So ipn EIDs with non-default Allocator Identifiers MUST NOT be used with BPv6, and the Allocator Identifier prefix MUST be omitted from any textual representation. It should be noted that BPv6 has no concept of LocalNode EIDs, so it will treat those EIDs as routable 👀

Warning, bestie: don't try to use non-default Allocator Identifiers with BPv6. It's a hard no 🚫

7.5. Late Binding

[RFC9171] mandates the concept of "late binding" of an EID 🦋 That means the address of a bundle's destination gets resolved from its identifier hop-by-hop as the bundle transits a BPv7 network. This per-hop binding of identifiers to addresses shows that EIDs are purely names and should not carry any implicit or explicit information about the current location or reachability of an identified node or service. It also means you never have to rename a node when its location changes 💖

The concept of late binding is preserved in this ipn URI scheme. Elements of an ipn URI MUST NOT be regarded as carrying information about location, reachability, or other addressing or routing concerns 🙅‍♀️

Here's an example of what NOT to do 💀 Assuming that a given Allocator assigns Node Numbers derived from link-layer addresses, and then reading the Node Number component of an ipn URI directly as a link-layer address, is incorrect behavior. No matter how an Allocator assigns Node Numbers, they remain just numbers with no additional meaning 🔢

8. Security Considerations 🔐

This section updates the security considerations from Section 4.2.5.1.2 of [RFC9171] to account for the inclusion of Allocator Identifiers in the ipn URI scheme when used with BPv7. Serious business, bestie 😤

8.1. Reliability and Consistency

None of the BPv7 endpoints identified by ipn EIDs are guaranteed to be reachable at any time. The Bundle Protocol itself never guarantees the identity of the processing entities operating on those endpoints 🥺 Verification of the signature provided by the Block Integrity Block (BIB) that targets the bundle's primary block, as defined by "Bundle Protocol Security (BPSec)" [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. In other words, a maliciously constructed ipn EID could be used to send a bundle to an endpoint that might be damaged by its arrival. Or it could be used to declare a false source for a bundle, which would cause incorrect processing at a node that receives the bundle 😱 In both cases (and honestly in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way. That can be done with BPSec [RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS [RFC9174] 🛡️

8.3. Back-End Transcoding

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

8.4. Local and Private Use ipn EIDs

Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn URIs present a risk to the stability of deployed BPv7 networks 🚨 If either type of ipn URI is allowed to propagate beyond the domain in which it is valid, the required uniqueness of ipn URIs no longer holds. A malicious node can abuse that to stop the whole network from working correctly 💔

See Sections 5.4 and 5.5 for the required behaviors that mitigate this form of abuse.

8.5. Sensitive Information

Because ipn URIs are only used to represent the numeric identities of resources, the risk of sensitive information being disclosed through interception of these URIs is minimal 🙌 Examining ipn URIs could be used to support traffic analysis. Where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that don't expose endpoint IDs, such as TCPCLv4 [RFC9174] 🕵️‍♀️

8.6. Semantic Attacks

The simplicity of the ipn URI scheme syntax minimizes the possibility of a human user misinterpreting a URI 🧠✨

9. IANA Considerations 📋

The following sections detail the creation of two new IANA registries and the renaming of an existing IANA registry under the "Uniform Resource Identifier (URI) Schemes" registry group 🍭

IANA has also updated the reference for the ipn scheme to this document in the "Uniform Resource Identifier (URI) Schemes" registry 🎉

9.1. 'ipn' Scheme URI Allocator Identifiers Registry 🎀

okay so IANA made a brand new registry called "'ipn' Scheme URI Allocator Identifiers" 💖 bestie, the registration rules use terms from [RFC8126], and they're sorted by range like a cute little planner 📋

+========================+==============+==================+
| Range                  | Registration | Note             |
|                        | Procedures   |                  |
+========================+==============+==================+
| 0..0xFFFF              | Expert       | Single Allocator |
|                        | Review       | Identifiers only |
+------------------------+--------------+------------------+
| 0x10000..0x3FFFFFFF    | Expert       |                  |
|                        | Review       |                  |
+------------------------+--------------+------------------+
| 0x40000000..0x7FFFFFFF | Experimental |                  |
|                        | Use          |                  |
+------------------------+--------------+------------------+
| 0x80000000..0xFFFFFFFF | Reserved     | Future Expansion |
+------------------------+--------------+------------------+
| >=0x100000000          | Reserved     |                  |
+------------------------+--------------+------------------+

   Table 2: Registration Procedures for the 'ipn' Scheme
             URI Allocator Identifiers Registry

So each entry in this registry links one or more Allocator Identifiers to a single organization 🫶 The organization is found through the "Name" and "Change Controller" fields. Each identified org is expected to publish a listing of the Node Numbers it has allocated, and the pointer to that listing lives in the "Reference" field ✨

Also, the "Single Allocator Identifiers only" note in the registration procedure means that, inside that range, handing out a run of consecutive Allocator Identifiers to one org is prohibited 🙅‍♀️ no hoarding the cute numbers, periodt 💅

The initial values in the registry are:

+=========+=============+===============+======+=========+==========+
|Name     |Range (dec)  |Range (hex)    |Range |Reference|Change    |
|         |             |               |Length|         |Controller|
|         |             |               |(Bits)|         |          |
+=========+=============+===============+======+=========+==========+
|Default  |0            |0x0            |0     |RFC 9758,|IETF      |
|Allocator|             |               |      |Section  |          |
|         |             |               |      |3.2.2    |          |
+---------+-------------+---------------+------+---------+----------+
|Example  |974848-978943|0xEE000-0xEEFFF|12    |RFC 9758 |IETF      |
|Range    |             |               |bits  |         |          |
+---------+-------------+---------------+------+---------+----------+

      Table 3: Initial Values in the 'ipn' Scheme URI Allocator
                         Identifiers Registry

The "Example Range" is set aside for examples in documentation and sample code 🧚

9.1.1. Guidance for Designated Experts 🔥

okay this part is important, bestie 🫶 Allocator Identifiers in BPv7 are encoded with the CBOR encoding of unsigned integers, and that means small numbers are cheaper to encode than big ones. So low-value Allocator Identifiers are lowkey the most desirable ones 👀 That's why you have to be careful when handing out ranges, so one applicant doesn't scoop up a big swathe of the highly desirable numbers and leave everyone else with scraps 💀 Designated experts are strongly recommended to get familiar with the CBOR encoding of unsigned integers in [RFC8949] 📚✨

9.2. 'ipn' Scheme URI Default Allocator Node Numbers Registry 🌸

IANA renamed the "CBHE Node Numbers" registry (defined in Section 3.2.1 of [RFC7116]) to the "'ipn' Scheme URI Default Allocator Node Numbers" registry and moved it into the "Uniform Resource Identifier (URI) Schemes" registry group 🦋 IANA also added this note to the old "CBHE Node Numbers" registry:

Note: Renamed "CBHE Node Numbers" as "'ipn' Scheme URI Default Allocator Node Numbers" and moved it to <https://www.iana.org/assignments/uri-schemes> per RFC 9758.

The registration procedures for this registry, using terms from [RFC8126], are:

+====================+=========================+
| Range              | Registration Procedures |
+====================+=========================+
| 1..0x3FFF          | Private Use             |
+--------------------+-------------------------+
| 0x4000..0xFFFFFFFE | Expert Review           |
+--------------------+-------------------------+
| >=0x100000000      | Invalid                 |
+--------------------+-------------------------+

            Table 4: Registration Procedures for the
            'ipn' Scheme URI Default Allocator Node
                        Numbers Registry

IANA registered these values in the "'ipn' Scheme URI Default Allocator Node Numbers" registry ✨

+============+===============================+===================+
| Value      | Description                   | Reference         |
+============+===============================+===================+
| 0          | Reserved for the Null ipn URI | [RFC7116] and RFC |
|            |                               | 9758, Section 3.1 |
+------------+-------------------------------+-------------------+
| 4294967295 | Reserved for LocalNode ipn    | RFC 9758,         |
|            | URIs                          | Section 3.4.2     |
+------------+-------------------------------+-------------------+

  Table 5: New Values in the 'ipn' Scheme URI Default Allocator
                      Node Numbers Registry

And since IANA only renamed this registry, every existing registration sticks around 🥰

9.3. 'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry 🧁

IANA made another brand new registry, called "'ipn' Scheme URI Well-Known Service Numbers for BPv7" 🎉 The registration procedures, using terms from [RFC8126], are:

+=====================+===============================+
| Range               | Registration Procedures       |
+=====================+===============================+
| 1..127              | Private Use                   |
+---------------------+-------------------------------+
| 128..255            | Standards Action              |
+---------------------+-------------------------------+
| 0x0100..0x7FFF      | Private Use                   |
+---------------------+-------------------------------+
| 0x8000..0xFFFF      | Specification Required        |
+---------------------+-------------------------------+
| 0x10000..0xFFFFFFFF | Private Use                   |
+---------------------+-------------------------------+
| >=0x100000000       | Reserved for future expansion |
+---------------------+-------------------------------+

     Table 6: Registration Procedures for the 'ipn'
     Scheme URI Well-Known Service Numbers for BPv7
                        Registry

The initial values in the registry are:

+================+=============================+===================+
| Value          | Description                 | Reference         |
+================+=============================+===================+
| 0              | The Administrative Endpoint | [RFC9171] and RFC |
|                |                             | 9758, Section 5.7 |
+----------------+-----------------------------+-------------------+
| 0xEEE0..0xEEEF | Example Range               | RFC 9758          |
+----------------+-----------------------------+-------------------+

     Table 7: Initial Values in the 'ipn' Scheme URI Well-Known
                 Service Numbers for BPv7 Registry

Again, the "Example Range" is for examples in documentation and sample code 🌈

9.3.1. Guidance for Designated Experts 💜

This registry is meant to hold the default Service Numbers for well-known, interoperable services that are available and useful to the whole BPv7 community 🌍 So every range that isn't marked for Private Use MUST have a publicly available specification explaining how you interface with the service 📖 No mystery services, bestie 🙅‍♀️

Services that only make sense for one particular deployment or cooperation might need a registry to cut down on admin work, but they don't need an entry in this one 🫧

10. References 📚

10.1. Normative References 🧾

10.2. Informative References

These are the informative refs, so they're not required reading to implement the scheme, but they're the friends that give the whole picture 🦋📚

Appendix A. 'ipn' URI Scheme Text Representation Examples ✨

okay this is the fun part 💖 this section shows some example ipn URIs in their text form, so you can see what they actually look like in the wild 🎀

A.1. Using the Default Allocator

Let's look at the ipn URI for Service Number 2 on Node Number 1, allocated by the Default Allocator (0) (see Section 3.2.2). 🌸

The recommended seven-character representation of this URI would be like this:

ipn:1.2

The nine-character version, with the explicit Allocator Identifier spelled out, would be like this:

ipn:0.1.2

A.2. Using a Non-Default Allocator

Now let's look at the ipn URI for Service Number 3 on Node Number 1, allocated by Allocator 977000. 🧚

The 14-character representation of this URI would be:

ipn:977000.1.3

A.3. The Null ipn URI

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

ipn:0.0

A.4. The LocalNode ipn URI

Consider the ipn URI for Service Number 7 on the local node. 🍓

The recommended seven-character representation of this URI would be:

ipn:!.7

The numeric 16-character representation of this URI would be:

ipn:4294967295.7

Appendix B. 'ipn' URI Scheme CBOR Encoding Examples 🔥

this section shows some example CBOR encodings of ipn EIDs, which is the binary side of the same story 💅

B.1. Using the Default Allocator

Consider the ipn EID ipn:1.1. This text form of an ipn EID identifies Service Number 1 on Node Number 1, allocated by the Default Allocator (0) (see Section 3.2.2). 💜

The recommended five-octet encoding of this EID, using the two-element scheme-specific encoding, would be like this:

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

The six-octet encoding of this EID, using the three-element scheme-specific encoding, would be like this:

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

B.2. Using a Non-Default Allocator

Consider the ipn EID ipn:977000.1.1. This text form of an ipn EID identifies Service Number 1 on Node Number 1, allocated by Allocator 977000. 🌈

The recommended 10-octet encoding of this EID, using the three-element scheme-specific encoding, would be like this:

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

The 13-octet encoding of this EID, using the two-element scheme-specific encoding, would be like this:

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

B.3. The Null Endpoint

The Null EID of ipn:0.0 can be encoded in the following ways. ⭐

The recommended five-octet encoding of the Null ipn EID, using the two-element scheme-specific encoding, would be like this:

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

The six-octet encoding of the Null ipn EID, using the three-element scheme-specific encoding, would be like this:

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

Acknowledgments 🫶

the following DTN Working Group participants contributed technical material, use cases, and critical technical reviews for this URI scheme update: Scott Burleigh of the IPNGROUP, Keith Scott, Brian Sipos of the Johns Hopkins University Applied Physics Laboratory, Jorge Amodio of LJCV Electronics, and Ran Atkinson. 👑

the authors also want to thank the wider CCSDS SIS-DTN Working Group members, who gave useful reviews and commentary on this document and what it means for the future of networked space exploration. 🚀✨

Authors' Addresses 🦋

Rick Taylor Aalyria Technologies Email: rtaylor@aalyria.com

Edward J. Birrane, III The Johns Hopkins University Applied Physics Laboratory Email: Edward.Birrane@jhuapl.edu

📦 where this page comes from