summaryrefslogtreecommitdiff
path: root/contrib/bind9/doc/rfc/rfc3596.txt
diff options
context:
space:
mode:
Diffstat (limited to 'contrib/bind9/doc/rfc/rfc3596.txt')
-rw-r--r--contrib/bind9/doc/rfc/rfc3596.txt451
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]
-