diff --git a/doc/draft/draft-ietf-dnsext-dnssec-records-00.txt b/doc/draft/draft-ietf-dnsext-dnssec-records-01.txt similarity index 72% rename from doc/draft/draft-ietf-dnsext-dnssec-records-00.txt rename to doc/draft/draft-ietf-dnsext-dnssec-records-01.txt index 03b95d793e..97b31a1f69 100644 --- a/doc/draft/draft-ietf-dnsext-dnssec-records-00.txt +++ b/doc/draft/draft-ietf-dnsext-dnssec-records-01.txt @@ -1,16 +1,18 @@ -Network Working Group R. Arends + + +DNS Extensions R. Arends Internet-Draft Nominum -Expires: August 23, 2002 M. Larson +Expires: August 2, 2002 M. Larson VeriSign D. Massey USC/ISI S. Rose NIST - February 22, 2002 + February 2002 Resource Records for DNS Security Extensions - draft-ietf-dnsext-dnssec-records-00 + draft-ietf-dnsext-dnssec-records-01 Status of this Memo @@ -33,7 +35,7 @@ Status of this Memo The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on August 23, 2002. + This Internet-Draft will expire on August 2, 2002. Copyright Notice @@ -50,7 +52,7 @@ Abstract -Arends, et al. Expires August 23, 2002 [Page 1] +Arends, et al. Expires August 2, 2002 [Page 1] Internet-Draft DNSSEC Resource Records February 2002 @@ -76,7 +78,7 @@ Table of Contents 2.2 The KEY RR Presentation Format . . . . . . . . . . . . . . 7 2.3 KEY RR Examples . . . . . . . . . . . . . . . . . . . . . 7 2.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 7 - 2.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 7 + 2.3.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 8 3. The SIG Resource Record . . . . . . . . . . . . . . . . . 9 3.1 The SIG RDATA . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1 The Type Covered Field . . . . . . . . . . . . . . . . . . 10 @@ -94,25 +96,32 @@ Table of Contents 4.1.1 The Next Domain Name Field . . . . . . . . . . . . . . . . 13 4.1.2 The Type Bit Map Field . . . . . . . . . . . . . . . . . . 13 4.2 The NXT RR Presentation Format . . . . . . . . . . . . . . 14 - 5. The DS Resource Record (placeholder) . . . . . . . . . . . 15 - 6. DNSSEC message bits . . . . . . . . . . . . . . . . . . . 16 - 6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 16 - 6.2 The DO Extended Flags Field Bit . . . . . . . . . . . . . 16 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 - 8. Security Considerations . . . . . . . . . . . . . . . . . 19 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 20 - References . . . . . . . . . . . . . . . . . . . . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . 22 + 5. The DS Resource Record . . . . . . . . . . . . . . . . . . 15 + 5.1 DS RDATA Wire Format . . . . . . . . . . . . . . . . . . . 15 + 5.1.1 The Key Tag Field . . . . . . . . . . . . . . . . . . . . 15 + 5.1.2 The Algorithm Field . . . . . . . . . . . . . . . . . . . 15 + 5.1.3 The Digest Type Field . . . . . . . . . . . . . . . . . . 16 + 5.1.4 The Digest Field . . . . . . . . . . . . . . . . . . . . . 16 + 5.2 DS Record Example . . . . . . . . . . . . . . . . . . . . 16 + 5.3 Resolver Example . . . . . . . . . . . . . . . . . . . . . 16 + 6. DNSSEC message bits . . . . . . . . . . . . . . . . . . . 18 -Arends, et al. Expires August 23, 2002 [Page 2] +Arends, et al. Expires August 2, 2002 [Page 2] Internet-Draft DNSSEC Resource Records February 2002 - A. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 23 - Full Copyright Statement . . . . . . . . . . . . . . . . . 24 + 6.1 The AD and CD Header Bits . . . . . . . . . . . . . . . . 18 + 6.2 The DO Extended Flags Field Bit . . . . . . . . . . . . . 18 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . 20 + 8. Security Considerations . . . . . . . . . . . . . . . . . 21 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 22 + References . . . . . . . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . 24 + A. Key Tag Calculation . . . . . . . . . . . . . . . . . . . 25 + Full Copyright Statement . . . . . . . . . . . . . . . . . 26 @@ -155,14 +164,7 @@ Internet-Draft DNSSEC Resource Records February 2002 - - - - - - - -Arends, et al. Expires August 23, 2002 [Page 3] +Arends, et al. Expires August 2, 2002 [Page 3] Internet-Draft DNSSEC Resource Records February 2002 @@ -218,7 +220,7 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 4] +Arends, et al. Expires August 2, 2002 [Page 4] Internet-Draft DNSSEC Resource Records February 2002 @@ -274,7 +276,7 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 5] +Arends, et al. Expires August 2, 2002 [Page 5] Internet-Draft DNSSEC Resource Records February 2002 @@ -292,8 +294,7 @@ Internet-Draft DNSSEC Resource Records February 2002 2.1.2 The Protocol Octet Field - The Protocol Octet value MUST be 3. Name servers and resolvers - SHOULD reject KEY records with a Protocol Octet value other than 3. + The Protocol Octet value MUST be 3. 2.1.2.1 Explanation for a Fixed Value Protocol Octet Field @@ -315,7 +316,7 @@ Internet-Draft DNSSEC Resource Records February 2002 1 RSA/MD5 RFC 2536 NOT RECOMMENDED 2 Diffie-Hellman RFC 2539 OPTIONAL 3 DSA RFC 2536 MANDATORY - 4 elliptic curve - reserved + 4 elliptic curve Work in Progress 5 RSA/SHA1 RFC 3110 MANDATORY 6-251 available for assignment - 252 reserved - indirect keys @@ -323,18 +324,39 @@ Internet-Draft DNSSEC Resource Records February 2002 254 private - OID 255 reserved - - - EDITORS NOTE: indirect keys (252), private keys 253/254 and the - implication of making a key MANDATORY need further clarification. - This clarification will be in the next version of this document. + It is expected that a signed zone will contain at least one KEY + record with one of the MANDATORY algorithms. A DNS security aware + resolver MUST implement all MANDATORY and SHOULD implement all + OPTIONAL algorithms. Currently RSA/MD5 is NOT RECOMMENDED for zone + signing, but it may be found in older DNS implementations. - -Arends, et al. Expires August 23, 2002 [Page 6] +Arends, et al. Expires August 2, 2002 [Page 6] Internet-Draft DNSSEC Resource Records February 2002 + Therefore, if may be useful for a security aware resolver to + implement RSA/MD5 as well as RSA/SHA1. + + Algorithm number 252 is reserved for indirect key format where the + actual key material is elsewhere (non-DNS). This format will be + defined in a separate document. + + Algorithm numbers 253 and 254 are reserved for private use and will + never be assigned a specific algorithm. For number 253, the public + key area and the signature begin with a wire encoded domain name + indicating the algorithm the key uses. Only local domain name + compression is permitted. The remainder of the public key area is + privately defined. For number 254, the public key area for the KEY + RR and the signature begin with an unsigned length byte followed by a + BER encoded Object Identifier (ISO OID) of that length. The OID + indicates the private algorithm in use and the remainder of the area + is whatever is required by that algorithm. Entities should only use + domain names and OIDs they control to designate their private + algorithms. + 2.2 The KEY RR Presentation Format A KEY RR may appear as a single line. The presentation format of the @@ -363,6 +385,14 @@ Internet-Draft DNSSEC Resource Records February 2002 256 indicates the flags field has the zone key bit is set. 3 is the fixed Protocol Octet value. 5 indicates the public key algorithm is RSA/SHA1 RFC 3110]. The remaining text is base 64 encoding of the + + + +Arends, et al. Expires August 2, 2002 [Page 7] + +Internet-Draft DNSSEC Resource Records February 2002 + + public key and the format of the public key is defined in [12]. Resolvers might use this public key to authenticate signed RR sets @@ -383,14 +413,6 @@ Internet-Draft DNSSEC Resource Records February 2002 the public key and the format of the public key is defined in [7]. This public key can be used to sign dynamic DNS updates for the - - - -Arends, et al. Expires August 23, 2002 [Page 7] - -Internet-Draft DNSSEC Resource Records February 2002 - - isi.edu zone. The process is for signing the dynamic DNS updates is described in [11]. @@ -422,27 +444,7 @@ Internet-Draft DNSSEC Resource Records February 2002 - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 23, 2002 [Page 8] +Arends, et al. Expires August 2, 2002 [Page 8] Internet-Draft DNSSEC Resource Records February 2002 @@ -498,7 +500,7 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 9] +Arends, et al. Expires August 2, 2002 [Page 9] Internet-Draft DNSSEC Resource Records February 2002 @@ -554,7 +556,7 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 10] +Arends, et al. Expires August 2, 2002 [Page 10] Internet-Draft DNSSEC Resource Records February 2002 @@ -610,7 +612,7 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 11] +Arends, et al. Expires August 2, 2002 [Page 11] Internet-Draft DNSSEC Resource Records February 2002 @@ -666,7 +668,7 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 12] +Arends, et al. Expires August 2, 2002 [Page 12] Internet-Draft DNSSEC Resource Records February 2002 @@ -686,7 +688,7 @@ Internet-Draft DNSSEC Resource Records February 2002 The type number for the NXT RR is 30. - The NXT RR is class independant. + The NXT RR is class independent. The NXT RR TTL SHOULD NOT exceed the zone minimum TTL. @@ -722,7 +724,7 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 13] +Arends, et al. Expires August 2, 2002 [Page 13] Internet-Draft DNSSEC Resource Records February 2002 @@ -778,15 +780,165 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 14] +Arends, et al. Expires August 2, 2002 [Page 14] Internet-Draft DNSSEC Resource Records February 2002 -5. The DS Resource Record (placeholder) +5. The DS Resource Record - [This section will be finalised once DS has WG consensus and is - proposed standard] + The DS record is a major change to DNS: it is the first resource + record that can appear only on the upper side of a delegation. Other + keys MAY sign the child's apex KEY RRset. DS records MUST point to + zone KEY records that are allowed to authenticate DNS data. + + The type number for the DS record is 43. + + The DS record is class independent. + +5.1 DS RDATA Wire Format + + This record contains these fields: key tag, algorithm, digest type, + and the digest of a public key KEY record that is allowed and/or used + to sign the child's apex KEY RRset. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | key tag | algorithm | Digest type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Digest | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (20 bytes for SHA-1) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +5.1.1 The Key Tag Field + + The key tag value is the same key tag value in the SIG RRs generated + using the KEY record this DS record points too. Having the key tag + in the RDATA provides additional reliability in matching than just + the KEY digest alone. See the key tag for details. + +5.1.2 The Algorithm Field + + The algorithm value has the same defined values as the KEY and SIG + records. The value MUST be an algorithm number assigned in the range + 1..251 and the algorithm MUST be allowed to sign DNS data. + + + + +Arends, et al. Expires August 2, 2002 [Page 15] + +Internet-Draft DNSSEC Resource Records February 2002 + + +5.1.3 The Digest Type Field + + The digest type is an identifier for the digest algorithm used. The + following numbers have been assigned and the assignment of future + numbers requires IETF standards action. + + VALUE Algorithm STATUS + 0 Reserved - + 1 RSA/SHA-1 MANDATORY + 2-255 Unassigned - + + + +5.1.4 The Digest Field + + The digest is calculated over the canonical name of the delegated + domain name followed by the whole RDATA of the KEY record (all four + fields). The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, + regardless of key size. Other digest algorithms may have a differing + digest size, to be described in other documents. + + digest = hash( cannonical FQDN on KEY RR | KEY_RR_rdata) + + KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key + + +5.2 DS Record Example + + The presentation format of the DS record consists of three numbers + (key tag, algorithm and digest type) followed by the digest itself + presented in hex: + + example. DS 12345 3 1 123456789abcdef67890123456789abcdef67890 + + This is a example of a KEY record and corresponding DS record. + + dskey.example. KEY 256 3 1 ( + encoded public key + ) ; key id = 28668 + DS 28668 1 1 49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE + + +5.3 Resolver Example + + To create a chain of trust, a resolver goes from trusted KEY to DS to + KEY. + + Assume the key for domain "example." is trusted. Zone "example." + + + +Arends, et al. Expires August 2, 2002 [Page 16] + +Internet-Draft DNSSEC Resource Records February 2002 + + + contains at least the following records: + example. SOA (soa stuff) + example. NS ns.example. + example. KEY (encoded public key) + example. NXT NS SOA KEY SIG NXT + example. SIG(SOA) + example. SIG(NS) + example. SIG(NXT) + example. SIG(KEY) + secure.example. NS ns1.secure.example. + secure.example. DS tag=10243 alg=3 digest_type=1 + secure.example. NXT NS SIG NXT DS unsecure.example. + secure.example. SIG(NXT) + secure.example. SIG(DS) + unsecure.example NS ns1.unsecure.example. + unsecure.example. NXT NS SIG NXT .example. + unsecure.example. SIG(NXT) + + In zone "secure.example." following records exist: + secure.example. SOA (soa stuff) + secure.example. NS ns1.secure.example. + secure.example. KEY (tag=12345 alg=3) + secure.example. SIG(KEY) (key-tag=12345 alg=3) + secure.example. SIG(SOA) (key-tag=12345 alg=3) + secure.example. SIG(NS) (key-tag=12345 alg=5) + + + In this example the private key for "example." signs the DS record + for "secure.example.", making that a secure delegation. The DS + record states which key is expected to sign the RRsets at + "secure.example.". Here "secure.example." signs its KEY RRset with + the KEY identified in the DS RRset, thus the KEY RRset is validated + and trusted. + + This example has only one DS record for the child, but parents MUST + allow multiple DS records to facilitate key rollover. It is strongly + recommended that the DS RRset be kept small: two or three DS records + should be sufficient in all cases. + + The resolver determines the security status of "unsecure.example." by + examining the parent zone's NXT record for this name. The absence of + the DS bit indicates an unsecure delegation. @@ -796,45 +948,7 @@ Internet-Draft DNSSEC Resource Records February 2002 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 23, 2002 [Page 15] +Arends, et al. Expires August 2, 2002 [Page 17] Internet-Draft DNSSEC Resource Records February 2002 @@ -890,7 +1004,7 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 16] +Arends, et al. Expires August 2, 2002 [Page 18] Internet-Draft DNSSEC Resource Records February 2002 @@ -946,7 +1060,7 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 17] +Arends, et al. Expires August 2, 2002 [Page 19] Internet-Draft DNSSEC Resource Records February 2002 @@ -956,6 +1070,27 @@ Internet-Draft DNSSEC Resource Records February 2002 This document clarifies the use of existing types and introduces no new IANA considerations. + The definitions of the flag bits in the KEY RR are set by working + group consensus and there is no IANA registry for their definition. + Changes to the meaning of the bits in the flags section of the KEY + RDATA must be done through working group consensus. + + RFC 2535 created an IANA registry for DNSSEC Resource Record + algorithm Octet values. Values to 1-5, and 255 were assigned and + values 6-254 were made available for assignment by IANA. This + document re-assigns DNS KEY Resource Record Protocol Octet values 1, + 2, 4, and 255 to ``reserved''. DNS Key Resource Record Protocol + Octet Value 3 remains unchanged as ``DNSSEC''. + + New protocol values are no longer available for assignment by IANA + and this document closes the IANA registry for DNS KEY Resource + Record Protocol Octet Values. Assignment of any future KEY Resource + Record Protocol Octet values requires a standards action. New + numbers for algorithm values will continue to be assigned by IANA. + + IANA needs to open a new registry for the DS RR type digest + algorithms. Defined types are: 0 is Reserved, 1 is SHA-1. Adding + new reservations requires IETF standards action. @@ -981,28 +1116,7 @@ Internet-Draft DNSSEC Resource Records February 2002 - - - - - - - - - - - - - - - - - - - - - -Arends, et al. Expires August 23, 2002 [Page 18] +Arends, et al. Expires August 2, 2002 [Page 20] Internet-Draft DNSSEC Resource Records February 2002 @@ -1010,7 +1124,7 @@ Internet-Draft DNSSEC Resource Records February 2002 8. Security Considerations This document describes the format of resource records used by DNS - security. The threats facing DNS are described in a seperate + security. The threats facing DNS are described in a separate document and these records are used to help counter those threats. The records themselves introduce no new security considerations, but the protocol use of these records is described in a second document. @@ -1058,13 +1172,18 @@ Internet-Draft DNSSEC Resource Records February 2002 -Arends, et al. Expires August 23, 2002 [Page 19] +Arends, et al. Expires August 2, 2002 [Page 21] Internet-Draft DNSSEC Resource Records February 2002 9. Acknowledgements + This document was created from the input and ideas of several members + of the DNS Extensions Working Group and working group mailing list. + The co-authors of this draft would like to express their thanks for + the comments and suggestions received during the re-writing of these + security extension specifications. @@ -1109,12 +1228,7 @@ Internet-Draft DNSSEC Resource Records February 2002 - - - - - -Arends, et al. Expires August 23, 2002 [Page 20] +Arends, et al. Expires August 2, 2002 [Page 22] Internet-Draft DNSSEC Resource Records February 2002 @@ -1170,7 +1284,7 @@ References -Arends, et al. Expires August 23, 2002 [Page 21] +Arends, et al. Expires August 2, 2002 [Page 23] Internet-Draft DNSSEC Resource Records February 2002 @@ -1226,7 +1340,7 @@ Authors' Addresses -Arends, et al. Expires August 23, 2002 [Page 22] +Arends, et al. Expires August 2, 2002 [Page 24] Internet-Draft DNSSEC Resource Records February 2002 @@ -1239,8 +1353,10 @@ Appendix A. Key Tag Calculation possible for more than one candidate key to have the same tag, in which case each must be tried until one works or all fail. The following reference implementation of how to calculate the Key Tag, - for all algorithms other than algorithm 1, is in ANSI C. It is coded - for clarity, not efficiency. + for all algorithms other than algorithm 1 (which is NOT RECOMMENDED), + is in ANSI C. The input is the key material in base 64,not the + entire RDATA of the KEY record that contains the public key. It is + coded for clarity, not efficiency. /* assumes int is at least 16 bits first byte of the key tag is the most significant byte of return @@ -1280,9 +1396,7 @@ Appendix A. Key Tag Calculation - - -Arends, et al. Expires August 23, 2002 [Page 23] +Arends, et al. Expires August 2, 2002 [Page 25] Internet-Draft DNSSEC Resource Records February 2002 @@ -1338,5 +1452,5 @@ Acknowledgement -Arends, et al. Expires August 23, 2002 [Page 24] +Arends, et al. Expires August 2, 2002 [Page 26] diff --git a/doc/draft/draft-ietf-dnsext-ipv6-addresses-02.txt b/doc/draft/draft-ietf-dnsext-ipv6-addresses-02.txt new file mode 100644 index 0000000000..58f36a71b1 --- /dev/null +++ b/doc/draft/draft-ietf-dnsext-ipv6-addresses-02.txt @@ -0,0 +1,338 @@ + + + + + + +DNSEXT Working Group Randy Bush (ed.) + Alain Durand (ed.) + Bob Fink (ed.) + Olafur Gudmundsson (ed.) + Tony Hain (ed.) +INTERNET-DRAFT June 2002 + + + +Updates: RFC 1886, RFC 2673, RFC 2874 + + + + Representing IPv6 addresses in DNS. + + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC 2026. + + 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 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/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + Comments should be sent to the authors or the DNSEXT WG mailing list + namedroppers@ops.ietf.org + + This draft expires on December 31, 2002. + + Copyright Notice + + Copyright (C) The Internet Society (2002). All rights reserved. + + + + + + +Expires 31/December/2002 DNSEXT [Page 1] + +INTERNET-DRAFT Representation of IPv6 addresses in DNS. June 2002 + + +Abstract + + This document clarifies and updates the standards status of RFCs that + define direct and reverse map of IPv6 addresses in DNS. This document + moves the A6 and Bit label specifications to experimental status. + + + + +1 - Introduction + + The IETF had begun the process of standardizing two different address + formats for IPv6 addresses AAAA[RFC1886] and A6[RFC2874] and both are + at proposed standard. This had led to confusion and conflicts on + which one to deploy. It is important for deployment that any + confusion in this area be cleared up, as there is a feeling in the + community that having more than one choice will lead to delays in the + deployment of IPv6. The goal of this document is to clarify the + situation. + + This document also discusses issues relating to the usage of Binary + Labels [RFC 2673] to support the reverse mapping of IPv6 addresses. + + This document is based on extensive technical discussion on various + relevant working groups mailing lists and a joint DNSEXT and NGTRANS + meeting at the 51st IETF in August 2001. This document attempts to + capture the sense of the discussions and reflect them in this + document to represent the consensus of the community. + + The main arguments and the issues are covered in a separate + document[Tradeoff] that reflects the current understanding of the + issues. This document summarizes the outcome of these discussions. + + The issue of the root of reverse IPv6 address map is outside the + scope of this document and is covered in a different + document[RFC3152]. + + + + + + + + + + + + + + + +Expires 31/December/2002 DNSEXT [Page 2] + +INTERNET-DRAFT Representation of IPv6 addresses in DNS. June 2002 + + +1.1 Standards action taken + + This document changes the status of RFCs 2673 and 2874 from Proposed + Standard to Experimental. + +2 - IPv6 addresses: AAAA RR vs A6 RR + + Working group consensus as perceived by the chairs of the DNSEXT and + NGTRANS working groups is that: + + a) AAAA records are preferable at the moment for production + deployment of IPv6, and + + b) that A6 records have interesting properties that need to be + better understood before deployment. + + c) It is not known if the benefits of A6 outweigh the costs and + risks. + + +2.1 Rationale + + There are several potential issues with A6 RRs that stem directly + from the feature that makes them different from AAAA RRs: the ability + to build up addresses via chaining. + + Resolving a chain of A6 RRs involves resolving a series of what are + nearly-independent queries. Each of these sub-queries takes some + non-zero amount of time, unless the answer happens to be in the + resolver's local cache already. Other things being equal, we expect + that the time it takes to resolve an N-link chain of A6 RRs will be + roughly proportional to N. What data we have suggests that users are + already impatient with the length of time it takes to resolve A RRs + in the IPv4 Internet, which suggests that users are not likely to be + patient with significantly longer delays in the IPv6 Internet, but + terminating queries prematurely is both a waste of resources and + another source of user frustration. Thus, we are forced to conclude + that indiscriminate use of long A6 chains is likely to lead to + increased user frustration. + + The probability of failure during the process of resolving an N-link + A6 chain also appears to be roughly proportional to N, since each of + the queries involved in resolving an A6 chain has roughly the same + probability of failure as a single AAAA query. + + Last, several of the most interesting potential applications for A6 + RRs involve situations where the prefix name field in the A6 RR + points to a target that is not only outside the DNS zone containing + + + +Expires 31/December/2002 DNSEXT [Page 3] + +INTERNET-DRAFT Representation of IPv6 addresses in DNS. June 2002 + + + the A6 RR, but is administered by a different organization entirely. + While pointers out of zone are not a problem per se, experience both + with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that + pointers to other organizations are often not maintained properly, + perhaps because they're less susceptible to automation than pointers + within a single organization would be. + +2.2 Recommended standard action + + Based on the perceived consensus, this document recommend that RFC + 1886 stay on standards track and be advanced, while moving RFC 2874 + to Experimental status. + +3 - Bitlabels in the reverse DNS tree + + RFC 2673 defines a new DNS label type. This was the first new type + defined since RFC 1035[RFC1035]. Since the development of 2673 it has + been learned that deployment of a new type is difficult since DNS + servers that do not support bitlabels reject queries containing bit + labels as being malformed. The community has also indicated that this + new label type is not needed for mapping reverse addresses. + +3.1 Rationale + + The hexadecimal text representation of IPv6 addresses appears to be + capable of expressing all of the delegation schemes that we expect to + be used in the DNS reverse tree. + +3.2 Recommended standard action + + RFC 2673 standard status is to be changed from Proposed to + Experimental. Future standardization of these documents is to be done + by the DNSEXT working group or its successor. + +4 DNAME in IPv6 reverse tree + + The issues for DNAME in the reverse mapping tree appears to be + closely tied to the need to use fragmented A6 in the main tree: if + one is necessary, so is the other, and if one isn't necessary, the + other isn't either. Therefore, in moving RFC 2874 to experimental, + the intent of this document is that use of DNAME RRs in the reverse + tree be deprecated. + + + + + + + + + +Expires 31/December/2002 DNSEXT [Page 4] + +INTERNET-DRAFT Representation of IPv6 addresses in DNS. June 2002 + + +5 Acknowledgments + + This document is based on input from many members of the various IETF + working groups involved in this issues. Special thanks go to the + people that prepared reading material for the joint DNSEXT and + NGTRANS working group meeting at the 51st IETF in London, Rob + Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino, + Christian Huitema. Number of other people have made number of + comments on mailing lists about this issue including Andrew W. + Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka + Savola, Paul Vixie. + +6 - Security Considerations: + + As this document specifies a course of action, there are no direct + security considerations. There is an indirect security impact of the + choice, in that the relationship between A6 and DNSSEC is not well + understood throughout the community, while the choice of AAAA does + leads to a model for use of DNSSEC in IPv6 networks which parallels + current IPv4 practice. + + +7 - IANA Considerations: + + None. + +Normative References: + +[RFC1035] P. Mockapetris, ``Domain Names - Implementation and + Specification'' STD 13, RFC 1035, November 1987. + +[RFC1886] S. Thompson, C. Huitema, ``DNS Extensions to support IP + version 6'', RFC 1886, December 1995. + +[RFC2673] M. Crawford ``Binary Labels in the Domain Name System``, RFC + 2673, August 1999. + +[RFC2874] M. Crawford, C. Huitema, ``DNS Extensions to Support IPv6 + Address Aggregation and Renumbering'', RFC 2874, July 2000. + +[RFC3152] R. Bush, ``Delegation of IP6.ARPA'', RFC 3152 also BCP0049, + August 2001, + +Informative References + +[Tradeoff] R. Austein, ``Tradeoffs in DNS support for IPv6'', Work in + progress, draft-ietf-dnsext-ipv6-dns-tradeoffs-xx.txt, June + 2002. + + + +Expires 31/December/2002 DNSEXT [Page 5] + +INTERNET-DRAFT Representation of IPv6 addresses in DNS. June 2002 + + +Editors Address + + Randy Bush + Alain Durand + Bob Fink + Olafur Gudmundsson + Tony Hain + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." + + + + + + + + + + + + + + + + +Expires 31/December/2002 DNSEXT [Page 6]