--- /dev/null
+
+
+
+
+
+
+Network Working Group A. Durand
+Request for Comments: 3901 SUN Microsystems, Inc.
+BCP: 91 J. Ihren
+Category: Best Current Practice Autonomica
+ September 2004
+
+
+ DNS IPv6 Transport Operational Guidelines
+
+Status of this Memo
+
+ This document specifies an Internet Best Current Practices for the
+ Internet Community, and requests discussion and suggestions for
+ improvements. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2004).
+
+Abstract
+
+ This memo provides guidelines and Best Current Practice for operating
+ DNS in a world where queries and responses are carried in a mixed
+ environment of IPv4 and IPv6 networks.
+
+1. Introduction to the Problem of Name Space Fragmentation:
+ following the referral chain
+
+ A resolver that tries to look up a name starts out at the root, and
+ follows referrals until it is referred to a name server that is
+ authoritative for the name. If somewhere down the chain of referrals
+ it is referred to a name server that is only accessible over a
+ transport which the resolver cannot use, the resolver is unable to
+ finish the task.
+
+ When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
+ only a matter of time until this starts to happen. The complete DNS
+ hierarchy then starts to fragment into a graph where authoritative
+ name servers for certain nodes are only accessible over a certain
+ transport. The concern is that a resolver using only a particular
+ version of IP and querying information about another node using the
+ same version of IP can not do it because somewhere in the chain of
+ servers accessed during the resolution process, one or more of them
+ will only be accessible with the other version of IP.
+
+ With all DNS data only available over IPv4 transport everything is
+ simple. IPv4 resolvers can use the intended mechanism of following
+ referrals from the root and down while IPv6 resolvers have to work
+
+
+
+Durand & Ihren Best Current Practice [Page 1]
+\f
+RFC 3901 DNS IPv6 Transport Guidelines September 2004
+
+
+ through a "translator", i.e., they have to use a recursive name
+ server on a so-called "dual stack" host as a "forwarder" since they
+ cannot access the DNS data directly.
+
+ With all DNS data only available over IPv6 transport everything would
+ be equally simple, with the exception of IPv4 recursive name servers
+ having to switch to a forwarding configuration.
+
+ However, the second situation will not arise in the foreseeable
+ future. Instead, the transition will be from IPv4 only to a mixture
+ of IPv4 and IPv6, with three categories of DNS data depending on
+ whether the information is available only over IPv4 transport, only
+ over IPv6 or both.
+
+ Having DNS data available on both transports is the best situation.
+ The major question is how to ensure that it becomes the norm as
+ quickly as possible. However, while it is obvious that some DNS data
+ will only be available over v4 transport for a long time it is also
+ obvious that it is important to avoid fragmenting the name space
+ available to IPv4 only hosts. For example, during transition it is
+ not acceptable to break the name space that we presently have
+ available for IPv4-only hosts.
+
+2. Terminology
+
+ The phrase "IPv4 name server" indicates a name server available over
+ IPv4 transport. It does not imply anything about what DNS [1,2] data
+ is served. Likewise, "IPv6 [4,5,6] name server" indicates a name
+ server available over IPv6 transport. The phrase "dual-stack name
+ server" indicates a name server that is actually configured to run
+ both protocols, IPv4 and IPv6, and not merely a server running on a
+ system capable of running both but actually configured to run only
+ one.
+
+3. Policy Based Avoidance of Name Space Fragmentation
+
+ Today there are only a few DNS "zones" on the public Internet that
+ are available over IPv6 transport, and most of them can be regarded
+ as "experimental". However, as soon as the root and top level
+ domains are available over IPv6 transport, it is reasonable to expect
+ that it will become more common to have zones served by IPv6 servers.
+
+ Having those zones served only by IPv6-only name server would not be
+ a good development, since this will fragment the previously
+ unfragmented IPv4 name space and there are strong reasons to find a
+ mechanism to avoid it.
+
+
+
+
+
+Durand & Ihren Best Current Practice [Page 2]
+\f
+RFC 3901 DNS IPv6 Transport Guidelines September 2004
+
+
+ The recommended approach to maintain name space continuity is to use
+ administrative policies, as described in the next section.
+
+4. DNS IPv6 Transport recommended Guidelines
+
+ In order to preserve name space continuity, the following
+ administrative policies are recommended:
+
+ - every recursive name server SHOULD be either IPv4-only or dual
+ stack,
+
+ This rules out IPv6-only recursive servers. However, one might
+ design configurations where a chain of IPv6-only name server
+ forward queries to a set of dual stack recursive name server
+ actually performing those recursive queries.
+
+ - every DNS zone SHOULD be served by at least one IPv4-reachable
+ authoritative name server.
+
+ This rules out DNS zones served only by IPv6-only authoritative
+ name servers.
+
+ Note: zone validation processes SHOULD ensure that there is at least
+ one IPv4 address record available for the name servers of any child
+ delegations within the zone.
+
+5. Security Considerations
+
+ The guidelines described in this memo introduce no new security
+ considerations into the DNS protocol or associated operational
+ scenarios.
+
+6. Acknowledgment
+
+ This document is the result of many conversations that happened in
+ the DNS community at IETF and elsewhere since 2001. During that
+ period of time, a number of Internet drafts have been published to
+ clarify various aspects of the issues at stake. This document
+ focuses on the conclusion of those discussions.
+
+ The authors would like to acknowledge the role of Pekka Savola in his
+ thorough review of the document.
+
+
+
+
+
+
+
+
+
+Durand & Ihren Best Current Practice [Page 3]
+\f
+RFC 3901 DNS IPv6 Transport Guidelines September 2004
+
+
+7. 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] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+ [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+ Specification", RFC 2460, December 1998.
+
+ [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+ Addressing Architecture", RFC 3513, April 2003.
+
+ [6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
+ Extensions to Support IP Version 6", RFC 3596, October 2003.
+
+8. Authors' Addresses
+
+ Alain Durand
+ SUN Microsystems, Inc
+ 17 Network circle UMPK17-202
+ Menlo Park, CA, 94025
+ USA
+
+ EMail: Alain.Durand@sun.com
+
+
+ Johan Ihren
+ Autonomica
+ Bellmansgatan 30
+ SE-118 47 Stockholm
+ Sweden
+
+ EMail: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand & Ihren Best Current Practice [Page 4]
+\f
+RFC 3901 DNS IPv6 Transport Guidelines September 2004
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2004).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+ REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+ INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights 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; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the IETF's procedures with respect to rights in IETF Documents can
+ be found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at ietf-
+ ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+Durand & Ihren Best Current Practice [Page 5]
+\f
projects / thirdparty / bind9.git / commitdiff
