diff options
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3596.txt')
-rw-r--r-- | contrib/bind9/doc/rfc/rfc3596.txt | 451 |
1 files changed, 0 insertions, 451 deletions
diff --git a/contrib/bind9/doc/rfc/rfc3596.txt b/contrib/bind9/doc/rfc/rfc3596.txt deleted file mode 100644 index f65690c8875a8..0000000000000 --- a/contrib/bind9/doc/rfc/rfc3596.txt +++ /dev/null @@ -1,451 +0,0 @@ - - - - - - -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] - |