DNS Resource Records for DTN Overlays
draft-johnson-dns-ipn-cla-07
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Scott M. Johnson | ||
| Last updated | 2024-07-01 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-johnson-dns-ipn-cla-07
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, <https://www.rfc-editor.org/info/rfc1035>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of
Oversized IPv6 Header Chains", RFC 7112,
DOI 10.17487/RFC7112, January 2014,
<https://www.rfc-editor.org/info/rfc7112>.
[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,
<https://www.rfc-editor.org/info/rfc7116>.
[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant
Networking TCP Convergence-Layer Protocol", RFC 7242,
DOI 10.17487/RFC7242, June 2014,
<https://www.rfc-editor.org/info/rfc7242>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[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,
<https://www.rfc-editor.org/info/rfc9174>.
[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,
<https://datatracker.ietf.org/doc/html/draft-burleigh-dtn-
stcp-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-johnson-dtn-
ipnd-00>.
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]