Internet Engineering Task Force S. Johnson, Ed. Internet-Draft Spacely Packets, LLC Intended status: Informational 1 July 2024 Expires: 2 January 2025 DNS Resource Records for DTN Overlays draft-johnson-dns-ipn-cla-07 Abstract 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. Notwithstanding cryptographic considerations, three basic components are necessary to enable a BP node to use the underlying Internet to communicate with another BP node: the IP address of the node, the CBHE Node Number (component of any ipn-scheme URI identifying a BP endpoint of which that node is a member), and the CLA which provides IP connectivity to that node. This document describes RRTYPE additions to DNS to enable terrestrial BP resource look-up. Status of This Memo 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 2 January 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Johnson Expires 2 January 2025 [Page 1] Internet-Draft DNS Resource Records for DTN Overlays July 2024 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. RRTYPES for Delay Tolerant Networks . . . . . . . . . . . . . 3 3.1. IPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. CLA . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Convergence Layer Adapters . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction 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. 1.1. Requirements Language 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. Johnson Expires 2 January 2025 [Page 2] Internet-Draft DNS Resource Records for DTN Overlays July 2024 2. Purpose One barrier to BP native application authoring which has been identified is lack of an API. This is being explored in multiple directions, including userspace and kernel API implementations. It is highly useful, when operating over the underlying Internet, for an application to be able to collect all necessary connectivity data via DNS query. A web browser, for example, does a DNS lookup before making a http request. At a minimum, this means Node Number and available CLA(s) in addition to IP address when making a BP connection. If BPSEC is deployed, additional RRTYPES, such as a security context identifier (CTX) and public key (BSEC) records might be appropriate to negotiate such a connection, but they are out of scope of this draft. If the application then transmits that information via an API to the BPA, the BPA can take action in the contact graph to perfect the connection. This draft, and the RRTYPEs it describes, enable a preferred component of an API structure to encourage application development. 3. RRTYPES for Delay Tolerant Networks 3.1. IPN A popular naming scheme for BP nodes is the IPN naming scheme, a URI scheme defined in [RFC7116]. URIs composed in this scheme identify BP endpoints. The scheme-specific part of a BP ipn-scheme Endpoint Identifier (EID) comprises two 64 bit unsigned integers separated by single '.'character as described in section 4.2.5.1.2 of [RFC9171]. Of these two components of an EID, only the first component termed the (node-nbr), identifies the node, while the second (service-nbr) component generally is analogus to the port number bound to an IP socket. Therefore, a DNS RRTYPE, IPN, is requested by which the (node-nbr) component of a Bundle Protocol EID is represented. 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. 3.2. CLA 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 utilize underlying 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 Johnson Expires 2 January 2025 [Page 3] Internet-Draft DNS Resource Records for DTN Overlays July 2024 Layer Adapters on a node. Table 1 describes an initial list of of valid values for a CLA RRTYPE. Wire format is defined as one or more character strings as defined in [RFC1035], Section 3.3, conforming to the format described in Section 3.3.14 of same, with character set restricted to Letters, Digits, and internal Hyphens. The presentation format syntax for this RRTYPE is defined as [CLA protocol]-[IP Version]-[BP Version]. Each CLA label MUST be formed of exactly one character-string. The character set for the presentation format is restricted to Letters, Digits, and interior Hyphens, although quoting is acceptable in a zone file, per the below example. node.foo. CLA IN "TCP-V4-V6" "TCP-V6-V7" node.foo. CLA IN TCP-V4-V6 TCP-V6-V7 The following is an example of an unsuitable syntax, as two labels quoted together represent only a single character string. node.foo. CLA IN "TCP-V4-V6 TCP-V6-V7" The first field describes the packet or datagram type for transmission, the second the version of IP (v4 or v6) and the third describes the version BP (v6 or v7) of the service(s) offered on the node. It is possible for a node to deploy multiple CLAs using a single Node Number and IP address; TCP-v4-v6 and UDP-v4-v6 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-v7) or in a space delimited format, expressing multiple values (i.e. TCP-v4-v7 TCP-v6-v7 LTP-v6-v7). 4. Convergence Layer Adapters +=========================+=========================+ | Valid CLA RRTYPE Values | Specification Document | +=========================+=========================+ | TCP-v4-v6 | [RFC7242] | +-------------------------+-------------------------+ | UDP-v4-v6 | [RFC7112] | +-------------------------+-------------------------+ | LTP-v4-v6 | [RFC7112] | +-------------------------+-------------------------+ | STCP-v4-v6 | [I-D.burleigh-dtn-stcp] | +-------------------------+-------------------------+ | BSSP-v4-v6 | CCSDS 730.2-G-1 | +-------------------------+-------------------------+ | IPND-v4-v6 | [I-D.johnson-dtn-ipnd] | +-------------------------+-------------------------+ Johnson Expires 2 January 2025 [Page 4] Internet-Draft DNS Resource Records for DTN Overlays July 2024 | TCP-v4-v7 | [RFC9174] | +-------------------------+-------------------------+ | TCP-v6-v7 | [RFC9174] | +-------------------------+-------------------------+ | UDP-v4-v7 | [RFC7112] | +-------------------------+-------------------------+ | UDP-v6-v7 | [RFC7112] | +-------------------------+-------------------------+ | LTP-v4-v7 | [RFC7112] | +-------------------------+-------------------------+ | LTP-v6-v7 | [RFC7112] | +-------------------------+-------------------------+ | STCP-v4-v7 | [I-D.burleigh-dtn-stcp] | +-------------------------+-------------------------+ | STCP-v6-v7 | [I-D.burleigh-dtn-stcp] | +-------------------------+-------------------------+ | BSSP-v4-v7 | CCSDS 730.2-G-1 | +-------------------------+-------------------------+ | BSSP-v6-v7 | CCSDS 730.2-G-1 | +-------------------------+-------------------------+ | IPND-v4-v7 | [I-D.johnson-dtn-ipnd] | +-------------------------+-------------------------+ | IPND-v6-v7 | [I-D.johnson-dtn-ipnd] | +-------------------------+-------------------------+ Table 1 5. IANA Considerations IANA is requested to create CLA and IPN RRTYPES in the Domain Name System (DNS) Resource Record (RR) TYPEs registry. 6. Security Considerations This document should not affect the security of the Internet. 7. References 7.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Johnson Expires 2 January 2025 [Page 5] Internet-Draft DNS Resource Records for DTN Overlays July 2024 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014, . [RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission Protocol (LTP), Compressed Bundle Header Encoding (CBHE), and Bundle Protocol IANA Registries", RFC 7116, DOI 10.17487/RFC7116, February 2014, . [RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol", RFC 7242, DOI 10.17487/RFC7242, June 2014, . [RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, . [RFC9174] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay- Tolerant Networking TCP Convergence-Layer Protocol Version 4", RFC 9174, DOI 10.17487/RFC9174, January 2022, . [I-D.burleigh-dtn-stcp] Burleigh, S. C., "Simple TCP Convergence-Layer Protocol", Work in Progress, Internet-Draft, draft-burleigh-dtn-stcp- 00, 14 September 2018, . [I-D.johnson-dtn-ipnd] Ellard, D., Altmann, R., Gladd, A., Brown, D., in 't Velt, R., and S. M. Johnson, "DTN IP Neighbor Discovery (IPND)", Work in Progress, Internet-Draft, draft-johnson-dtn-ipnd- 00, 9 October 2023, . Johnson Expires 2 January 2025 [Page 6] Internet-Draft DNS Resource Records for DTN Overlays July 2024 Contributors Thanks to Mark Andrews, Scott Burleigh, Brian Sipos, Rick Taylor, and Ray Bellis for their contributions to this document. Author's Address Scott M. Johnson (editor) Spacely Packets, LLC 46 High Ridge Road Daytona Beach, FL 32117 United States of America Phone: 386-888-7311 Email: scott@spacelypackets.com Johnson Expires 2 January 2025 [Page 7]