--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / thirdparty / bind9.git / commitdiff
