284 lines
9.8 KiB
Plaintext
284 lines
9.8 KiB
Plaintext
|
|
|
|
|
|
|
|
|
|
|
|
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]
|
|
|
|
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]
|
|
|
|
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]
|
|
|
|
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]
|
|
|
|
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]
|
|
|