Internet Draft R. Atkinson draft-rja-ilnp-dns-05.txt Consultant Expires: 24 DEC 2010 24 June 2010 Category: Experimental DNS Resource Records for ILNP draft-rja-ilnp-dns-05.txt STATUS OF THIS MEMO Distribution of this memo is unlimited. Copyright (c) 2010 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 groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six Atkinson Expires in 6 months [Page 1]
Internet Draft ILNP DNS 24 JUN 2010 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 has had extensive review within the IRTF Routing Research Group, and is part of the ILNP document set. Also, 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 also have had broader review than just the IRTF Routing RG. 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 is a product of the IRTF Routing RG. TABLE OF CONTENTS 1. Introduction.............................2 2. New Resource Records.....................3 2.1 ID 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 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 introduction to ILNP is available in a separate document. [ILNP-Intro] Atkinson Expires in 6 months [Page 2]
Internet Draft ILNP DNS 24 JUN 2010 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. [RFC 1034] [RFC 1035] More recently, the IETF have defined standards-track security extensions to the DNS. [RFC 4033] 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. [RFC 3007] 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 [RFC 1034] [RFC 1035]. 1.1 Terminology 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 RFC 2119. [RFC 2119] 2. NEW RESOURCE RECORDS This document specifies several new and closely related DNS data Resource Records (RRs). These new RR types have the mnemonics "ID", "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-Intro] 2.1 "ID" Resource Record An ID record has the following logical components: <owner-name> IN ID <preference> <I> An "ID" record has the DNS TYPE of ID and a numeric value of <to be assigned by IANA>. An ID record is a member of the Internet ("IN") CLASS in the DNS. Each ID record is associated with a owner name entry in the DNS. ID records are present only for owner name values that are ILNP-capable nodes. This restriction is important; ILNP-capable nodes use the presence of ID records in the DNS to learn that a correspondent node is also ILNP-capable. While erroneous ID Atkinson Expires in 6 months [Page 3]
Internet Draft ILNP DNS 24 JUN 2010 records in the DNS for an owner name 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. Of course, a particular node's owner name might have an ID record in the DNS and yet that node might be temporarily disconnected from the Internet. The Preference field indicates the owner name's relative preference for this ID record among other ID records associated with this owner-name. Lower preference values are preferred over higher preference values. In the above <owner-name> is the owner name string, while <I> is an unsigned 64-bit value. A given owner name may have zero or more ID records at a given time. In normal operation, nodes that support the Identifier-Locator Network Protocol (ILNP) will have at least one valid ID record. The ID DNS record has the following RDATA format: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Preference | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | ID | | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: Preference A 16-bit unsigned integer which specifies the preference given to this RR among others at the same owner. Lower Preference values are preferred over higher Preference values. ID A 64-bit unsigned integer. Server and Cache implementations are encouraged to return all L32, L64, and LP records associated with the owner name as additional data present in the ID record reply, if space permits in the DNS reply message. Atkinson Expires in 6 months [Page 4]
Internet Draft ILNP DNS 24 JUN 2010 2.2 "L32" Resource Record An "L32" record has the DNS TYPE of "L32" and a numeric value of <to be assigned by IANA>. An L32 record is a member of the Internet ("IN") CLASS in the DNS. Each L32 record is associated with an owner name entry in the DNS. The Preference field indicates the owner name's relative preference for this particular L32 record among other L32 records for the same owner name. An L32 record has the following logical components: <owner-name> IN L32 <preference> <L> In the above, <owner-name> is the owner name, <preference> is an unsigned 16-bit value, while <L> is an unsigned 32-bit value that names a subnetwork where the owner is directly attached. A given owner name might have zero or more L32 values at a given time. An ILNP-capable IPv4 host SHOULD have at least 1 L32 record while it is connected to the Internet. An ILNP-capable multi-homed IPv4 host normally will have multiple L32 values while multi-homed. An IPv4 host that is NOT ILNP-capable MUST NOT have an L32 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>. An owner name that is naming a subnetwork, rather than naming a host, MAY have an L32 record as a wild-card entry. This deployment scenario probably is most common if the named subnetwork is, was, or might become, mobile. The Preference field 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. The L32 DNS record has the following RDATA format: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Preference | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | L32 | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: Atkinson Expires in 6 months [Page 5]
Internet Draft ILNP DNS 24 JUN 2010 Preference A 16-bit unsigned integer which specifies the preference given to this RR among others at the same owner. Lower Preference values are preferred over higher Preference values. L32 A 32-bit unsigned integer that names a subnetwork. As a performance optimisation, to reduce offered DNS query load on the server, DNS server implementations are encouraged to return all ID records and LP records for the same owner name if space permits in the DNS reply message to an L32 query. 2.3 "L64" Resource Record An "L64" record has the DNS TYPE of "L64" and a numeric value of <to be assigned by IANA>. An L64 record is a member of the Internet ("IN") CLASS in the DNS. Each L64 record is associated with an owner name entry in the DNS. The Preference field indicates the owner name's relative preference for this particular L64 record among other L64 records for the same owner name. An L64 record has the following logical components: <owner-name> IN L64 <preference> <L> In the above, <owner-name> is the owner name, <preference> is an unsigned 16-bit value, while <L> is an unsigned 64-bit value that names a subnetwork where <owner-name> is directly attached. A given owner name may have zero or more L64 values at a given time. An ILNP-capable multi-homed host will normally have multiple L64 values while multi-homed. An owner name that is naming a subnetwork, rather than naming a host, MAY have an L64 record as a wild-card entry. This deployment scenario is most common if the named subnetwork is, was, or might become, mobile. A owner name that names a single node will NOT have an L64 record in the DNS -- unless that node is ILNP-capable. A node that is not currently connected to the Internet commonly might not have any L64 values in the DNS associated with its owner name. The Preference field 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. Atkinson Expires in 6 months [Page 6]
Internet Draft ILNP DNS 24 JUN 2010 The L64 DNS record has the following RDATA format: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Preference | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | | L64 | | | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: Preference A 16-bit unsigned integer which specifies the preference given to this RR among others at the same owner. Lower Preference values are preferred over higher Preference values. L64 A 64-bit unsigned integer that names a subnetwork. As a performance optimisation, to reduce the offered DNS query load upon the server, DNS servers are encouraged to return also all ID and LP records that belong to the owner name as Additional Data in the DNS reply message to the L64 query, if space permits. 2.4 "LP" Resource Record An "LP" record has the following logical components: <owner-name> IN LP <preference> <target-name> An LP record has the DNS TYPE of LP and a numeric value of <to be assigned by IANA>. An LP record is a member of the Internet ("IN") CLASS in the DNS. Each LP record is associated with an owner name entry in the DNS, and points to a second Fully-Qualified Domain Name (shown above as <target-name>). LP records SHOULD only be present for owner name values that are 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, those erroneous DNS records could increase the delay at the start of a communications session. Of course, a particular node might have an LP record in the Atkinson Expires in 6 months [Page 7]
Internet Draft ILNP DNS 24 JUN 2010 DNS and yet temporarily be disconnected from the Internet. The Preference field indicates the owner name's relative preference for this LP record among other L32, L64, and LP records associated with this owner name. Lower values are preferred. In the above <owner-name> is the owner name, while <target-name> is any other valid domain name string. It is invalid to have an LP record with the same value in both the <owner-name> and <target-name> values. A given owner name will have zero or more LP records at a given time. The LP DNS record has the following RDATA format: +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Preference | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / FQDN / / / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: Preference A 16-bit unsigned integer which specifies the preference given to this RR among others at the same owner. Lower Preference values are preferred over higher Preference values. FQDN A Fully-Qualified Domain Name that has one or more L64 records in the DNS. This is referred to as the <target-name> above. 3. USAGE EXAMPLE Given a domain name, one can use the Domain Name System (DNS) to discover the set of ID records, the set of L32 records, the set of L64 records, and the set of LP records that are associated with that owner name. 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. Atkinson Expires in 6 months [Page 8]
Internet Draft ILNP DNS 24 JUN 2010 The Preference fields associated with the ID, L32, L64, and LP records are used to indicate the owner name's preference for others to use one particular ID, L32, L64, or LP record, rather than use another ID, L32, L64, or LP record also associated with that owner-name. Lower Preference field values are preferred over higher Preference field values. In the event that a client querying for one of these record type does not receive all ID, L32, L64, and LP RR's in a response, the client SHOULD send follow-up DNS queries for RRTYPE that was missing and is desired, to insure that the client receives all the necessary information. Credible anecdotal reports indicate at least one DNS recursive cache implementation actively drops 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 client might not receive all of those Additional Data records. 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. [RFC 4033] [RFC 3007] As of this writing, those mechanisms are believed to be widely implemented in currently available DNS servers. In situations where authentication of DNS data is a concern, the DNS Security extensions SHOULD be used. [RFC 4033] If these DNS records are updated dynamically over the network, then the Secure Dynamic DNS Update [RFC 3007] mechanism SHOULD be used to secure such transactions. 5. IANA CONSIDERATIONS IANA is requested to allocate each of these DNS Resource Records (enumerated 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 5395. [RFC 5395] 6. REFERENCES 6.1 Normative References Atkinson Expires in 6 months [Page 9]
Internet Draft ILNP DNS 24 JUN 2010 [RFC 1034] P. Mockapetris, "Domain names - Concepts and Facilities", RFC-1034, 1 November 1987 [RFC 1035] P. Mockapetris, "Domain names - Implementation and Specification", RFC-1035, 1 November 1987. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 3007] B. Wellington, "Secure Domain Name System Dynamic Update", RFC 3007, RFC Editor, November 2000. [RFC 3597] A. Gustafsson, "Handling of Unknown DNS Resource Record (RR) Types", RFC 3597, September 2003. [RFC 4033] R. Arends, R. Austein, M. Larson, D. Massey, & S. Rose, "DNS Security Introduction & Requirements", RFC 4033, RFC Editor, March 2005. [RFC 5395] D. Eastlake 3rd, "Domain Name System IANA Considerations", RFC 5395, November 2008. 6.2 INFORMATIVE REFERENCES [ILNP-Intro] R. Atkinson, "ILNP Concept of Operations", draft-rja-ilnp-intro-04.txt, June 2010. 7. ACKNOWLEDGEMENTS Mohamed Boucadair, Noel Chiappa, Saleem Bhatti, Steve Hailes, Joel Halpern, Mark Handley, Tony Li, Yakov Rehkter, and Scott Rose (in alphabetical order) provided review and feedback on earlier versions of this document. AUTHOR'S ADDRESS: R. Atkinson Consultant McLean, VA 22102 USA Email: rja.lists@gmail.com Atkinson Expires in 6 months [Page 10]
Internet Draft ILNP DNS 24 JUN 2010 [NOTE: This section is to be removed by RFC Editor prior to publication.] 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 draft-rja-ilnp-dns-02.txt for a full description. F. What existing RRTYPE or RRTYPEs come closest to filling that need and why are they unsatisfactory? The AAAA record combines both Locator and Identifier, so has significantly different semantics than having separate L64 and ID record values. The AAAA record also lacks scalability and flexibility in the context of the experimental protocol extensions that will use the ID and L64 records, as any valid ID 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 Atkinson Expires in 6 months [Page 11]
Internet Draft ILNP DNS 24 JUN 2010 the same. G. What mnemonic is requested for the new RRTYPE (optional)? As described in this draft, "ID", "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 [RFC 3597])? No. J. Comments: Expires: 24 AUG 2010 Atkinson Expires in 6 months [Page 12]