]> Aalyria Technologies, LLC

ek.ietf@gmail.com

Delay/Disruption Tolerant Networking DTN BP IPN DNS This document requests a DNS parent for IPN addresses, discusses the registration procedures and management of the DNS zone, as well as some operational recommendations. This document specifies that IPN addresses may have a DNS representation of the form 1.978879.ipn.arpa, for IPN node 1 under IPN Allocator 978879. This document also describes how this DNS structure can be useful in locating the Bundle Protocol (BP) Convergence Layer (CL) endpoint(s) of the BP Agent responsible for a given IPN address. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Delay/Disruption Tolerant Networking mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction TODO Introduction

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 when, and only when, they appear in all capitals, as shown here. TODO

Concept of Operations The Forwarding Information Base (FIB) of a BP Agent may be populated from a variety of sources. Typically, explicit (manual) configuration is given to associate BP destination endpoints with the Convergence Layer parameters required to establish communication with a responsible receiving BP Agent. A BP Agent may also dynamically create a FIB entry by querying for DNS Resource Records as follows. Consider a space agency with a registered IPN Allocator ID of 978879 that published the following two DNS zones: A BP Agent, perhaps collocated at a landing station, which had received a Bundle destined for ipn:978879.500.345 could determine the proper TCP and UDP CL IP addresses and ports by:

• querying for a PTR record associated with 500.978879.ipn.arpa
• (receiving research-department.space-agency.example)
• querying for an SRV record associated with _dtn-bundle._tcp.research-department.space-agency.example (ditto for ._udp)
• (receiving port 4556 and hostname cloud-service.space-agency.example.)
• querying for A and AAAA records for cloud-service.space-agency.example.
• (receiving 192.0.2.5 and 2001:db8::5)

The BP Agent at the landing station could then attempt to initiated a or connection to [2001:db8::5]:4556, for example, and attempt to deliver the given Bundle. Similarly, a researcher attempting to send a Bundle payload to mars-orbiter2.space-agency.example could use a BP Agent capable of querying DNS and learning about the endpoint at 192.0.2.1:4556. Once the Bundle had been forwarded to antenna-relay.space-agency.example, it would be the antenna-relay's responsibility to forward it to the spacecraft. Any future CLs that define DNS records (e.g. SVCB records, etc) may be added to the space-agency.example zone and, through the use of PTR records in the 978879.ipn.arpa zone, be discovered by appropriately capable BP agents.

Operational Considerations TODO Operational Note that use of DNS may not be appropriate for all network environments. Any deployments where querying DNS might not align with reliability or performance requirements are recommended to obtain BP FIB information by other mechanisms (out of scope of this document).

Security Considerations TODO Security

IAB Considerations The IAB is requested to approve the zone "ipn.arpa" as parent for IPN addresses, similar to in-addr.arpa and ip6.arpa "reverse DNS" for IPv4 and IPv6 addresses (respectively). Per , IPN addresses have an Allocator identifier and an allocator-specific identifier (both 32-bit unsigned integers).

IANA Considerations

'ipn' Allocator Registry List of Nameservers IANA is requested to augment its registration procedures for entries in the 'ipn' Scheme URI Allocator Identifiers Registry with a column for "Authoritative Nameservers". Requesters of an Allocator or Allocator range MAY provide the IP addresses of DNS nameservers that will be considered authoritative for the .ipn.arpa zone for each requested Allocator.

Guidance to Designate Experts TBD: things like make sure there are at least two nameserver IP addresses and both IPv4 and IPv6 addresses are given, etc.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document updates the specification of the 'ipn' URI scheme previously defined in RFC 6260 and the IANA registries established in RFC 7116. It also updates the rules for the encoding and decoding of these URIs when used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv7) as defined in RFC 9171. These updates clarify the structure and behavior of the 'ipn' URI scheme, define new encodings of 'ipn' scheme URIs, and establish the registries necessary to manage this scheme. This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms. This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG.

Acknowledgments TODO acknowledge.