Initial commitstart

1 files changed, 451 insertions, 0 deletions

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]
+