diff options
Diffstat (limited to 'contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt')
| -rw-r--r-- | contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt | 300 |
1 files changed, 0 insertions, 300 deletions
diff --git a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt b/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt deleted file mode 100644 index b2e2341..0000000 --- a/contrib/bind9/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt +++ /dev/null @@ -1,300 +0,0 @@ -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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - |
