Session Date/Time: 05 Oct 2022 17:00

DTN

Summary

This interim meeting focused primarily on discussing a personal draft proposing an extension to the Internet Protocol Number (IPN) naming scheme. The goal was to address scalability, clarity in IANA registries, and improved interoperability for IPN, with a view towards working group adoption at IETF 115.

Key Discussion Points

Meeting Administration: The meeting was an informal interim, emphasizing discussion over formal presentations. The IETF Note Well applies. The draft under discussion was presented in Markdown to allow for live editing and workshop-style feedback.
Chairs as Authors: The chairs, Rick Taylor and Ed Birrane, clarified that their roles as authors of the draft were personal contributions and should be considered separate from their chairing duties.
Draft Readership: A poll indicated that approximately three-quarters of attendees had read the draft, providing context for the level of background discussion needed.
IPN Extension Proposal: The core proposal is to extend the existing node-number.service-number IPN scheme to include a numbering-authority.node-number.service-number structure.
- Rationale: The current single flat node numbering namespace presents scalability challenges for global uniqueness and management. A hierarchical structure, similar to MAC addresses or EUIs, would allow for decentralized allocation and more efficient CBOR encoding by enabling smaller node numbers within each authority's domain, avoiding a "race for low numbers" to achieve header compression.
- Secondary Purpose: Clarify IANA registries related to IPN usage for Bundle Protocol Version 7 (BPv7), as current registries are confusing and misleadingly named.
Urgency and Scope:
- The proposed changes are not driven by an immediate "breaking" industrial need but are timely for clarifying and enhancing IPN before the working group progresses further into naming, addressing, forwarding, and routing.
- The primary driver is improving interoperability between cooperating parties. For closed systems, existing IPN in BPv7 works without standards, but global interoperability requires clarity.
- Examples of multi-agency scenarios would be beneficial for understanding the scope and usage of numbering authorities.
Alternative: report-to-Eid for Authority: A suggestion was made to use the report-to-Eid field to establish an authority identifier.
- Concerns: This was viewed as redefining the meaning of report-to-Eid, which could introduce new concepts and undesirable behavioral changes. It was also noted that source and destination EIDs might come from different authorities, requiring per-EID authority identification rather than a single bundle-level field. This approach might also lead to bundle-in-bundle encapsulation or Network Address Translation (NAT) rather than a homogeneous address space extension.
Extend Existing Scheme vs. New Scheme:
- The functional impact on a BPv7 implementation would be similar whether the scheme is extended or a new "IPN3" scheme is introduced (both would initially result in an unrecognized scheme or a scheme with an unexpected number of dimensions).
- The general sense was to extend the existing IPN scheme to avoid introducing unnecessary new scheme identifiers.
Backward Compatibility and Implementation Impact:
- Concerns were raised regarding the impact on existing IPN implementations (e.g., NASA, ISS), especially if they need to operate with both BPv6 and BPv7 (though BPv6 and BPv7 are not wire-compatible, raising operator confusion about nomenclature was a concern).
- It was emphasized that BPv6 and BPv7 are not wire-compatible, so any interoperability would require gatewaying/translation, making name translation a manageable part of that process.
- The status quo regarding IANA registries is deemed unsatisfactory; some form of clarification or update is necessary, irrespective of the scheme extension.
Administrative Endpoint and Node Number Uniqueness:
- Service Number 0: In BPv6 IPN, service number 0 was a must for the administrative endpoint; in BPv7, it's a may. A strong preference was expressed for it to be consistently 0, and there was general agreement on the intent.
- Common Node Number: The intent that all IPN EIDs on a given node should share a common node number (or authority-qualified node number) was discussed. This is desired for clarity but not explicitly written in RFC 9171. Making this explicit would be beneficial.
Compatibility with HIP/DRIP: Stuart Cheshire highlighted potential compatibility with Host Identity Protocol (HIP) and DRIP Hierarchical Host Identity Tags (HITS), where DRIP identifiers could be mapped to naming authorities and sub-authorities within the proposed IPN extension. This would allow embedding other allocation methods.
- Caveat: While embedding other allocation methods is fine, it's important to resist overloading node numbers with global meaning beyond their allocation purpose.
"Thresholding" (Bit-width Limits): Scott Burleigh proposed limiting the bit-width of authority, sub-authority, and node numbers (e.g., 32, 16, 16 bits respectively) such that the combined identifier would always fit within 64 bits. This would offer significant implementation advantages (e.g., packing into a 64-bit unsigned integer) and potentially minimize impact on existing implementations that assume integer-based node identifiers.
- Discussion: This was seen as a potentially radical change given the existing 2^64 range in RFC 9171 and predecessors. Rick Taylor expressed concern about directly updating RFC 9171 with such strict limits due to perceived impact on space agencies, suggesting that such limits could be enforced through IANA registration policies (e.g., private/experimental ranges for numbers >2^16). However, Scott argued that if the scheme definition changes in this document, imposing size limits on its new elements would not necessarily require modifying 9171, and that breaking implementations assuming 64-bit integer IDs would be a significant problem for broader interoperability. The general sentiment was that exceeding 4 billion for authority or node numbers is unlikely in practice.

Decisions and Action Items

Decision: The general sense of those present is to proceed with an extension to the existing IPN scheme (rather than defining a brand new scheme) to address scalability, IANA registry clarity, and interoperability concerns.
Action Item (Rick Taylor): Publish a new revision of the draft, incorporating comments received on the mailing list and during this meeting.
Action Item (Rick Taylor / Scott Burleigh): Encourage further discussion on the mailing list, specifically regarding the proposal for "thresholding" (limiting bit-width of IPN components for implementation advantages and backward compatibility considerations).
Goal: The working group aims to reach agreement on the draft to enable adoption and potentially initiate a working group last call at IETF 115.

Next Steps

The updated draft will be circulated for review and further comments.
Discussion will continue on the DTN mailing list, particularly on the bit-width limitation proposal.
The chairs will aim for working group adoption of the draft at the IETF 115 meeting in London.