--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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 <to be assigned>.
+
+ 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]
+\f
+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 <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 [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]
+\f
+Internet Draft -6-29 MAY 2012
+
+
+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 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]
+\f
+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 <to be assigned>.
+
+ 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 <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
+
+
+
+Atkinson et alia Expires in 6 months [Page 7]
+\f
+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:
+ <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 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]
+\f
+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 <to be assigned>.
+
+ 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]
+\f
+Internet Draft -10-29 MAY 2012
+
+
+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+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.
+
+
+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
+
+
+
+
+Atkinson et alia Expires in 6 months [Page 10]
+\f
+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]
+\f
+Internet Draft -12-29 MAY 2012
+
+
+ The type value for the LP RR type is X-LP-X <to be assigned>.
+
+ 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 <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.
+
+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]
+\f
+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:
+ <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 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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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.
+ <http://dx.doi.org/10.1109/INFCOMW.2011.5928919>
+
+ [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.
+ <http://dx.doi.org/10.1109/TNET.2002.803905>
+
+ [PHG02] Andreas Pappas, Stephen Hailes, Raffaele Giaffreda,
+ "Mobile Host Location Tracking through DNS",
+ IEEE London Communications Symposium, London,
+ England, UK, September 2002.
+ <http://www.ee.ucl.ac.uk/lcs/papers2002/LCS072.pdf>
+
+ [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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+Internet Draft -22-29 MAY 2012
+
+
+ Expires: 29 NOV 2012
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson et alia Expires in 6 months [Page 22]
+\f
\ No newline at end of file
projects / thirdparty / bind9.git / commitdiff
