From f50ae72ec3417cae55dd4e085991c01af9fdc5f1 Mon Sep 17 00:00:00 2001 From: Martin Nagy Date: Wed, 11 Feb 2009 20:37:59 +0100 Subject: Initial commit --- doc/rfc/rfc3596.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc3596.txt (limited to 'doc/rfc/rfc3596.txt') diff --git a/doc/rfc/rfc3596.txt b/doc/rfc/rfc3596.txt new file mode 100644 index 0000000..f65690c --- /dev/null +++ b/doc/rfc/rfc3596.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group S. Thomson +Request for Comments: 3596 Cisco +Obsoletes: 3152, 1886 C. Huitema +Category: Standards Track Microsoft + V. Ksinant + 6WIND + M. Souissi + AFNIC + October 2003 + + + DNS Extensions to Support IP Version 6 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This document defines the changes that need to be made to the Domain + Name System (DNS) to support hosts running IP version 6 (IPv6). The + changes include a resource record type to store an IPv6 address, a + domain to support lookups based on an IPv6 address, and updated + definitions of existing query types that return Internet addresses as + part of additional section processing. The extensions are designed + to be compatible with existing applications and, in particular, DNS + implementations themselves. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. New resource record definition and domain. . . . . . . . . . . 2 + 2.1. AAAA record type . . . . . . . . . . . . . . . . . . . . 3 + 2.2. AAAA data format . . . . . . . . . . . . . . . . . . . . 3 + 2.3. AAAA query . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.4. Textual format of AAAA records . . . . . . . . . . . . . 3 + 2.5. IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . . 3 + 3. Modifications to existing query types. . . . . . . . . . . . . 4 + 4. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 + 5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 4 + + + +Thomson, et al. Standards Track [Page 1] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + + 6. Intellectual Property Statement. . . . . . . . . . . . . . . . 4 + Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . . 5 + Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . . 6 + Normative References . . . . . . . . . . . . . . . . . . . . . . . 6 + Informative References . . . . . . . . . . . . . . . . . . . . . . 6 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 8 + +1. Introduction + + Current support for the storage of Internet addresses in the Domain + Name System (DNS) [1,2] cannot easily be extended to support IPv6 + addresses [3] since applications assume that address queries return + 32-bit IPv4 addresses only. + + To support the storage of IPv6 addresses in the DNS, this document + defines the following extensions: + + o A resource record type is defined to map a domain name to an + IPv6 address. + + o A domain is defined to support lookups based on address. + + o Existing queries that perform additional section processing to + locate IPv4 addresses are redefined to perform additional + section processing on both IPv4 and IPv6 addresses. + + The changes are designed to be compatible with existing software. + The existing support for IPv4 addresses is retained. Transition + issues related to the co-existence of both IPv4 and IPv6 addresses in + the DNS are discussed in [4]. + + The IP protocol version used for querying resource records is + independent of the protocol version of the resource records; e.g., + IPv4 transport can be used to query IPv6 records and vice versa. + + This document combines RFC 1886 [5] and changes to RFC 1886 made by + RFC 3152 [6], obsoleting both. Changes mainly consist in replacing + the IP6.INT domain by IP6.ARPA as defined in RFC 3152. + +2. New resource record definition and domain + + A record type is defined to store a host's IPv6 address. A host that + has more than one IPv6 address must have more than one such record. + + + + + + + +Thomson, et al. Standards Track [Page 2] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +2.1 AAAA record type + + The AAAA resource record type is a record specific to the Internet + class that stores a single IPv6 address. + + The IANA assigned value of the type is 28 (decimal). + +2.2 AAAA data format + + A 128 bit IPv6 address is encoded in the data portion of an AAAA + resource record in network byte order (high-order byte first). + +2.3 AAAA query + + An AAAA query for a specified domain name in the Internet class + returns all associated AAAA resource records in the answer section of + a response. + + A type AAAA query does not trigger additional section processing. + +2.4 Textual format of AAAA records + + The textual representation of the data portion of the AAAA resource + record used in a master database file is the textual representation + of an IPv6 address as defined in [3]. + +2.5 IP6.ARPA Domain + + A special domain is defined to look up a record given an IPv6 + address. The intent of this domain is to provide a way of mapping an + IPv6 address to a host name, although it may be used for other + purposes as well. The domain is rooted at IP6.ARPA. + + An IPv6 address is represented as a name in the IP6.ARPA domain by a + sequence of nibbles separated by dots with the suffix ".IP6.ARPA". + The sequence of nibbles is encoded in reverse order, i.e., the + low-order nibble is encoded first, followed by the next low-order + nibble and so on. Each nibble is represented by a hexadecimal digit. + For example, the reverse lookup domain name corresponding to the + address + + 4321:0:1:2:3:4:567:89ab + + would be + + b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6. + ARPA. + + + + +Thomson, et al. Standards Track [Page 3] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +3. Modifications to existing query types + + All existing query types that perform type A additional section + processing, i.e., name server (NS), location of services (SRV) and + mail exchange (MX) query types, must be redefined to perform both + type A and type AAAA additional section processing. These + definitions mean that a name server must add any relevant IPv4 + addresses and any relevant IPv6 addresses available locally to the + additional section of a response when processing any one of the above + queries. + +4. Security Considerations + + Any information obtained from the DNS must be regarded as unsafe + unless techniques specified in [7] or [8] are used. The definitions + of the AAAA record type and of the IP6.ARPA domain do not change the + model for use of these techniques. + + So, this specification is not believed to cause any new security + problems, nor to solve any existing ones. + +5. IANA Considerations + + There are no IANA assignments to be performed. + +6. Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. + + + + + +Thomson, et al. Standards Track [Page 4] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Acknowledgments + + Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien + Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin + (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic + Roudaut (IRISA) and G6 group for their help during the RFC 1886 + Interop tests sessions. + + Many thanks to Alain Durand and Olafur Gudmundsson for their support. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 5] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Appendix A: Changes from RFC 1886 + + The following changes were made from RFC 1886 "DNS Extensions to + support IP version 6": + + - Replaced the "IP6.INT" domain by "IP6.ARPA". + - Mentioned SRV query types in section 3 "MODIFICATIONS TO + EXISTING QUERY TYPES" + - Added security considerations. + - Updated references : + * From RFC 1884 to RFC 3513 (IP Version 6 Addressing + Architecture). + * From "work in progress" to RFC 2893 (Transition Mechanisms for + IPv6 Hosts and Routers). + * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845. + - Updated document abstract + - Added table of contents + - Added full copyright statement + - Added IANA considerations section + - Added Intellectual Property Statement + +Normative References + + [1] Mockapetris, P., "Domain Names - Concepts and Facilities", STD + 13, RFC 1034, November 1987. + + [2] Mockapetris, P., "Domain Names - Implementation and + Specification", STD 13, RFC 1035, November 1987. + + [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + +Informative References + + [4] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 + Hosts and Routers", RFC 2893, August 2000. + + [5] Thomson, S. and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, December 1995. + + [6] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August + 2001. + + [7] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999 + + + + + + +Thomson, et al. Standards Track [Page 6] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + + [8] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, + "Secret Key Transaction Authentication for DNS (TSIG)", RFC + 2845, May 2000. + +Authors' Addresses + + Susan Thomson + Cisco Systems + 499 Thornall Street, 8th floor + Edison, NJ 08837 + + Phone: +1 732-635-3086 + EMail: sethomso@cisco.com + + + Christian Huitema + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052-6399 + + EMail: huitema@microsoft.com + + + Vladimir Ksinant + 6WIND S.A. + Immeuble Central Gare - Bat.C + 1, place Charles de Gaulle + 78180, Montigny-Le-Bretonneux - France + + Phone: +33 1 39 30 92 36 + EMail: vladimir.ksinant@6wind.com + + + Mohsen Souissi + AFNIC + Immeuble International + 2, rue Stephenson, + 78181, Saint-Quentin en Yvelines Cedex - France + + Phone: +33 1 39 30 83 40 + EMail: Mohsen.Souissi@nic.fr + + + + + + + + + + +Thomson, et al. Standards Track [Page 7] + +RFC 3596 DNS Extensions to Support IPv6 October 2003 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2003). 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 assignees. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Thomson, et al. Standards Track [Page 8] + -- cgit