From: Mark Andrews Date: Fri, 1 Jun 2012 00:07:18 +0000 (+1000) Subject: new draft X-Git-Tag: v9.10.0a1~1177^2 X-Git-Url: http://git.ipfire.org/gitweb/?a=commitdiff_plain;h=fb672cba5ff2fe1c39ef755ce58650f1d67e6e23;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-irtf-rrg-ilnp-dns-05.txt b/doc/draft/draft-irtf-rrg-ilnp-dns-05.txt new file mode 100644 index 00000000000..840a8caede4 --- /dev/null +++ b/doc/draft/draft-irtf-rrg-ilnp-dns-05.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Draft RJ Atkinson +draft-irtf-rrg-ilnp-dns-05.txt Consultant +Expires: 29 NOV 2012 SN Bhatti +Category: Experimental U. St Andrews + Scott Rose + US NIST + 29 May 2012 + + + DNS Resource Records for ILNP + draft-irtf-rrg-ilnp-dns-05.txt + + +STATUS OF THIS MEMO + + Distribution of this memo is unlimited. + + 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. Code Components extracted from this + document must include Simplified BSD License text as described in + Section 4.e of the Trust Legal Provisions and are provided + without warranty as described in the Simplified BSD License. + + This Internet-Draft is submitted in full conformance with the + provisions of BCP 78 and BCP 79. + + This document may contain material from IETF Documents or + IETF Contributions published or made publicly available + before November 10, 2008. The person(s) controlling the + copyright in some of this material may not have granted the + IETF Trust the right to allow modifications of such material + outside the IETF Standards Process. Without obtaining an + adequate license from the person(s) controlling the copyright + in such materials, this document may not be modified outside + the IETF Standards Process, and derivative works of it may not + be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages + other than English. + + Internet-Drafts are working documents of the Internet + Engineering Task Force (IETF), its areas, and its working + + + +Atkinson et alia Expires in 6 months [Page 1] + +Internet Draft -2-29 MAY 2012 + + + groups. Note that other groups may also distribute working + documents as Internet-Drafts. + + 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." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/1id-abstracts.html + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + This document is not on the IETF standards-track and does not + specify any level of standard. This document merely provides + information for the Internet community. + + This document is part of the ILNP document set, which has had + extensive review within the IRTF Routing Research Group. 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. + +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 RG. + +TABLE OF CONTENTS + + 1. Introduction.............................2 + 2. New Resource Records.....................3 + 2.1 NID Resource Record.....................3 + 2.2 L32 Resource Record......................5 + 2.3 L64 Resource Record......................6 + 2.4 LP Resource Record.......................7 + 3. Usage Example............................8 + 4. Security Considerations..................9 + + + +Atkinson et alia Expires in 6 months [Page 2] + +Internet Draft -3-29 MAY 2012 + + + 5. IANA Considerations......................9 + 6. References...............................9 + +1. INTRODUCTION + + The Identifier-Locator Network Protocol (ILNP) was developed to + explore a possible evolutionary direction for the Internet + Architecture. An description of the ILNP architecture is + available in a separate document [ILNP-ARCH]. Implementation and + engineering details are largely isolated into a second document + [ILNP-ENG]. + + 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 have defined standards-track security + extensions to the DNS [RFC4033]. These security extensions can + be used to authenticate signed DNS data records and can also be + used to store signed public keys in the DNS. Further, the IETF + have 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]. + +1.1 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 + + + +Atkinson et alia Expires in 6 months [Page 3] + +Internet Draft -4-29 MAY 2012 + + + "OPTIONAL" in this document are to be interpreted as described + in RFC 2119 [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 resource record 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) [ILNP-ARCH]. + + 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 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 an node + that is not ILNP-capable would not prevent communication, such + erroneous DNS records could increase the delay at the start of an + IP communications session. + + 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 X-NID-X . + + The NID RR is class independent. + + The NID RR has no special 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 + + + +Atkinson et alia Expires in 6 months [Page 4] + +Internet Draft -5-29 MAY 2012 + + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 [RFC-4291, 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 MAY be used with *any + interface* of that node. + +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. + + + + + + +Atkinson et alia Expires in 6 months [Page 5] + +Internet Draft -6-29 MAY 2012 + + +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 Resource Record (RR) is used to hold 32-bit + Locator values for ILNPv4-capable nodes. + + 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 communications 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 multi-homed host normally + will have multiple Locator values while multi-homed. 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 + + + +Atkinson et alia Expires in 6 months [Page 6] + +Internet Draft -7-29 MAY 2012 + + + 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 X-L32-X . + + 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 + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +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 + + + +Atkinson et alia Expires in 6 months [Page 7] + +Internet Draft -8-29 MAY 2012 + + + 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 a FQDN for an + individual host. host1.example.com has two L32 values, so + host1.example.com is multi-homed. + + 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. + + + + + + + +Atkinson et alia Expires in 6 months [Page 8] + +Internet Draft -9-29 MAY 2012 + + +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 communications 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 multi-homed host normally + will have multiple Locator values while multi-homed. 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 X-L64-X . + + 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 + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 | + + + +Atkinson et alia Expires in 6 months [Page 9] + +Internet Draft -10-29 MAY 2012 + + + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +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. + + +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 + + + + +Atkinson et alia Expires in 6 months [Page 10] + +Internet Draft -11-29 MAY 2012 + + + 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 a FQDN for an + individual host. host1.example.com has two L64 values, so it will + be multi-homed. + + 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. + + As described in [ILNP-ARCH], 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 multi-homed + site where the multi-homing is handled entirely by the site's + border routers (e.g. via Locator rewriting) or in some mobile + network deployment scenarios [ILNP-ADV]. + + 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 a communications session. + + + + +Atkinson et alia Expires in 6 months [Page 11] + +Internet Draft -12-29 MAY 2012 + + + The type value for the LP RR type is X-LP-X . + + 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 LPP RR consists of: + + - an unsigned 16 bit Preference field + - a variable-length FQDN field + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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. + +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. + + +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 wire-encoded domain + name, as described in Section 3.3 of RFC 1035 [RFC1035]. The + + + +Atkinson et alia Expires in 6 months [Page 12] + +Internet Draft -13-29 MAY 2012 + + + wire-encoded format is self-describing, so the length is + implicit. The domain names MUST NOT be compressed. + + +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 multi-homed 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 + multi-homed [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. + + +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 + + + +Atkinson et alia Expires in 6 months [Page 13] + +Internet Draft -14-29 MAY 2012 + + + 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 multi-homed 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 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 + + + +Atkinson et alia Expires in 6 months [Page 14] + +Internet Draft -15-29 MAY 2012 + + + 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 multi-homed + 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. + + +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 communication session. + + 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 + + + +Atkinson et alia Expires in 6 months [Page 15] + +Internet Draft -16-29 MAY 2012 + + + 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 is requested to allocate each of these DNS Resource Records + + NID + L32 + L64 + LP + + (described above in Section 2) a Data RRTYPE value according to + the procedures of Section 3.1 and 3.1.1 on pages 7 through 9 of + RFC 6195 [RFC6195]. + +6. REFERENCES + + +6.1 Normative References + + [RFC1034] P. Mockapetris, "Domain names - Concepts and + Facilities", RFC-1034, 1 November 1987 + + [RFC1035] P. Mockapetris, "Domain names - Implementation and + Specification", RFC-1035, 1 November 1987. + + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC3007] B. Wellington, "Secure Domain Name System Dynamic + Update", RFC 3007, RFC Editor, November 2000. + + [RFC3597] A. Gustafsson, "Handling of Unknown DNS Resource + Record (RR) Types", RFC 3597, September 2003. + + [RFC4033] R. Arends, R. Austein, M. Larson, D. Massey, & + S. Rose, "DNS Security Introduction & Requirements", + RFC 4033, RFC Editor, March 2005. + + + + +Atkinson et alia Expires in 6 months [Page 16] + +Internet Draft -17-29 MAY 2012 + + + [RFC6195] D. Eastlake 3rd, "Domain Name System IANA + Considerations", RFC 6195, March 2011. + + [ILNP-ARCH] R.J. Atkinson & S.N. Bhatti, "ILNP Architecture", + draft-irtf-rrg-ilnp-arch, May 2012. + + [ILNP-ADV] R.J. Atkinson & S.N. Bhatti, + "Optional Advanced Deployment Scenarios for ILNP", + draft-irtf-rrg-ilnp-adv, May 2012 + + [ILNP-ENG] R. Atkinson & S. Bhatti, "ILNP Engineering and + Implementation Considerations", + draft-irtf-rrg-ilnp-eng, May 2012. + +6.2 INFORMATIVE REFERENCES + + [ABH09a] R. Atkinson, S. Bhatti, & S. Hailes, + "Site-Controlled Secure Multi-Homing and Traffic + Engineering For IP", Proc. MILCOM2009 - 28th IEEE + Military Communications Conference, Boston, MA, USA. + Oct 2009. + + [BA11] S. Bhatti & R. Atkinson, + "Reducing DNS Caching", + Proc. GI2011 - 14th IEEE Global Internet Symposium, + Shanghai, China. 15 Apr 2011. + + + [JSBM02] J. Jung, E. Sit, H. Balakrishnan, and R. Morris, + DNS performance and the effectiveness of caching. + IEEE/ACM Trans. Netw. 10(5) (October 2002), 589-603. + + + [PHG02] Andreas Pappas, Stephen Hailes, Raffaele Giaffreda, + "Mobile Host Location Tracking through DNS", + IEEE London Communications Symposium, London, + England, UK, September 2002. + + + [RAB09] D. Rehunthan, R. Atkinson, S. Bhatti, + "Enabling Mobile Networks Through Secure Naming", + Proc. MILCOM2009 - 28th IEEE Military Communications + Conference (MILCOM), Boston, MA, USA, Oct 2009 + + [SB00] Alex C. Snoeren and Hari Balakrishnan. 2000. + "An End-To-End Approach To Host Mobility", Proc. + 6th Conference on Mobile Computing And Networking + (MobiCom), ACM, Boston, MA, USA, pp. 155-166, + + + +Atkinson et alia Expires in 6 months [Page 17] + +Internet Draft -18-29 MAY 2012 + + + August 2000. + + [SBK01] Alex C. Snoeren, Hari Balakrishnan, & M. Frans + Kaashoek, "Reconsidering Internet Mobility", + Proceedings of 8th Workshop on Hot Topics in + Operating Systems (HotOS), IEEE Computer Society, + Washington, DC, USA, May 2001. + +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. + + +RFC EDITOR NOTE + + This section is to be removed prior to publication. + + Please note that this document is written in British English, so + British English spelling is used throughout. This is consistent + with existing practice in several other RFCs, for example + RFC-5887. + + This document tries to be very careful with history, in the + interest of correctly crediting ideas to their earliest + identifiable author(s). So in several places the first published + RFC about a topic is cited rather than the most recent published + RFC about that topic. + +Authors' Addresses: + + RJ Atkinson + Consultant + San Jose, CA + 95125 USA + + Email: rja.lists@gmail.com + + + + +Atkinson et alia Expires in 6 months [Page 18] + +Internet Draft -19-29 MAY 2012 + + + SN Bhatti + School of Computer Science + University of St Andrews + North Haugh, St Andrews + Fife, Scotland, UK + KY16 9SX + + 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 alia Expires in 6 months [Page 19] + +Internet Draft -20-29 MAY 2012 + + + [NOTE: Appendix A is to be removed by the + RFC Editor prior to publication.] + + Appendix A: + + + DNS RRTYPE PARAMETER ALLOCATION TEMPLATE + + When ready for formal consideration, this template is + to be submitted to IANA for processing by emailing the + template to dns-rrtype-applications@ietf.org. + + A. Submission Date: To be determined. + + B. Submission Type: + [X] New RRTYPE + + C. Contact Information for submitter: + Name: R. Atkinson + Email Address: rja.lists@gmail.com + International telephone number: unlisted + Other contact handles: + + D. Motivation for the new RRTYPE application? + + Support for an experimental set of IP extensions + that replace the concept of an "IP Address" with + distinct "Locator" and "Identifier" values. + + E. Description of the proposed RR type. + + Please see: + + http://tools.ietf.org/id/draft-irtf-rrg-ilnp-dns-03.txt + + for a full description. + + F. What existing RRTYPE or RRTYPEs come closest to filling + that need and why are they unsatisfactory? + + There is no RRTYPE that fulfils the need due to the + new semantics of Locator and Identifier values. + + The AAAA record combines both Locator and Identifier, + so has significantly different semantics than having + separate L64 and NID record values. The AAAA record also + lacks scalability and flexibility in the context of the + experimental protocol extensions that will use the NID + + + +Atkinson et alia Expires in 6 months [Page 20] + +Internet Draft -21-29 MAY 2012 + + + and L64 records, as any valid NID record value for a node + can be used on the wire with any valid L64 record value + for the same node. + + The CNAME record is closest conceptually to an LP + record, but a CNAME is a node name referral scheme, + while the LP record is indicating that the given node + has the same routing prefix as some other domain name, + but does not necessarily have any other values that are + the same. + + Lastly, the AAAA and CNAME RR Types lack a Preference + field to rank responses. Such Preference information + is required for ILNP in order to support the use of multiple + instances of NID, L32, L64 and LP records. + + G. What mnemonic is requested for the new RRTYPE (optional)? + + As described in this draft, "NID", "L32", "L64", and "LP". + + H. Does the requested RRTYPE make use of any existing IANA + Registry or require the creation of a new IANA + sub-registry in DNS Parameters? + + Existing registry of DNS Resource Record (RR) data TYPE + values should be used. + + I. Does the proposal require/expect any changes in DNS + servers/resolvers that prevent the new type from being + processed as an unknown RRTYPE (see [RFC3597]) ? + + No. + + J. Comments: + This document defines "ILNP-aware" DNS servers + or DNS resolver as a DNS server (authoritative or recursive) + that MAY include other ILNP RRTypes in the Additional + section of a DNS response that match a QNAME (if + size permits). This is to reduce the number of + DNS stub resolver follow-up DNS queries. and only applies + when the QTYPE is either NID, L32, L64, or LP. There is no + signalling mechanism for this Additional section + processing, and this is believed to be compatible + with existing non-ILNP-aware DNS servers and DNS stub + resolvers. + + No changes are required for existing deployed + DNS servers or DNS resolvers. + + + +Atkinson et alia Expires in 6 months [Page 21] + +Internet Draft -22-29 MAY 2012 + + + Expires: 29 NOV 2012 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Atkinson et alia Expires in 6 months [Page 22] + \ No newline at end of file