1 files changed, 300 insertions, 0 deletions
diff --git a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
new file mode 100644
index 0000000..b2e2341
--- /dev/null
+++ b/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
@@ -0,0 +1,300 @@
+Internet Engineering Task Force                         A.Durand
+INTERNET-DRAFT                             SUN Microsystems,inc.
+November, 24, 2003                                      J. Ihren
+Expires May 25, 2004                                  Autonomica
+
+
+               DNS IPv6 transport operational guidelines
+          <draft-ietf-dnsop-ipv6-transport-guidelines-01.txt>
+
+
+
+Status of this Memo
+
+   This memo provides information to the Internet community. It does not
+   specify an Internet standard of any kind. This memo is in full
+   conformance with all provisions of Section 10 of RFC2026
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet- Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/1id-abstracts.html
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html
+
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+
+Abstract
+
+   This memo provides guidelines and Best Current Practice to operate
+   DNS in a world where queries and responses are carried in a mixed
+   environment of IPv4 and IPv6 networks.
+
+
+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.
+
+
+1. Terminology
+
+   The phrase "IPv4 name server" indicates a name server available over
+   IPv4 transport. It does not imply anything about what DNS data is
+   served. Likewise, "IPv6 name server" indicates a name server
+   available over IPv6 transport. The phrase "dual-stack DNS server"
+   indicates a DNS 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.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [2119].
+
+
+2. Introduction to the Problem of Name Space Fragmentation:
+     following the referral chain
+
+   The caching resolver that tries to look up a name starts out at the
+   root, and follows referrals until it is referred to a nameserver that
+   is authoritative for the name.  If somewhere down the chain of
+   referrals it is referred to a nameserver that is only accessible over
+   an unavailable type of transport, a traditional nameserver 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
+   nameservers for certain nodes are only accessible over a certain
+   transport. What is feared is that a node using only a particular
+   version of IP, 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
+   through a "translator", i.e. they have to use a second 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 old legacy IPv4 name servers
+   having to switch to a forwarding configuration.
+
+   However, the second situation will not arise in a foreseeable time.
+   Instead, it is expected that the transition will be from IPv4 only to
+   a mixture of IPv4 and IPv6, with DNS data of theoretically three
+   categories depending on whether it 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 as quickly as possible
+   becomes the norm. 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. I.e. during transition it is not
+   acceptable to break the name space that we presently have available
+   for IPv4-only hosts.
+
+
+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.
+
+   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 DNS server SHOULD be either IPv4-only or dual
+      stack,
+      - every single DNS zone SHOULD be served by at least one IPv4
+      reachable DNS server.
+
+   This rules out IPv6-only DNS servers performing full recursion and
+   DNS zones served only by IPv6-only DNS servers.  However, one could
+   very well design a configuration where a chain of IPv6 only DNS
+   servers forward queries to a set of dual stack DNS servers actually
+   performing those recursive queries.  This approach could be revisited
+   if/when translation techniques between IPv4 and IPv6 were to be
+   widely deployed.
+
+   In order to help enforcing the second point, the optional operational
+   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
+
+   Being a critical piece of the Internet infrastructure, the DNS is a
+   potential value target and thus should be protected.  Great care
+   should be taken not to weaken the security of DNS while introducing
+   IPv6 operation.
+
+   Keeping the DNS name space from fragmenting is a critical thing for
+   the availability and the operation of the Internet; this memo
+   addresses this issue by clear and simple operational guidelines.
+
+   The RECOMMENDED guidelines are compatible with the operation of
+   DNSSEC and do not introduce any new security issues.
+
+
+6. Author Addresses
+
+   Alain Durand
+   SUN Microsystems, Inc
+   17 Network circle UMPK17-202
+   Menlo Park, CA, 94025
+   USA
+   Mail: Alain.Durand@sun.com
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm, Sweden
+   Mail: johani@autonomica.se
+
+
+7. Normative References
+
+   [2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
+           Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+8. 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 assigns.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+