| Internet-Draft | DNS Resource Records for DTN Overlays | June 2024 |
| Johnson | Expires 27 December 2024 | [Page] |
Delay Tolerant Networks (DTNs) are typically characterized by high latency and lack of constant end to end connectivity, consistent with their use in deep space communications. This, however, is not the limit of application of Bundle Protocol (BP) and related DTN enabling technologies. Through a collection of Convergance Layer Adapters (CLAs), deployment overlaying the terrestrial Internet is a core component of DTN implementations. IPN is a integer based naming scheme for DTN networks. Nothwithstanding cryptographic considerations, three basic components are necessary to make a BP overlay network connection, the IP address of the node, the CBHE Node Number (IPN component), and the CLA which provides IP connectivity. This document describes RRTYPE additions to DNS to enable terrestrial BP resource look up.¶
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 27 December 2024.¶
Copyright (c) 2024 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.¶
Terrestrial use of DTNs across reliable, low latency paths introduces the opportunity to leverage the existing DNS infrastructure to distribute connectivity related data. While is it not technically feasible to ensure delivery of non-stale data to spaceborne DTN nodes in response to a DNS lookup request, there is no such barrier to deploying DNS records which describe those core datasets necessary to enable connection of DTN nodes overlaying IPv4 or IPv6 networks.¶
A popular naming scheme for BP nodes is the IPN naming scheme, defined in [RFC7116]. The fundamental unit of this scheme is the Endpoint Identifier (EID) which is comprised of two 64 bit unsigned integers delineated by . as described in section 4.2.5.1.2 of [RFC9171]. Of the components of an EID, only the (node-nbr) component identifies the node, while the (service-nbr) component generally is analagous to the port number bound to an IP socket. Therefore, a DNS RRTYPE, IPN, is requested to represent the (node-nbr) component of a Bundle Protocol EID. Wire format encoding shall be an unsigned 64-bit integer in network order. Presentation format, for these resource records are either a 64 bit unsigned decimal integer, or two 32 bit unsigned decimal integers delimited by a period with the most significant 32 bits first and least significant 32 bits last. Values are not to be zero padded.¶
BP supports a wide range of CLAs; some are IP based while others interface at different layers or via different network layer protocols. Those treated here represent the subset designed to operate overlaying IP networks, and hence have DNS services generally constantly available in a low latency environment. Primary among these are TCP, UDP and LTP over UDP CLAs operating over both IPv4 and IPv6 links. A DNS RRTYPE, CLA, is requested to represent Convergence Layer Adapters on a node. Table 1 describes an initial list of of valid values for a CLA RRTYPE, to be encoded for presentation as space separated, unquoted, unescaped ASCII. Wire format encoding is identical to TXT format, with values restricted to Letters, Digits and interior Hyphens. It is possible for a node to deploy multiple CLAs using a single Node Number and IP address; TCP-v4 and UDP-v4 can work side by side on the same node, for example. To address this capability in the CLA RRTYPE, records may be expressed as a lone entry (i.e TCP-v6) or in a space delimited format, expressing multiple values (i.e. TCP-v4 TCP-v6 LTP-v6).¶
| Valid CLA RRTYPE Values |
|---|
| TCP-v4 |
| TCP-v6 |
| UDP-v4 |
| UDP-v6 |
| LTP-v4 |
| LTP-v6 |
| STCP-v4 |
| STCP-v6 |
| BSSP-v4 |
| BSSP-v6 |
| IPND-v4 |
| IPND-v6 |
IANA is requested to create CLA and IPN RRTYPES in the Domain Name System (DNS) Resource Record (RR) TYPEs registry.¶
This document should not affect the security of the Internet.¶
Thanks to Mark Andrews and Scott Burleigh for their contributions to this document.¶