[arin-ppml] Draft Policy ARIN-2026-1: Taking IP To Other Planets (TIPTOP)

[Raymond Burkholder]

On 2026-03-24 11:37, ARIN wrote:
> On 19 March 2026, the ARIN Advisory Council (AC) accepted “ARIN-prop-349: Taking IP To Other Planets (TIPTOP)” as Draft Policy.
> Draft Policy ARIN-2026-1 is below and can be found at:
> https://www.arin.net/participate/policy/drafts/2026_1
>
> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are:
>
> * Enabling Fair and Impartial Number Resource Administration
> * Technically Sound
> * Supported by the Community
>
> The PDP can be found at:
>
> https://www.arin.net/participate/policy/pdp/
>
> Draft Policies and Proposals under discussion can be found at:https://www.arin.net/participate/policy/drafts/

Have the various groups known as 'Delay Tolerant Networking (DTN)' been 
involved in any of these discussions?  They are the ones typically 
involved in addressing, protocol selection, etc.  I would start there.  
There are a a few other similar groups around.

A couple items I had laying around in my mailbox:

----------

Hello, a new article has been posted to the APNIC Blog on “Delay 
Tolerant Networking Performance”:

https://blog.apnic.net/2024/03/25/delay-tolerant-networking-performance/

  The article specifically addresses performance aspects of the 
Licklider Transmission Protocol (LTP)
based on two popular DTN implementations with complimentary use cases. 
The article highlights
the performance increases observed for using larger LTP segment sizes 
even when lower layer|
fragmentation is necessary to accommodate the larger sizes. The article 
finally includes a new
service for signaling lower-layer QoS parameters for networks that 
support DTN overlays.

  This article has important implications for IPv4 and IPv6 
Internetworking in that it provides
evidence that larger packet sizes have significantly beneficial 
implications for performance
|even when IP fragmentation is invoked. It suggests that better support 
for large packets
through larger link and path MTUs as well as properly functioning IP 
fragmentation are
important for the future of the Internet. The new Firewall and Service 
Tickets (FAST)
service should also provide significant QoS benefits.

Please review and comment,

Fred Templin fred.l.templin at boeing.com

-------

dtn at ietf.org

The Delay/Disruption Tolerant Networking (DTN) Working Group specifies
mechanisms for data communications in the presence of long delays and/or
intermittent connectivity.  The Working Group has published the Bundle
Protocol v7 (BPv7), corresponding Bundle Protocol Security protocol (BPSec)
and an interoperable Security Context, and the TCP Convergence Layer
specifications as standards track RFCs. Multiple independent implementations
exist for these technologies in both space and terrestrial environments, and
the technology is now used in production by government and commercial
organizations world-wide.

This Working Group now focuses on the further work relevant to the area of
Delay/Disruption Tolerant Networking, dividing work items into 3
broad categories:

  * An architecture for Naming, Addressing and Forwarding

     The Bundle Protocol v7 defines an encoding of Names for use in DTN, but
     the detailed semantics have not been specified.  The Working Group will
     define a common architecture for the delay/disruption tolerant assignment
     of names, and the late-binding of such names during bundle forwarding to
     end-points within a DTN.  This architecture will define a standard model
     for the forwarding process of a Bundle Process Agent, providing an
     informational reference point for further specifications.

     The Working Group charter intentionally excludes topics related to Routing
     in DTNs. This does not preclude discussion of the subject, in coordination
     with the Routing Area, but no Working Group documents will be adopted
     under this charter.

  * The definition of architecture and protocols in the areas of Operations,
  Administration and Management (OAM), and Key Management

     Current DTN deployments rely on the use of pre-placed keys and
     configuration or bespoke tooling, and there is a growing demand for
     standards to improve the automation and reliability of DTN management.
     Existing IETF protocols for OAM and Key Management generally rely on a
     bi-directional end-to-end path between devices, and in Delay/Disruption
     Tolerant Networks (DTNs) such paths rarely exist.  To enable OAM and Key
     Management in such cases, there may be a need to standardize an
     architecture supporting alternative methods and their supporting protocols
     and data models.  The Working Group will liaise with relevant experts in
     the OPS Area to discover if there are existing standards that meet, or may
     be extended to meet, the DTN use-cases before standardizing new protocols.
     There is also believed to be cross-over between the use-cases for OAM and
     Key Management in DTNs and the use-cases in Mobile Ad-hoc Networks
     (MANETs); to this end the Working Group will coordinate with the MANET
     Working Group to explore potential synergies and avoid duplication of
     effort.

  * Extensions to and best practices for existing protocols

     Extensions to the Bundle Protocol to enable reliability signalling,
     tunnelling and Quality of Service indication are needed for the
     operational deployment of Delay/Disruption Tolerant Networks, and these
     capabilities will be standardized by the Working Group.

     Additional extensions to the Bundle Protocol, additional Security Context
     definitions for BPSec, and new Convergence Layer adaptors will be
     considered on a case-by-case basis by the working group.

     The Working Group will also document best practices learned from existing
     deployment.

The Working Group will coordinate with other IETF Working Groups, especially
in the Security, Routing, Operation and Management Areas, to ensure the
quality of peer review, the avoidance of duplication of effort, and alignment
with specifications produced in other Working Groups.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20260325/c1184ab8/attachment.htm>