From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6742.txt | 1123 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1123 insertions(+) create mode 100644 doc/rfc/rfc6742.txt (limited to 'doc/rfc/rfc6742.txt') diff --git a/doc/rfc/rfc6742.txt b/doc/rfc/rfc6742.txt new file mode 100644 index 0000000..7aad015 --- /dev/null +++ b/doc/rfc/rfc6742.txt @@ -0,0 +1,1123 @@ + + + + + + +Internet Research Task Force (IRTF) RJ Atkinson +Request for Comments: 6742 Consultant +Category: Experimental SN Bhatti +ISSN: 2070-1721 U. St Andrews + S. Rose + US NIST + November 2012 + + + DNS Resource Records for the + Identifier-Locator Network Protocol (ILNP) + +Abstract + + This note describes additional optional resource records for use with + the Domain Name System (DNS). These optional resource records are + for use with the Identifier-Locator Network Protocol (ILNP). This + document is a product of the IRTF Routing Research Group. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Research Task + Force (IRTF). The IRTF publishes the results of Internet-related + research and development activities. These results might not be + suitable for deployment. This RFC represents the individual + opinion(s) of one or more members of the Routing Research Group of + the Internet Research Task Force (IRTF). Documents approved for + publication by the IRSG are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6742. + + + + + + + + + + + + + +Atkinson, et al. Experimental [Page 1] + +RFC 6742 ILNP DNS November 2012 + + +Copyright Notice + + Copyright (c) 2012 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 + (http://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. + + This document may not be modified, and derivative works of it may not + be created, except to format it for publication as an RFC or to + translate it into languages other than English. + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Document Roadmap ...........................................4 + 1.2. Terminology ................................................5 + 2. New Resource Records ............................................5 + 2.1. The NID Resource Record ....................................5 + 2.2. The L32 Resource Record ....................................7 + 2.3. The L64 Resource Record ...................................10 + 2.4. The LP Resource Record ....................................12 + 3. Deployment Example .............................................15 + 3.1. Use of ILNP Records .......................................15 + 3.2. Additional Section Processing .............................16 + 4. Security Considerations ........................................17 + 5. IANA Considerations ............................................17 + 6. References .....................................................17 + 6.1. Normative References ......................................17 + 6.2. Informative References ....................................18 + 7. Acknowledgements ...............................................20 + +1. Introduction + + This document is part of the ILNP document set, which has had + extensive review within the IRTF Routing RG. ILNP is one of the + recommendations made by the RG Chairs. Separately, various refereed + research papers on ILNP have also been published during this decade. + So, the ideas contained herein have had much broader review than the + IRTF Routing RG. The views in this document were considered + controversial by the Routing RG, but the RG reached a consensus that + the document still should be published. The Routing RG has had + remarkably little consensus on anything, so virtually all Routing RG + outputs are considered controversial. + + + +Atkinson, et al. Experimental [Page 2] + +RFC 6742 ILNP DNS November 2012 + + + At present, the Internet research and development community is + exploring various approaches to evolving the Internet Architecture to + solve a variety of issues including, but not limited to, scalability + of inter-domain routing [RFC4984]. A wide range of other issues + (e.g., site multihoming, node multihoming, site/subnet mobility, node + mobility) are also active concerns at present. Several different + classes of evolution are being considered by the Internet research + and development community. One class is often called "Map and + Encapsulate", where traffic would be mapped and then tunnelled + through the inter-domain core of the Internet. Another class being + considered is sometimes known as "Identifier/Locator Split". This + document relates to a proposal that is in the latter class of + evolutionary approaches. + + The Identifier-Locator Network Protocol (ILNP) was developed to + explore a possible evolutionary direction for the Internet + Architecture. A description of the ILNP architecture is available in + a separate document [RFC6740]. Implementation and engineering + details are largely isolated into a second document [RFC6741]. + + The Domain Name System (DNS) is the standard way that Internet nodes + locate information about addresses, mail exchangers, and other data + relating to remote Internet nodes [RFC1034] [RFC1035]. + + More recently, the IETF has defined standards-track security + extensions to the DNS [RFC4033]. These security extensions can be + used to authenticate signed DNS data records and can be used to store + signed public keys in the DNS. Further, the IETF has defined a + standards-track approach to enable secure dynamic update of DNS + records over the network [RFC3007]. + + This document defines several new optional data resource records. + This note specifies the syntax and other items required for + independent implementations of these DNS resource records. The + reader is assumed to be familiar with the basics of DNS, including + familiarity with [RFC1034] [RFC1035]. + + The concept of using DNS for rendezvous with mobile nodes or mobile + networks has been proposed earlier, more than once, independently, by + several other researchers; for example, please see [SB00], [SBK01], + and [PHG02]. + + + + + + + + + + +Atkinson, et al. Experimental [Page 3] + +RFC 6742 ILNP DNS November 2012 + + +1.1. Document Roadmap + + This document describes defines additional DNS resource records that + support ILNP. + + The ILNP architecture can have more than one engineering + instantiation. For example, one can imagine a "clean-slate" + engineering design based on the ILNP architecture. In separate + documents, we describe two specific engineering instances of ILNP. + The term "ILNPv6" refers precisely to an instance of ILNP that is + based upon, and backwards compatible with, IPv6. The term "ILNPv4" + refers precisely to an instance of ILNP that is based upon, and + backwards compatible with, IPv4. + + Many engineering aspects common to both ILNPv4 and ILNPv6 are + described in [RFC6741]. A full engineering specification for either + ILNPv6 or ILNPv4 is beyond the scope of this document. + + Readers are referred to other related ILNP documents for details not + described here: + + a) [RFC6740] is the main architectural description of ILNP, including + the concept of operations. + + b) [RFC6741] describes engineering and implementation considerations + that are common to both ILNPv4 and ILNPv6. + + c) [RFC6743] defines a new ICMPv6 Locator Update message used by an + ILNP node to inform its correspondent nodes of any changes to its + set of valid Locators. + + d) [RFC6744] defines a new IPv6 Nonce Destination Option used by + ILNPv6 nodes (1) to indicate to ILNP correspondent nodes (by + inclusion within the initial packets of an ILNP session) that the + node is operating in the ILNP mode and (2) to prevent off-path + attacks against ILNP ICMP messages. This Nonce is used, for + example, with all ILNP ICMPv6 Locator Update messages that are + exchanged among ILNP correspondent nodes. + + e) [RFC6745] defines a new ICMPv4 Locator Update message used by an + ILNP node to inform its correspondent nodes of any changes to its + set of valid Locators. + + f) [RFC6746] defines a new IPv4 Nonce Option used by ILNPv4 nodes to + carry a security nonce to prevent off-path attacks against ILNP + ICMP messages and also defines a new IPv4 Identifier Option used + by ILNPv4 nodes. + + + + +Atkinson, et al. Experimental [Page 4] + +RFC 6742 ILNP DNS November 2012 + + + g) [RFC6747] describes extensions to Address Resolution Protocol + (ARP) for use with ILNPv4. + + h) [RFC6748] describes optional engineering and deployment functions + for ILNP. These are not required for the operation or use of ILNP + and are provided as additional options. + +1.2. Terminology + + In this document, the term "ILNP-aware" applied to a DNS component + (either authoritative server or cache) is used to indicate that the + component attempts to include other ILNP RRTypes to the Additional + section of a DNS response to increase performance and reduce the + number of follow-up queries for other ILNP RRTypes. These other + RRsets MAY be added to the Additional section if space permits and + only when the QTYPE equals NID, L64, L32, or LP. There is no method + for a server to signal that it is ILNP-aware. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. New Resource Records + + This document specifies several new and closely related DNS data + resource records (RRs). These new RR types have the mnemonics "NID", + "L32", "L64", and "LP". These RR types are associated with a Fully + Qualified Domain Name (FQDN) that is hereafter called the "owner + name". These are part of work on the Identifier-Locator Network + Protocol (ILNP) [RFC6740]. + + For clarity, throughout this section of this document, the "RDATA" + subsections specify the on-the-wire format for these records, while + the "Presentation Format" subsections specify the human-readable + format used in a DNS configuration file (i.e., "master file" as + defined by RFC 1035, Section 5.1). + +2.1. The NID Resource Record + + The Node Identifier (NID) DNS resource record (RR) is used hold + values for Node Identifiers that will be used for ILNP-capable nodes. + + NID records are present only for ILNP-capable nodes. This + restriction is important; ILNP-capable nodes use the presence of NID + records in the DNS to learn that a correspondent node is also ILNP- + capable. While erroneous NID records in the DNS for a node that is + not ILNP-capable would not prevent communication, such erroneous DNS + records could increase the delay at the start of an IP session. + + + +Atkinson, et al. Experimental [Page 5] + +RFC 6742 ILNP DNS November 2012 + + + A given owner name may have zero or more NID records at a given time. + In normal operation, nodes that support the Identifier-Locator + Network Protocol (ILNP) will have at least one valid NID record. + + The type value for the NID RR type is 104. + + The NID RR is class independent. + + The NID RR has no special Time to Live (TTL) requirements. + +2.1.1. NID RDATA Wire Format + + The RDATA for an NID RR consists of: + + - a 16-bit Preference field + - a 64-bit NodeID field + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | NodeID | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.1.1.1. The Preference Field + + The field contains a 16-bit unsigned integer in network + byte order that indicates the owner name's relative preference for + this NID record among other NID records associated with this owner + name. Lower Preference values are preferred over higher Preference + values. + +2.1.1.2. The NodeID Field + + The NodeID field is an unsigned 64-bit value in network byte order. + It complies with the syntactic rules of IPv6 interface identifiers + [RFC4291], Section 2.5.1, but has slightly different semantics. + Unlike IPv6 interface identifiers, which are bound to a specific + *interface* of a specific node, NodeID values are bound to a specific + *node*, and they MAY be used with *any interface* of that node. + + + + + + + + +Atkinson, et al. Experimental [Page 6] + +RFC 6742 ILNP DNS November 2012 + + +2.1.2. NID RR Presentation Format + + The presentation of the format of the RDATA portion is as follows: + + - The Preference field MUST be represented as a 16-bit unsigned + decimal integer. + + - The NodeID field MUST be represented using the same syntax (i.e., + groups of 4 hexadecimal digits, with each group separated by a + colon) that is already used for DNS AAAA records (and also used for + IPv6 interface IDs). + + - The NodeID value MUST NOT be in the 'compressed' format (e.g., + using "::") that is defined in RFC 4291, Section 2.2 (2). This + restriction exists to avoid confusion with 128-bit IPv6 addresses, + because the NID is a 64-bit field. + +2.1.3. NID RR Examples + + An NID record has the following logical components: + + IN NID + + In the above, is the owner name string, is + an unsigned 16-bit value, and is an unsigned 64-bit value. + + host1.example.com. IN NID 10 0014:4fff:ff20:ee64 + host1.example.com. IN NID 20 0015:5fff:ff21:ee65 + host2.example.com. IN NID 10 0016:6fff:ff22:ee66 + + As NodeID values use the same syntax as IPv6 interface identifiers, + when displayed for human readership, the NodeID values are presented + in the same hexadecimal format as IPv6 interface identifiers. This + is shown in the example above. + +2.1.4. Additional Section Processing + + To improve performance, ILNP-aware DNS servers and DNS resolvers MAY + attempt to return all L32, L64, and LP records for the same owner + name of the NID RRset in the Additional section of the response, if + space permits. + +2.2. The L32 Resource Record + + An L32 DNS RR is used to hold 32-bit Locator values for + ILNPv4-capable nodes. + + + + + +Atkinson, et al. Experimental [Page 7] + +RFC 6742 ILNP DNS November 2012 + + + L32 records are present only for ILNPv4-capable nodes. This + restriction is important; ILNP-capable nodes use the presence of L32 + records in the DNS to learn that a correspondent node is also + ILNPv4-capable. While erroneous L32 records in the DNS for a node + that is not ILNP-capable would not prevent communication, such + erroneous DNS records could increase the delay at the start of an IP + session. + + A given owner name might have zero or more L32 values at a given + time. An ILNPv4-capable host SHOULD have at least 1 Locator (i.e., + L32 or LP) DNS resource record while it is connected to the Internet. + An ILNPv4-capable multihomed host normally will have multiple Locator + values while multihomed. An IP host that is NOT ILNPv4-capable MUST + NOT have an L32 or LP record in its DNS entries. A node that is not + currently connected to the Internet might not have any L32 values in + the DNS associated with its owner name. + + A DNS owner name that is naming a subnetwork, rather than naming a + host, MAY have an L32 record as a wild-card entry, thereby applying + to entries under that DNS owner name. This deployment scenario + probably is most common if the named subnetwork is, was, or might + become, mobile. + + The type value for the L32 RR type is 105. + + The L32 RR is class independent. + + The L32 RR has no special TTL requirements. + +2.2.1. L32 RDATA Wire Format + + The RDATA for an L32 RR consists of: + + - a 16-bit Preference field + - a 32-bit Locator32 field + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference | Locator32 (16 MSBs) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Locator32 (16 LSBs) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + MSB = most significant bit + LSB = least significant bit + + + + + +Atkinson, et al. Experimental [Page 8] + +RFC 6742 ILNP DNS November 2012 + + +2.2.1.1. The Preference Field + + The field is an unsigned 16-bit field in network byte + order that indicates the owner name's relative preference for this + L32 record among other L32 records associated with this owner name. + Lower Preference values are preferred over higher Preference values. + +2.2.1.2. The Locator32 Field + + The field is an unsigned 32-bit integer in network byte + order that is identical on-the-wire to the ADDRESS field of the + existing DNS A record. + +2.2.2. L32 RR Presentation Format + + The presentation of the format of the RDATA portion is as follows: + + - The Preference field MUST be represented as a 16-bit unsigned + decimal integer. + + - The Locator32 field MUST be represented using the same syntax used + for existing DNS A records (i.e., 4 decimal numbers separated by + periods without any embedded spaces). + +2.2.3. L32 RR Examples + + An L32 record has the following logical components: + + IN L32 + + In the above is the owner name string, is + an unsigned 16-bit value, and is an unsigned 32-bit + value. + + host1.example.com. IN L32 10 10.1.02.0 + host1.example.com. IN L32 20 10.1.04.0 + host2.example.com. IN L32 10 10.1.08.0 + + As L32 values have the same syntax and semantics as IPv4 routing + prefixes, when displayed for human readership, the values are + presented in the same dotted-decimal format as IPv4 addresses. An + example of this syntax is shown above. + + In the example above, the owner name is from an FQDN for an + individual host. host1.example.com has two L32 values, so + host1.example.com is multihomed. + + + + + +Atkinson, et al. Experimental [Page 9] + +RFC 6742 ILNP DNS November 2012 + + + Another example is when the owner name is that learned from an LP + record (see below for details of LP records). + + l32-subnet1.example.com. IN L32 10 10.1.02.0 + l32-subnet2.example.com. IN L32 20 10.1.04.0 + l32-subnet3.example.com. IN L32 30 10.1.08.0 + + In this example above, the owner name is for a subnetwork rather than + an individual node. + +2.2.4. Additional Section Processing + + To improve performance, ILNP-aware DNS servers and DNS resolvers MAY + attempt to return all NID, L64, and LP records for the same owner + name of the L32 RRset in the Additional section of the response, if + space permits. + +2.3. The L64 Resource Record + + The L64 resource record (RR) is used to hold unsigned 64-bit Locator + values for ILNPv6-capable nodes. + + L64 records are present only for ILNPv6-capable nodes. This + restriction is important; ILNP-capable nodes use the presence of L64 + records in the DNS to learn that a correspondent node is also + ILNPv6-capable. While erroneous L64 records in the DNS for a node + that is not ILNP-capable would not prevent communication, such + erroneous DNS records could increase the delay at the start of an IP + session. + + A given owner name might have zero or more L64 values at a given + time. An ILNPv6-capable host SHOULD have at least 1 Locator (i.e., + L64 or LP) DNS resource record while it is connected to the Internet. + An ILNPv6-capable multihomed host normally will have multiple Locator + values while multihomed. An IP host that is NOT ILNPv6-capable MUST + NOT have an L64 or LP record in its DNS entries. A node that is not + currently connected to the Internet might not have any L64 values in + the DNS associated with its owner name. + + A DNS owner name that is naming a subnetwork, rather than naming a + host, MAY have an L64 record as a wild-card entry, thereby applying + to entries under that DNS owner name. This deployment scenario + probably is most common if the named subnetwork is, was, or might + become, mobile. + + The type value for the L64 RR type is 106. + + + + + +Atkinson, et al. Experimental [Page 10] + +RFC 6742 ILNP DNS November 2012 + + + The L64 RR is class independent. + + The L64 RR has no special TTL requirements. + +2.3.1. The L64 RDATA Wire Format + + The RDATA for an L64 RR consists of: + + - a 16-bit Preference field + - a 64-bit Locator64 field + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + | Locator64 | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.3.1.1. The Preference Field + + The field is an unsigned 16-bit integer in network byte + order that indicates the owner name's relative preference for this + L64 record among other L64 records associated with this owner name. + Lower Preference values are preferred over higher Preference values. + +2.3.1.2. The Locator64 Field + + The field is an unsigned 64-bit integer in network byte + order that has the same syntax and semantics as a 64-bit IPv6 routing + prefix. + +2.3.2. L64 RR Presentation Format + + The presentation of the format of the RDATA portion is as follows: + + - The Preference field MUST be represented as a 16-bit unsigned + decimal integer. + + - The Locator64 field MUST be represented using the same syntax used + for AAAA records (i.e., groups of 4 hexadecimal digits separated by + colons). However, the 'compressed' display format (e.g., using + "::") that is specified in RFC 4291, Section 2.2 (2), MUST NOT be + used. This is done to avoid confusion with a 128-bit IPv6 address, + since the Locator64 is a 64-bit value, while the IPv6 address is a + 128-bit value. + + + +Atkinson, et al. Experimental [Page 11] + +RFC 6742 ILNP DNS November 2012 + + +2.3.3. L64 RR Examples + + An L64 record has the following logical components: + + IN L64 + + In the above, is the owner name string, is + an unsigned 16-bit value, while is an unsigned 64-bit + value. + + host1.example.com. IN L64 10 2001:0DB8:1140:1000 + host1.example.com. IN L64 20 2001:0DB8:2140:2000 + host2.example.com. IN L64 10 2001:0DB8:4140:4000 + + As L64 values have the same syntax and semantics as IPv6 routing + prefixes, when displayed for human readership, the values might + conveniently be presented in hexadecimal format, as above. + + In the example above, the owner name is from an FQDN for an + individual host. host1.example.com has two L64 values, so it will be + multihomed. + + Another example is when the owner name is that learned from an LP + record (see below for details of LP records). + + l64-subnet1.example.com. IN L64 10 2001:0DB8:1140:1000 + l64-subnet2.example.com. IN L64 20 2001:0DB8:2140:2000 + l64-subnet3.example.com. IN L64 30 2001:0DB8:4140:4000 + + Here, the owner name is for a subnetwork rather than an individual + node. + +2.3.4. Additional Section Processing + + To improve performance, ILNP-aware DNS servers and DNS resolvers MAY + attempt to return all NID, L32, and LP records for the same owner + name of the L64 RRset in the Additional section of the response, if + space permits. + +2.4. The LP Resource Record + + The LP DNS resource record (RR) is used to hold the name of a + subnetwork for ILNP. The name is an FQDN which can then be used to + look up L32 or L64 records. LP is, effectively, a Locator Pointer to + L32 and/or L64 records. + + + + + + +Atkinson, et al. Experimental [Page 12] + +RFC 6742 ILNP DNS November 2012 + + + As described in [RFC6740], the LP RR provides one level of + indirection within the DNS in naming a Locator value. This is useful + in several deployment scenarios, such as for a multihomed site where + the multihoming is handled entirely by the site's border routers + (e.g., via Locator rewriting) or in some mobile network deployment + scenarios [RFC6748]. + + LP records MUST NOT be present for owner name values that are not + ILNP-capable nodes. This restriction is important; ILNP-capable + nodes use the presence of LP records in the DNS to infer that a + correspondent node is also ILNP-capable. While erroneous LP records + in the DNS for an owner name would not prevent communication, + presence of such erroneous DNS records could increase the delay at + the start of an IP session. + + The type value for the LP RR type is 107. + + The LP RR is class independent. + + The LP RR has no special TTL requirements. + +2.4.1. LP RDATA Wire Format + + The RDATA for an LP RR consists of: + + - an unsigned 16-bit Preference field + - a variable-length FQDN field + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / + / / + / FQDN / + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +2.4.1.1. The Preference Field + + The field contains an unsigned 16-bit integer in network + byte order that indicates the owner name's relative preference for + this LP record among other LP records associated with this owner + name. Lower Preference values are preferred over higher Preference + values. + + + + + + +Atkinson, et al. Experimental [Page 13] + +RFC 6742 ILNP DNS November 2012 + + +2.4.1.2. The FQDN Field + + The variable-length FQDN field contains the DNS target name that is + used to reference L32 and/or L64 records. This field MUST NOT have + the same value as the owner name of the LP RR instance. + + A sender MUST NOT use DNS name compression on the FQDN field when + transmitting an LP RR. + +2.4.2. LP RR Presentation Format + + The presentation of the format of the RDATA portion is as follows: + + - The Preference field MUST be represented as a 16-bit unsigned + decimal integer. + + - The FQDN field MUST be represented as a domain name. + +2.4.3. LP RR Examples + + An LP record has the following logical components: + + IN LP + + In the above, is the owner name string, is + an unsigned 16-bit value, while is the domain name which + should be resolved further. + + host1.example.com. IN LP 10 l64-subnet1.example.com. + host1.example.com. IN LP 10 l64-subnet2.example.com. + host1.example.com. IN LP 20 l32-subnet1.example.com. + + In the example above, host1.example.com is multihomed on three + subnets. Resolving the FQDNs return in the LP records would allow + the actual subnet prefixes to be resolved, e.g., as in the examples + for the L32 and L64 RR descriptions, above. This level of + indirection allows the same L32 and/or L64 records to be used by many + hosts in the same subnetwork, easing management of the ILNP network + and potentially reducing the number of DNS Update transactions, + especially when that network is mobile [RAB09] or multihomed + [ABH09a]. + +2.4.4. Additional Section Processing + + To improve performance, ILNP-aware DNS servers and DNS resolvers MAY + attempt to return all L32 and L64 records for the same owner name of + the LP RRset in the Additional section of the response, if space + permits. + + + +Atkinson, et al. Experimental [Page 14] + +RFC 6742 ILNP DNS November 2012 + + +3. Deployment Example + + Given a domain name, one can use the Domain Name System (DNS) to + discover the set of NID records, the set of L32 records, the set of + L64 records, and the set of LP records that are associated with that + DNS owner name. + + For example: + + host1.example.com. IN NID 10 0014:4fff:ff20:ee64 + host1.example.com. IN L64 10 2001:0DB8:1140:1000 + + would be the minimum requirement for an ILNPv6 node that has owner + name host1.example.com and is connected to the Internet at the + subnetwork having routing prefix 2001:0DB8:1140:1000. + + If that host were multihomed on two different IPv6 subnets: + + host1.example.com. IN NID 10 0014:4fff:ff20:ee64 + host1.example.com. IN L64 10 2001:0DB8:1140:1000 + host1.example.com. IN L64 20 2001:0DB8:2140:2000 + + would indicate the Identifier and two subnets that host1.example.com + is attached to, along with the relative preference that a client + would use in selecting the Locator value for use in initiating + communication. + + If host1.example.com were part of a mobile network, a DNS query might + return: + + host1.example.com. IN NID 10 0014:4fff:ff20:ee64 + host1.example.com. IN LP 10 mobile-net1.example.com. + + and then a DNS query to find the current Locator value(s) for the + node named by the LP record: + + mobile-net1.example.com. IN L64 2001:0DB8:8140:8000 + +3.1. Use of ILNP Records + + As these DNS records are only used with the Identifier-Locator + Network Protocol (ILNP), these records MUST NOT be present for a node + that does not support ILNP. This lookup process is considered to be + in the "forward" direction. + + The Preference fields associated with the NID, L32, L64, and LP + records are used to indicate the owner name's preference for others + to use one particular NID, L32, L64, or LP record, rather than use + + + +Atkinson, et al. Experimental [Page 15] + +RFC 6742 ILNP DNS November 2012 + + + another NID, L32, L64, or LP record also associated with that owner + name. Lower Preference field values are preferred over higher + Preference field values. + + It is possible that a DNS stub resolver querying for one of these + record types will not receive all NID, L32, L64, and LP RR's in a + single response. Credible anecdotal reports indicate at least one + DNS recursive cache implementation actively drops all Additional Data + records that were not expected by that DNS recursive cache. So even + if the authoritative DNS server includes all the relevant records in + the Additional Data section of the DNS response, the querying DNS + stub resolver might not receive all of those Additional Data records. + DNS resolvers also might purge some ILNP RRsets before others, for + example, if NID RRsets have a longer DNS TTL value than Locator- + related (e.g., LP, L32, L64) RRsets. So a DNS stub resolver sending + queries to a DNS resolver cannot be certain if they have obtained all + available RRtypes for a given owner name. Therefore, the DNS stub + resolver SHOULD send follow-up DNS queries for RRTYPE values that + were missing and are desired, to ensure that the DNS stub resolver + receives all the necessary information. + + Note nodes likely either to be mobile or to be multihomed normally + will have very low DNS TTL values for L32 and L64 records, as those + values might change frequently. However, the DNS TTL values for NID + and LP records normally will be higher, as those values are not + normally impacted by node location changes. Previous trace-driven + DNS simulations from MIT [JSBM02] and more recent experimental + validation of operational DNS from U. of St Andrews [BA11] both + indicate deployment and use of very short DNS TTL values within + 'stub' or 'leaf' DNS domains is not problematic. + + An ILNP node MAY use any NID value associated with its DNS owner name + with any or all Locator (L32 or L64) values also associated with its + DNS owner name. + + Existing DNS servers that do not explicitly support the new DNS RRs + defined in this specification are expected to follow existing + standards for handling unknown DNS RRs [RFC3597]. + +3.2. Additional Section Processing + + For all the records above, Additional Section Processing MAY be used. + This is intended to improve performance for both the DNS client and + the DNS server. For example, a node sending DNS query for an NID + owner name, such as host1.example.com, would benefit from receiving + all ILNP DNS records related to that owner name being returned, as it + is quite likely that the client will need that information to + initiate an ILNP session. + + + +Atkinson, et al. Experimental [Page 16] + +RFC 6742 ILNP DNS November 2012 + + + However, this is not always the case: a DNS query for L64 for a + particular owner name might be made because the DNS TTL for a + previously resolved L64 RR has expired, while the NID RR for that + same owner name has a DNS TTL that has not expired. + +4. Security Considerations + + These new DNS resource record types do not create any new + vulnerabilities in the Domain Name System. + + Existing mechanisms for DNS Security can be used unchanged with these + record types [RFC4033] [RFC3007]. As of this writing, the DNS + Security mechanisms are believed to be widely implemented in + currently available DNS servers and DNS clients. Deployment of DNS + Security appears to be growing rapidly. + + In situations where authentication of DNS data is a concern, the DNS + Security extensions SHOULD be used [RFC4033]. + + If these DNS records are updated dynamically over the network, then + the Secure Dynamic DNS Update [RFC3007] mechanism SHOULD be used to + secure such transactions. + +5. IANA Considerations + + IANA has allocated each of the following DNS resource records + (described above in Section 2) a Data RRTYPE value according to the + procedures of Sections 3.1 and 3.1.1 of [RFC6195]. + + Type Value + ---- ----- + NID 104 + L32 105 + L64 106 + LP 107 + +6. References + +6.1. Normative References + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + +Atkinson, et al. Experimental [Page 17] + +RFC 6742 ILNP DNS November 2012 + + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record + (RR) Types", RFC 3597, September 2003. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "DNS Security Introduction and Requirements", RFC + 4033, March 2005. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC6195] Eastlake 3rd, D., "Domain Name System (DNS) IANA + Considerations", BCP 42, RFC 6195, March 2011. + + [RFC6740] Atkinson, R. and S. Bhatti, "Identifier-Locator Network + Protocol (ILNP) Architectural Description", RFC 6740, + November 2012. + + [RFC6741] Atkinson, R. and S. Bhatti, "Identifier-Locator Network + Protocol (ILNP) Engineering and Implementation + Considerations", RFC 6741, November 2012. + +6.2. Informative References + + [ABH09a] Atkinson, R., Bhatti, S. and S. Hailes, "Site-Controlled + Secure Multi-Homing and Traffic Engineering For IP", + Proceedings of IEEE Military Communications Conference, + IEEE, Boston, MA, USA, October 2009. + + [BA11] Bhatti, S. and R. Atkinson, "Reducing DNS Caching", + Proceedings of IEEE Global Internet Symposium (GI2011), + Shanghai, P.R. China. 15 April 2011. + + + [JSBM02] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS + performance and the effectiveness of caching", IEEE/ACM + Trans. Netw. 10(5) (October 2002), pp 589-603. + + + [PHG02] Pappas, A., Hailes, S. and R. Giaffreda, "Mobile Host + Location Tracking through DNS", IEEE London + Communications Symposium, London, England, UK, September + 2002. + + + + + + +Atkinson, et al. Experimental [Page 18] + +RFC 6742 ILNP DNS November 2012 + + + [RAB09] Rehunathan, D., Atkinson, R. and S. Bhatti, "Enabling + Mobile Networks Through Secure Naming", Proceedings of + IEEE Military Communications Conference (MILCOM), IEEE, + Boston, MA, USA, October 2009. + + [SB00] Snoeren, A. and H. Balakrishnan, "An End-To-End Approach + To Host Mobility", Proceedings of 6th Conference on + Mobile Computing and Networking (MobiCom), ACM, Boston, + MA, USA, August 2000. + + [SBK01] Snoeren, A., Balakrishnan, H., and M. Frans Kaashoek, + "Reconsidering Internet Mobility", Proceedings of 8th + Workshop on Hot Topics in Operating Systems (HotOS), IEEE + Computer Society, Elmau, Germany, May 2001. + + [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report + from the IAB Workshop on Routing and Addressing", RFC + 4984, September 2007. + + [RFC6743] Atkinson, R. and S. Bhatti, "ICMPv6 Locator Update + Message", RFC 6743, November 2012. + + [RFC6744] Atkinson, R. and S. Bhatti, "IPv6 Nonce Destination + Option for the Identifier-Locator Network Protocol for + IPv6 (ILNPv6)", RFC 6744, November 2012. + + [RFC6745] Atkinson, R. and S. Bhatti, "ICMP Locator Update Message + for the Identifier-Locator Network Protocol for IPv4 + (ILNPv4)", RFC 6745, November 2012. + + [RFC6746] Atkinson, R. and S.Bhatti, "IPv4 Options for the + Identifier-Locator Network Protocol (ILNP)", RFC 6746, + November 2012. + + [RFC6747] Atkinson, R. and S. Bhatti, "Address Resolution Protocol + (ARP) Extension for the Identifier-Locator Network + Protocol for IPv4 (ILNPv4)", RFC 6747, November 2012. + + [RFC6748] Atkinson, R. and S. Bhatti, "Optional Advanced Deployment + Scenarios for the Identifier-Locator Network Protocol + (ILNP)", RFC 6748, November 2012. + + + + + + + + + + +Atkinson, et al. Experimental [Page 19] + +RFC 6742 ILNP DNS November 2012 + + +7. Acknowledgements + + Steve Blake, Stephane Bortzmeyer, Mohamed Boucadair, Noel Chiappa, + Wes George, Steve Hailes, Joel Halpern, Mark Handley, Volker Hilt, + Paul Jakma, Dae-Young Kim, Tony Li, Yakov Rehkter, Bruce Simpson, + Robin Whittle, and John Wroclawski (in alphabetical order) provided + review and feedback on earlier versions of this document. Steve + Blake provided an especially thorough review of an early version of + the entire ILNP document set, which was extremely helpful. We also + wish to thank the anonymous reviewers of the various ILNP papers for + their feedback. + + Roy Arends provided expert guidance on technical and procedural + aspects of DNS issues, for which the authors are greatly obliged. + +Authors' Addresses + + RJ Atkinson + Consultant + San Jose, CA 95125 + USA + + EMail: rja.lists@gmail.com + + + SN Bhatti + School of Computer Science + University of St Andrews + North Haugh, St Andrews + Fife, Scotland + KY16 9SX, UK + + EMail: saleem@cs.st-andrews.ac.uk + + + Scott Rose + US National Institute for Standards & Technology + 100 Bureau Drive + Gaithersburg, MD 20899 + USA + + EMail: scottr.nist@gmail.com + + + + + + + + + +Atkinson, et al. Experimental [Page 20] + -- cgit v1.2.3