doc: Add RFC documents

1 files changed, 1123 insertions, 0 deletions

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 <Preference> 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:
+
+     <owner-name>  IN  NID  <Preference>   <NodeID>
+
+   In the above, <owner-name> is the owner name string, <Preference> is
+   an unsigned 16-bit value, and <NodeID> 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 <Preference> 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 <Locator32> 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:
+
+     <owner-name>  IN  L32  <Preference>   <Locator32>
+
+   In the above <owner-name> is the owner name string, <Preference> is
+   an unsigned 16-bit value, and <Locator32> 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 <Preference> 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 <Locator64> 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:
+
+        <owner-name>  IN  L64  <Preference>   <Locator64>
+
+   In the above, <owner-name> is the owner name string, <Preference> is
+   an unsigned 16-bit value, while <Locator64> 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 <Preference> 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:
+
+        <owner-name>  IN  LP  <Preference>   <FQDN>
+
+   In the above, <owner-name> is the owner name string, <Preference> is
+   an unsigned 16-bit value, while <FQDN> 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.
+               <http://dx.doi.org/10.1109/INFCOMW.2011.5928919>
+
+   [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.
+               <http://dx.doi.org/10.1109/TNET.2002.803905>
+
+   [PHG02]     Pappas, A., Hailes, S. and R. Giaffreda, "Mobile Host
+               Location Tracking through DNS", IEEE London
+               Communications Symposium, London, England, UK, September
+               2002.
+               <http://www.ee.ucl.ac.uk/lcs/previous/LCS2002/LCS072.pdf>
+
+
+
+
+
+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]
+