From: Mark Andrews Date: Thu, 4 Dec 2003 22:54:54 +0000 (+0000) Subject: new draft X-Git-Tag: v9.2.4rc1~81^2~73 X-Git-Url: http://git.ipfire.org/gitweb/?a=commitdiff_plain;h=66cc8985f2d0d193fed1c2414dfdbe27e5d6a452;p=thirdparty%2Fbind9.git new draft --- diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-02.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-02.txt deleted file mode 100644 index 2920cad2fa0..00000000000 --- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-02.txt +++ /dev/null @@ -1,480 +0,0 @@ -Internet Engineering Task Force Alain Durand -INTERNET-DRAFT SUN Microsystems,inc. -Feb, 27, 2003 Johan Ihren -Expires August, 28, 2003 Autonomica - - - IPv6 DNS transition issues - - - - -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 - - - -Abstract - - This memo summarizes DNS related issues when transitioning a network - to IPv6. Consensus and open issues are presented. - - - -1. Representing IPv6 addresses in DNS records - - In the direct zones, according to [RFC3363], IPv6 addresses are - represented using AAAA records [RFC1886]. In the reverse zone, IPv6 - addresses are represented using PTR records in nibble format under - the ip6.arpa. tree [RFC3152]. - - - -2. IPv4/IPv6 name space - -2.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. - - -2.2. Introduction to the problem of name space fragmentation: - following the referral chain - - The caching resolver that tries to lookup 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 - a type of transport that is unavailable, 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 and the complete - DNS hierarchy 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. - - The latter is the best situation, and a 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. - - -2.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 they can mostly be regarded - as "experimental". However, as soon as there is a root name server - available over IPv6 transport it is reasonable to expect that it will - become more common to have zones served by IPv6 servers over time. - - 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: - - 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 recursive DNS servers and DNS zones served - only by IPv6-only DNS servers. This approach could be revisited - if/when translation techniques between IPv4 and IPv6 were to be - widely deployed. - - In order to enforce the second point, the zone validation process - SHOULD ensure that there is at least one IPv4 address record - available for the name servers of any child delegations within the - zone. - - - -3. Local Scope addresses. - - [IPv6ADDRARCH] define three scopes of addresses, link local, site - local and global. - -3.1 Link local addresses - - Local addresses SHOULD NOT be published in the DNS, neither in the - forward tree nor in the reverse tree. - - -3.2 Site local addresses - - Note: There is an ongoing discussion in the IPv6 wg on the - usefulness of site local addresses that may end up deprecating or - limiting the use of Site Local addresses. - - - Site local addresses are an evolution of private addresses [RFC1918] - in IPv4. The main difference is that, within a site, nodes are - expected to have several addresses with different scopes. [ADDRSELEC] - recommends to use the lowest possible scope possible for - communications. That is, if both site local & global addresses are - published in the DNS for node B, and node A is configured also with - both site local & global addresses, the communication between node A - and B has to use site local addresses. - - For reasons illustrated in [DontPublish], site local addresses SHOULD - NOT be published in the public DNS. They MAY be published in a site - view of the DNS if two-face DNS is deployed. - - For a related discussion on how to handle those "local" zones, see - [LOCAL]. - - -3.3 Reverse path DNS for site local addresses. - - The main issue is that the view of a site may be different on a stub - resolver and on a fully recursive resolver it points to. A simple - scenario to illustrate the issue is a home network deploying site - local addresses. Reverse DNS resolution for site local addresses has - to be done within the home network and the stub resolver cannot - simply point to the ISP DNS resolver. - - Site local addresses SHOULD NOT be populated in the public reverse - tree. If two-face DNS is deployed, site local addresses MAY be - populated in the local view of reverse tree. - - - -4. Automatic population of the Reverse path DNS - - Getting the reverse tree DNS populated correctly in IPv4 is not an - easy exercise and very often the records are not really up to date or - simply are just not there. As IPv6 addresses are much longer than - IPv4 addresses, the situation of the reverse tree DNS will probably - be even worse. - - A fairly common practice from IPv4 ISP is to generate PTR records for - home customers automatically from the IPv4 address itself. Something - like: - - 1.2.3.4.in-addr.arpa. IN PTR 4.3.2.1.local-ISP.net - - It is not clear today if something similar need to be done in IPv6, - and, if yes, what is the best approach to this problem. - - As the number of possible PTR records would be huge (2^80) for a /48 - prefix, a possible solution would be to use wildcards entries like: - - *.0.1.2.3.4.5.6.7.8.9.a.b.c.ip6.arpa. IN PTR customer-42.local- - ISP.net - - However, the use of wildcard is generally discouraged and this may - not be an acceptable solution. - - An alternative approach is to dynamically synthetize PTR records, - either on the server side or on the resolver side. This approach is - discussed at length in [DYNREVERSE]. - - Other solutions like the use of ICMP name lookups [ICMPNL] have been - proposed but failed to reach consensus. It would work if and only the - remote host is reachable at the time of the request and one can - somehow trust the value that would be returned by the remote host. - the - - A more radical approach would be not to pre-populate the reverse tree - at all. This approach claims that applications that misuse reverse - DNS for any kind of access control are fundamentally broken and - should be fixed without introducing any kludge in the DNS. There is a - certain capital of sympathy for this, however, ISP who who pre- - generate statically PTR records for their IPv4 customers do it for a - reason, and it is unlikely that this reason will disappear with the - introduction of IPv6. - - - -5. Privacy extension addresses - - [RFC3041] defines privacy extensions for IPv6 stateless - autoconfiguration where the interface ID is a random number. As those - addresses are designed to provide privacy by making it more difficult - to log and trace back to the user, it makes no sense to in the - reverse tree DNS to have them pointing to a real name. - - [RFC3041] type addresses SHOULD NOT be published in the reverse tree - DNS pointing to meaningful names. A generic, catch-all name MAY be - acceptable. An interesting alternative would be to use dynamic - synthesis as in [DYNREVERSE]. - - - -6. 6to4 - - 6to4 addresses can be published in the forward DNS, however special - care is needed in the reverse tree. See [6to4ReverseDNS] for details. - The delegation of 2.0.0.2.ip6.arpa. is suggested in [6to4ARPA], - however, delegations in the reverse zone under 2.0.0.2.ip6.arpa are - the core of the problem. Delegating the next 32 bits of the IPv4 - address used in the 6to4 domain won't scale and delegating on less - may require cooperation from the upstream IPSs. The problem here is - that, especially in the case of home usage of 6to4, the entity being - delegated the x.y.z.t.2.0.0.2.ip6.arpa. zone (the ISP) may not be the - same as the one using 6to4 (the end customer). the - - Another problem with reverse DNS for 6to4 addresses is that the 6to4 - prefix may be transient. One of the usage scenario of 6to4 is to have - PCs connected via dial-up use 6to4 to connect to the IPv6 Internet. - In such a scenario, the lifetime of the 6to4 prefix is the same as - the DHCP lease of the IPv4 address it is derived from. It means that - the reverse DNS delegation is only valid for the same duration. - - A possible approach is not to populate the reverse tree DNS for 6to4 - addresses. Another one is to use dynamic synthesis as described in - [DYNREVERSE]. - - - - -7. Recursive DNS server discovery - - [DNSdiscovery] has been proposed to reserve a well known site local - unicast address to configure the DNS resolver as a last resort - mechanism, when no other information is available. Another approach - is to use a DHCPv6 extensions [DHCPv6DNS]. - - - -8. DNSsec - - There is nothing specific to IPv6 or IPv4 in DNSsec. However, - translation tools such as NAT-PT [RFC2766] introduce a DNS-ALG that - will break DNSsec by imposing a change in the trust model. See [DNS- - ALG] for details. - - - -9. Security considerations - - Using wildcard DNS records in the reverse path tree may have some - implication when used in conjunction with DNSsec. Security - considerations for referenced documents are described in those memos - and are not replicated here. - - - -10. 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 - - - -11. References - - [RFC1918] Address Allocation for Private Internets. Y. Rekhter, B. - Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February - 1996. - - [RFC2766] Network Address Translation - Protocol Translation (NAT- - PT). - G. Tsirtsis, P. Srisuresh. February 2000. - - [RFC3041] Privacy Extensions for Stateless Address Autoconfiguration - in IPv6, - T. Narten, R. Draves, January 2001. - - [RFC3152] Delegation of ip6.arpa, R. Bush, August 2001. - - [RFC3363] Representing Internet Protocol version 6 (IPv6) Addresses - in the Domain Name System (DNS), R. Bush, A. Durand, B. - Fink, O. Gudmundsson, T. Hain. August 2002. - - [DYNREVERSE] Dynamic reverse DNS for IPv6, A. Durand, - draft-durand-dnsops-dynreverse-00.txt, work in progress. - - [DNS-ALG] Issues with NAT-PT DNS ALG in RFC2766, A. Durand, - draft-durand-v6ops-natpt-dns-alg-issues-00.txt, work in - progress. - - [LOCAL] Operational Guidelines for "local" zones in the DNS, - Kato, A., Vixie, P., draft-kato-dnsop-local-zones-00.txt, - work in progress. - - [ICMPNL] Use of ICMPv6 node information query for reverse DNS lookup, - Jun-ichiro itojun Hagino, draft-itojun-ipv6-nodeinfo- - revlookup-00.txt, work in progress. - - [IPv6ADDRARCH] IP Version 6 Addressing Architecture, R. Hinden, - draft-ipngwg-addr-arch-v3-11.txt, work in progress. - - [6to4ARPA] Delegation of 2.0.0.2.ip6.arpa, Bush, R., Damas, J., - draft-ymbk-6to4-arpa-delegation-00.txt, work in progress. - - [6to4ReverseDNS] 6to4 and DNS, K. Moore, draft-moore-6to4-dns-03.txt, - work in progress. - - [DNSdiscovery] Well known site local unicast addresses for DNS - resolver, - A. Durand, J. hagano, D. Thaler, draft-ietf-ipv6-dns- - discovery-07.txt, work in progress. - - [DHCPv6DNS] DNS Configuration options for DHCPv6, Droms, R. - draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt, work in - progress. - - - -12. Full Copyright Statement - - "Copyright (C) The Internet Society (2001). 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-03.txt b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-03.txt new file mode 100644 index 00000000000..54c3a8cff9d --- /dev/null +++ b/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-03.txt @@ -0,0 +1,1064 @@ + +DNS Operations WG A. Durand +Internet-Draft SUN Microsystems, Inc. +Expires: May 1, 2004 J. Ihren + Autonomica + P. Savola + CSC/FUNET + Nov 2003 + + + Operational Considerations and Issues with IPv6 DNS + draft-ietf-dnsop-ipv6-dns-issues-03.txt + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that other + groups may also distribute working documents as Internet-Drafts. + + 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/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on May 1, 2004. + +Copyright Notice + + Copyright (C) The Internet Society (2003). All Rights Reserved. + +Abstract + + This memo presents operational considerations and issues with IPv6 + Domain Name System (DNS), including a summary of special IPv6 + addresses, documentation of known DNS implementation misbehaviour, + recommendations and considerations on how to perform DNS naming for + service provisioning and for DNS resolver IPv6 support, + considerations for DNS updates for both the forward and reverse + trees, and miscellaneous issues. This memo is aimed to include a + summary of information about IPv6 DNS considerations for those who + have experience with IPv4 DNS. + + + +Durand, et al. Expires May 1, 2004 [Page 1] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . . . 3 + 1.2 Difference of DNS Transport and DNS Records . . . . . . . . . 3 + 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . . . 4 + 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 4 + 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . . . 4 + 2.2 Privacy (RFC3041) Address . . . . . . . . . . . . . . . . . . 4 + 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5 + 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . . . 5 + 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . . . 6 + 4. Recommendations for Service Provisioning using DNS . . . . . . 6 + 4.1 Use of Service Names instead of Node Names . . . . . . . . . . 6 + 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . . . 7 + 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . . . 7 + 4.4 IPv6 Transport Guidelines for DNS Servers . . . . . . . . . . 8 + 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 8 + 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . . . 8 + 5.2 Recursive DNS Server Discovery . . . . . . . . . . . . . . . . 10 + 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . . . 10 + 6. Considerations about Forward DNS Updating . . . . . . . . . . 10 + 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 10 + 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7. Considerations about Reverse DNS Updating . . . . . . . . . . 11 + 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . . . 11 + 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . . . 12 + 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . . . 12 + 7.4 DDNS With DHCP . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . . . 13 + 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 13 + 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . . . 13 + 8.2 Renumbering Procedures and Applications' Use of DNS . . . . . 13 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + Normative References . . . . . . . . . . . . . . . . . . . . . 14 + Informative References . . . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 + A. Site-local Addressing Considerations for DNS . . . . . . . . . 17 + Intellectual Property and Copyright Statements . . . . . . . . 18 + + + + + + + + + + +Durand, et al. Expires May 1, 2004 [Page 2] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + +1. Introduction + + This memo presents operational considerations and issues with IPv6 + DNS; it is meant to be an extensive summary and a list of pointers + for more information about IPv6 DNS considerations for those with + experience of IPv4 DNS. + + The first section gives a brief overview of how IPv6 addresses and + names are represented in the DNS, how transport protocols and + resource records (don't) relate, and what IPv4/IPv6 name space + fragmentation means and how to avoid it; all of these are described + at more length in other documents. + + The second section summarizes the special IPv6 address types and how + they relate to DNS. The third section describes observed DNS + implementation misbehaviour which have a varying effect on the use of + IPv6 records with DNS. The fourth section lists recommendations and + considerations for provisioning services with DNS. The fifth section + in turn looks at recommendations and considerations about providing + IPv6 support in the resolvers. The sixth and seveth sections + describe considerations with forward and reverse DNS updates, + respectively. The eighth section introduces several miscellaneous + IPv6 issues relating to DNS for which no better place has been found + in this memo. Appendix A looks briefly at the requirements for + site-local addressing. + +1.1 Representing IPv6 Addresses in DNS Records + + In the forward zones, IPv6 addresses are represented using AAAA + records. In the reverse zones, IPv6 address are represented using + PTR records in the nibble format under the ip6.arpa. -tree. See [1] + for more about IPv6 DNS usage, and [2] or [4] for background + information. + + In particular one should note that the use of A6 records, DNAME + records in the reverse tree, or Bitlabels in the reverse tree is not + recommended [2]. + +1.2 Difference of DNS Transport and DNS Records + + In DNS, the IP version used to transport the queries and responses is + independent of the records being queried: AAAA records can be queried + over IPv4, and A records over IPv6. The DNS servers must not make any + assumptions about what data to return for Answer and Authority + sections. + + However, there is some debate whether the addresses in Additional + section could be selected or filtered using hints obtained from which + + + +Durand, et al. Expires May 1, 2004 [Page 3] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + transport was being used; this has some obvious problems because in + many cases the transport protocol does not correlate with the + requests, and because a "bad" answer is in a way worse than no answer + at all (consider the case where the client is led to believe that a + name received in the additional record does not have any AAAA records + to begin with). + + As stated in [1]: + + 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. + + +1.3 Avoiding IPv4/IPv6 Name Space Fragmentation + + To avoid the DNS name space from fragmenting into parts where some + parts of DNS are only visible using IPv4 (or IPv6) transport, the + recommendation is to always keep at least one authoritative server + IPv4-enabled, and to ensure that recursive DNS servers support IPv4. + See DNS IPv6 transport guidelines [3] for more information. + +2. DNS Considerations about Special IPv6 Addresses + + There are a couple of IPv6 address types which are somewhat special; + these are considered here. + +2.1 Limited-scope Addresses + + The IPv6 addressing architecture [5] includes two kinds of local-use + addresses: link-local (fe80::/10) and site-local (fec0::/10). The + site-local addresses are being deprecated [6], and are only discussed + in Appendix A. + + Link-local addresses should never be published in DNS, because they + have only local (to the connected link) significance [7]. + +2.2 Privacy (RFC3041) Address + + Privacy addresses (RFC3041 [8]) use a random number as the interface + identifier. Publishing DNS records relating to such addresses would + defeat the purpose of the mechanism and is not recommended. If + absolutely necessary, a mapping could be made to some + non-identifiable name, as described in [8]. + +2.3 6to4 Addresses + + 6to4 [9] specifies an automatic tunneling mechanism which maps a + + + +Durand, et al. Expires May 1, 2004 [Page 4] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. + Providing reverse DNS delegation path for such addresses is a + challenge. Note that similar difficulties don't surface with the + other automatic tunneling mechanisms (in parcicular, providing + reverse DNS information for Teredo hosts whose address includes the + UDP port of the NAT binding does not seem reasonable). + + If the reverse DNS population would be desirable (see Section 7.1 for + applicability), there are a number of ways to tackle the delegation + path problem [10], some more applicable than the others. + + The main proposal [11] has been to allocate 2.0.0.2.ip6.arpa. to RIRs + and let them do subdelegations in accordance to the delegations of + the respective IPv4 address space. This has a major practical + drawback: those ISPs and IPv4 address space holders where 6to4 is + being used do not, in general, provide any IPv6 services -- as + otherwise, most people would not use 6to4 to begin with -- and it is + improbable that the reverse delegation chain would be completed + either. In most cases, creating such delegation chains might just + lead to latencies caused by lookups for (almost always) non-existant + DNS records. + +3. Observed DNS Implementation Misbehaviour + + Several classes of misbehaviour in DNS servers, load-balancers and + resolvers has been observed. Most of these are rather generic, not + only applicable to IPv6 -- but in some cases, the consequences of + this misbehaviour are extremely severe in IPv6 environments and + deserve to be mentioned. + +3.1 Misbehaviour of DNS Servers and Load-balancers + + There are several classes of misbehaviour in certain DNS servers and + load-balancers which have been noticed and documented [12]: some + implementations silently drop queries for unimplemented DNS records + types, or provide wrong answers to such queries (instead of a proper + negative reply). While typically these issues are not limited to + AAAA records, the problems are aggravated by the fact that AAAA + records are being queried instead of (mainly) A records. + + The problems are serious because when looking up a DNS name, typical + getaddrinfo() implementations, with AF_UNSPEC hint given, first try + to query the AAAA records of the name, and after receiving a + response, query the A records. This is done in a serial fashion -- if + the first query is never responded (instead of properly returning a + negative answer), significant timeouts will occur. + + In consequence, this is an enermous problem for IPv6 deployments, and + + + +Durand, et al. Expires May 1, 2004 [Page 5] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + in some cases, IPv6 support in the software has even been disabled + due to these problems. + + The solution is to fix or retire those misbehaving implementations, + but that is likely not going to be effective. There are some + possible ways to mitigate the problem, e.g. by performing the lookups + somewhat in parallel and reducing the timeout as long as at least one + answer has been received; but such methods remain to be investigated; + slightly more on this in Section 5. + +3.2 Misbehaviour of DNS Resolvers + + Several classes of misbehaviour have also been noticed in DNS + resolvers [13]. However, these do not seem to directly impair IPv6 + use, and are only referred to for completeness. + +4. Recommendations for Service Provisioning using DNS + + When names are added in the DNS to facilitate a service, there are + several general guidelines to consider to be able to do it as + smoothly as possible. + +4.1 Use of Service Names instead of Node Names + + When a node includes multiple services, one should keep them + logically separate in the DNS. This can be done by the use of + service names instead of node names (or, "hostnames"). + + For example, assume a node named "pobox.example.com" provides both + SMTP and IMAP service. Instead of configuring the MX records to + point at "pobox.example.com", and configuring the mail clients to + look up the mail via IMAP from "pobox.example.com", one should use + e.g. "smtp.example.com" for SMTP (for both message submission and + mail relaying between SMTP servers) and "imap.example.com" for IMAP. + Note that in the specific case of STMP relaying, the server itself + must typically also be configured to know all its names to ensure + loops do not occur. DNS can provide a layer of indirection between + service names and where the service actually is, and using which + addresses. + + This is a good practice with IPv4 as well, because it provides more + flexibility and enables easier migration of services from one host to + another. A specific reason why this is relevant for IPv6 is that the + different services may have a different level of IPv6 support -- that + is, one node providing multiple services might want to enable just + one service to be IPv6-visible while keeping some others as + IPv4-only. Using service names enables more flexibility with + different IP versions as well. + + + +Durand, et al. Expires May 1, 2004 [Page 6] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + +4.2 Separate vs the Same Service Names for IPv4 and IPv6 + + The service naming can be achieved in basically two ways: when a + service is named "service.example.com" for IPv4, the IPv6-enabled + service could be either added to "service.example.com", or added + separately to a sub-domain, like, "service.ipv6.example.com". + + Both methods have different characteristics. Using a sub-domain + allows for easier service piloting, probably not disturbing the + "regular" users of IPv4 service; however, the service would not be + used without explicitly asking for it (or, within a restricted + network, modifying the DNS search path) -- so it will not actually be + used that much. Using the same service name is the "long-term" + solution, but may degrade performance for those clients whose IPv6 + performance is lower than IPv4, or does not work as well (see the + next subsection for more). + + In most cases, it makes sense to pilot or test a service using + separate service names, and move to the use of the same name when + confident enough that the service level will not degrade for the + users unaware of IPv6. + +4.3 Adding the Records Only when Fully IPv6-enabled + + The recommendation is that AAAA records for a service should not be + added to the DNS until all of following are true: + + 1. The address is assigned to the interface on the node. + + 2. The address is configured on the interface. + + 3. The interface is on a link which is connected to the IPv6 + infrastructure. + + In addition, if the AAAA record is added for the node, instead of + service as recommended, all the services of the node should be + IPv6-enabled prior to adding the AAAA record. + + For example, if an IPv6 node is isolated from an IPv6 perspective + (e.g., it is not connected to IPv6 Internet) constraint #3 would mean + that it should not have an address in the DNS. + + Consider the case of two dual-stack nodes, which both have IPv6 + enabled, but the server does not have (global) IPv6 connectivity. As + the client looks up the server's name, only A records are returned + (if the recommendations above are followed), and no IPv6 + communication, which would be unsuccessful, is even attempted. + + + + +Durand, et al. Expires May 1, 2004 [Page 7] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + The issues are not always so black-and-white. Usually it's important + if the service offered using both protocols is of roughly equal + quality, using the appropriate metrics for the service (e.g., + latency, throughput, low packet loss, general reliability, etc.) -- + this is typically very important especially for interactive or + real-time services. In many cases, the quality of IPv6 connectivity + is not yet equal to that of IPv4, at least globally -- this has to be + taken into consideration when enabling services [14]. + +4.4 IPv6 Transport Guidelines for DNS Servers + + As described in Section 1.3 and [3], there should continue to be at + least one authorative IPv4 DNS server for every zone, even if the + zone has only IPv6 records. (Note that obviously, having more servers + with robust connectivity would be preferably, but this is the + recommendation.) + +5. Recommendations for DNS Resolver IPv6 Support + + When IPv6 is enabled on a node, there are several things to consider + to ensure that the process is as smooth as possible. + +5.1 DNS Lookups May Query IPv6 Records Prematurely + + The system library that implements the getaddrinfo() function for + looking up names is a critical piece when considering the robustness + of enabling IPv6; it may come in basically three flavours: + + 1. The system library does not know whether IPv6 has been enabled in + the kernel of the operating system: it may start looking up AAAA + records with getaddrinfo() and AF_UNSPEC hint when the system is + upgraded to a system library version which supports IPv6. + + 2. The system library might start to perform IPv6 queries with + getaddrinfo() only when IPv6 has been enabled in the kernel. + However, this does not guarantee that there exists any useful + IPv6 connectivity (e.g., the node could be isolated from the + other IPv6 networks, only having link-local addresses). + + 3. The system library might implement a toggle which would apply + some heuristics to the "IPv6-readiness" of the node before + starting to perform queries; for example, it could check that a + link-local IPv6 address exists, or a global IPv6 address exists. + + First, let us consider generic implications of unnecessary queries + for AAAA records: when looking up all the records in the DNS, AAAA + records are typically tried first, and then A records. These are + done in serial, and the A query is not performed until a response is + + + +Durand, et al. Expires May 1, 2004 [Page 8] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + received to the AAAA query. Considering the misbehaviour of DNS + servers and load-balancers, as described in Section 3.1, the look-up + delay for AAAA may incur additional unnecessary latency, and + introduce a component of unreliability. + + One option here could be to do the queries partially in parallel; for + example, if the final response to the AAAA query is not received in + 0.5 seconds, start performing the A query while waiting for the + result (immediate parallelism might be unoptimal without information + sharing between the look-up threads, as that would probably lead to + duplicate non-cached delegation chain lookups). + + An additional concern is the address selection, which may, in some + circumstances, prefer AAAA records over A records, even when the node + does not have any IPv6 connectivity [15]. In some cases, the + implementation may attempt to connect or send a datagram on a + physical link [16], incurring very long protocol timeouts, instead of + quickly failing back to IPv4. + + Now, we can consider the issues specific to each of the three + possibilities: + + In the first case, the node performs a number of completely useless + DNS lookups as it will not be able to use the returned AAAA records + anyway. (The only exception is where the application desires to know + what's in the DNS, but not use the result for communication.) One + should be able to disable these unnecessary queries, for both latency + and reliability reasons. However, as IPv6 has not been enabled, the + connections to IPv6 addresses fail immediately, and if the + application is programmed properly, the application can fall + gracefully back to IPv4 [17]. + + The second case is similar to the first, except it happens to a + smaller set of nodes when IPv6 has been enabled but connectivity has + not been provided yet; similar considerations apply, with the + exception that IPv6 records, when returned, will be actually tried + first which may typically lead to long timeouts. + + The third case is a bit more complex: optimizing away the DNS lookups + with only link-locals is probably safe (but may be desirable with + different lookup services which getaddrinfo() may support), as the + link-locals are typically automatically generated when IPv6 is + enabled, and do not indicate any form of IPv6 connectivity. That + is, performing DNS lookups only when a non-link-local address has + been configured on any interface could be beneficial -- this would be + an indication that either the address has been configured either from + a router advertisement, DHCPv6, or manually. Each would indicate at + least some form of IPv6 connectivity, even though there would not be + + + +Durand, et al. Expires May 1, 2004 [Page 9] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + guarantees of it. + + XXXX: are there any actual recommendations in here?!? :-) + +5.2 Recursive DNS Server Discovery + + Recursive IPv6 DNS server discovery is a subject of active debate at + the moment: the main proposed mechanisms include the use of + well-known addresses [18], the use of Router Advertisements to convey + the information [19], and using DHCPv6 (or the stateless subset of it + [20]) for DNS server configuration. No consensus has been reached + yet. + + Note that IPv6 DNS server discovery, while an important topic, is not + required for dual-stack nodes with dual-stack networks: IPv6 DNS + records can very well be queried over IPv4. + +5.3 IPv6 Transport Guidelines for Resolvers + + As described in Section 1.3 and [3], the recursive resolvers should + be IPv4-only or dual-stack to be able to reach any IPv4-only DNS + server. Note that this requirement is also fulfilled by an IPv6-only + stub resolver pointing to a dual-stack recursive DNS resolver. + +6. Considerations about Forward DNS Updating + + While the topic how to enable updating the forward DNS, i.e., the + mapping from names to the correct new addresses, is not specific to + IPv6, it bears thinking about especially due to adding Stateless + Address Autoconfiguration [21] to the mix. + + Typically forward DNS updates are more manageable than doing them in + the reverse DNS, because the updater can, typically, be assumed to + "own" a certain DNS name -- and we can create a form of security + association with the DNS name and the node allowed to update it to + point to a new address. + + A more complex form of DNS updates -- adding a whole new name to a + DNS zone, instead of updating an existing one -- is considered + out-of-scope (XXX: at least for now, send text/feedback!). + +6.1 Manual or Custom DNS Updates + + The DNS mappings can be maintained by hand, in a semi-automatic + fashion or by running non-standardized protocols. These are not + considered at more length in this memo. + + + + + +Durand, et al. Expires May 1, 2004 [Page 10] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + +6.2 Dynamic DNS + + Dynamic DNS updates (DDNS) [22][23] is a standardized mechanism for + dynamically updating the DNS. It works equally well with stateless + address autoconfiguration (SLAAC), DHCPv6 or manual address + configuration. The only (minor) twist that with SLAAC, the DNS + server cannot tie the authentication of the user to the IP address, + and stronger mechanisms must be used. Actually, relying on IP + addresses for Dynamic DNS is rather insecure at best, so this is + probably not a significant problem (but requires that the + authorization keying will be explicitly configured). + + Note that the nodes must somehow be configured with the information + about the servers where they will attempt to update their addresses, + sufficient security material for authenticating themselves to the + server, and the hostname they will be updating. Unless otherwise + configured, the first could be obtained by looking up the authorative + name servers for the hostname; the second must be configured + explicitly unless one chooses to trust the IP address -based + authentication (not a good idea); and lastly, the nodename is + typically pre-configured somehow on the node, e.g. at install time. + + Care should be observed when updating the addresses not to use longer + TTLs for addresses than are preferred lifetimes for the + autoconfigured addresses, so that if the node is renumberedin a + managed fashion, the amount of stale DNS information is kept to the + minimum. + +7. Considerations about Reverse DNS Updating + + Forward DNS updating was rather straightforward; reverse DNS is + significantly trickier especially with certain mechanisms. However, + first it makes sense to look at the applicability of reverse DNS in + the first place. + +7.1 Applicability of Reverse DNS + + Today, some applications use reverse DNS to either look up some hints + about the topological information associated with an address (e.g. + resolving web server access logs), or as a weak form of a security + check, to get a feel whether the user's network administrator has + "authorized" the use of the address (on the premises that adding a + reverse record for an address would signal some form of + authorization). + + One additional, maybe slightly more useful applicability is ensuring + the reverse and forward DNS contents match and correspond to a + configured name or domain. As a security check, it is typically + + + +Durand, et al. Expires May 1, 2004 [Page 11] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + accompanied by other mechanisms, such as a user/password login; the + main purpose of the DNS check is to weed out the majority of + unauthorized users, and if someone managed to bypass the checks, he + would still need to authenticate "properly". + + It is not clear whether it makes sense to require or recommend that + reverse DNS records be updated. In many cases, it would just make + more sense to use proper mechanisms for security (or topological + information lookup) in the first place. At minimum, the applications + which use it as a generic authorization (in the sense that a record + exists at all) should be modified as soon as possible to avoid such + lookups completely. + +7.2 Manual or Custom DNS Updates + + Reverse DNS can be updated using manual or custom methods, naturally. + These are not further described here, except for one special case. + + One way to deploy reverse DNS would be to use wildcard records, for + example, by configuring one name for a subnet (/64) or a site (/48). + Naturally, such a name could not be verified from the forward DNS, + but would at least provide some form of "topological information" or + "weak authorization" if that is really considered to be useful. Note + that this is not actually updating the DNS as such, as the whole + point is to avoid DNS updates completely by manual configuration of a + generic name. + +7.3 DDNS with Stateless Address Autoconfiguration + + Dynamic DNS with SLAAC is a bit complicated, but manageable with a + rather low form of security with some implementation. + + Every node on a link must then be allowed to insert its own reverse + DNS record in the reverse zone. However, in the typical case, there + can be no stronger form of authentication between the nodes and the + server than the source IP address (the user may roam to other + administrative domains as well, requiring updates to foreign DNS + servers), which might make attacks more lucrative. + + Moreover, the reverse zones must be cleaned up by some janitorial + process: the node does not typically know a priori that it will be + disconnected, and cannot send a DNS update using the correct source + address to remove a record. + +7.4 DDNS With DHCP + + With DHCP, the reverse DNS name is typically already inserted to the + DNS that reflects to the name (e.g., "dhcp-67.example.com"). + + + +Durand, et al. Expires May 1, 2004 [Page 12] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + If a more explicit control is required, similar considerations as + with SLAAC apply, except for the fact that typically one must update + a reverse DNS record instead of inserting one -- due to a denser + address assignment policy -- and updating a record seems like a + slightly more difficult thing to secure. + +7.5 DDNS with Dynamic Prefix Delegation + + In cases where more than one address is being used and updated, one + should consider where the updated server resides. That is, whether + the prefixes have been delegated to a node in the local site, or + whether they reside elsewhere, e.g., at the ISP. The reverse DNS + updates are typically easier to manage if they can be done within a + single administrative entity -- and therefore, if a reverse DNS + delegation has been made, it may be easier to enable reverse DNS at + the site, e.g. by a wildcard record, or by some DNS update mechanism. + +8. Miscellaneous DNS Considerations + + This section describes miscellaneous considerations about DNS which + seem related to IPv6, for which no better place has been found in + this document. + +8.1 NAT-PT with DNS-ALG + + NAT-PT [24] DNS-ALG is a critical component (unless something + replacing that functionality is specified) which mangles A records to + look like AAAA records to the IPv6-only nodes. Numerous problems have + been identified with DNS-ALG [25]. + +8.2 Renumbering Procedures and Applications' Use of DNS + + One of the most difficult problems of renumbering procedures [26] is + that an application which gets a DNS name disregards information such + as TTL, and uses the result obtained from DNS as long as it happens + to be stored in the memory of the application. For applications + which run for a long time, this could be days, weeks or even months; + some applications may be clever enough to organize the data + structures and functions in such a manner that look-ups get refreshed + now and then. This is an issue with no clear solution. + +9. Acknowledgements + + Some recommendations (Section 4.3, Section 5.1) about IPv6 service + provisioning were moved here from [27] by Erik Nordmark and Bob + Gilligan. Havard Eidnes provided useful feedback and improvements. + + + + + +Durand, et al. Expires May 1, 2004 [Page 13] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + +10. Security Considerations + + This document reviews the operational procedures for IPv6 DNS + operations and does not have security considerations in itself. + + However, it is worth nothing that in particular with Dynamic DNS + Updates, security models based on the source address validation are + very weak and cannot be recommended. On the other hand, it should be + noted that setting up an authorization mechanism (e.g., a shared + secret, or public-private keys) between a node and the DNS server has + to be done manually, and may require quite a bit of time and + expertise. + + To re-emphasize which was already stated, reverse DNS checks provide + very weak security at best, and the only (questionable) + security-related use for them may be in conjunction with other + mechanisms when authenticating a user. + +Normative References + + [1] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS + Extensions to Support IP Version 6", RFC 3596, October 2003. + + [2] Bush, R., Durand, A., Fink, B., Gudmundsson, O. and T. Hain, + "Representing Internet Protocol version 6 (IPv6) Addresses in + the Domain Name System (DNS)", RFC 3363, August 2002. + + [3] Durand, A. and J. Ihren, "DNS IPv6 transport operational + guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-01 (work + in progress), October 2003. + +Informative References + + [4] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August + 2001. + + [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) + Addressing Architecture", RFC 3513, April 2003. + + [6] Huitema, C. and B. Carpenter, "Deprecating Site Local + Addresses", draft-ietf-ipv6-deprecate-site-local-02 (work in + progress), November 2003. + + [7] Hazel, P., "IP Addresses that should never appear in the public + DNS", draft-ietf-dnsop-dontpublish-unreachable-03 (work in + progress), February 2002. + + [8] Narten, T. and R. Draves, "Privacy Extensions for Stateless + + + +Durand, et al. Expires May 1, 2004 [Page 14] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + Address Autoconfiguration in IPv6", RFC 3041, January 2001. + + [9] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via + IPv4 Clouds", RFC 3056, February 2001. + + [10] Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work in + progress), October 2002. + + [11] Bush, R. and J. Damas, "Delegation of 2.0.0.2.ip6.arpa", + draft-ymbk-6to4-arpa-delegation-00 (work in progress), February + 2003. + + [12] Morishita, Y. and T. Jinmei, "Common Misbehavior against DNS + Queries for IPv6 Addresses", + draft-morishita-dnsop-misbehavior-against-aaaa-00 (work in + progress), June 2003. + + [13] Larson, M. and P. Barber, "Observed DNS Resolution + Misbehavior", draft-ietf-dnsop-bad-dns-res-01 (work in + progress), June 2003. + + [14] Savola, P., "Moving from 6bone to IPv6 Internet", + draft-savola-v6ops-6bone-mess-01 (work in progress), November + 2002. + + [15] Roy, S., "Dual Stack IPv6 on by Default", + draft-ietf-v6ops-v6onbydefault-00 (work in progress), October + 2003. + + [16] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered + Harmful", draft-ietf-v6ops-onlinkassumption-00 (work in + progress), October 2003. + + [17] Shin, M., "Application Aspects of IPv6 Transition", + draft-shin-v6ops-application-transition-02 (work in progress), + October 2003. + + [18] Ohta, M., "Preconfigured DNS Server Addresses", + draft-ohta-preconfigured-dns-00 (work in progress), July 2003. + + [19] Jeong, J., "IPv6 DNS Discovery based on Router Advertisement", + draft-jeong-dnsop-ipv6-dns-discovery-00 (work in progress), + July 2003. + + [20] Droms, R., "A Guide to Implementing Stateless DHCPv6 Service", + draft-ietf-dhc-dhcpv6-stateless-01 (work in progress), October + 2003. + + + + +Durand, et al. Expires May 1, 2004 [Page 15] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + [21] Thomson, S. and T. Narten, "IPv6 Stateless Address + Autoconfiguration", RFC 2462, December 1998. + + [22] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic + Updates in the Domain Name System (DNS UPDATE)", RFC 2136, + April 1997. + + [23] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000. + + [24] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - + Protocol Translation (NAT-PT)", RFC 2766, February 2000. + + [25] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", + draft-durand-v6ops-natpt-dns-alg-issues-00 (work in progress), + February 2003. + + [26] Baker, F., "Procedures for Renumbering an IPv6 Network without + a Flag Day", draft-baker-ipv6-renumber-procedure-01 (work in + progress), October 2003. + + [27] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for + IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-01 (work in + progress), October 2003. + + +Authors' Addresses + + Alain Durand + SUN Microsystems, Inc. + 17 Network circle UMPL17-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, et al. Expires May 1, 2004 [Page 16] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + Pekka Savola + CSC/FUNET + + Espoo + Finland + + EMail: psavola@funet.fi + +Appendix A. Site-local Addressing Considerations for DNS + + As site-local addressing is being deprecated, and it is not yet clear + whether an addressing-based replacement (and which kind) is devised, + the considerations for site-local addressing are introduced here. + + The interactions with DNS come in two flavors: forward and reverse + DNS. + + To actually use site-local addresses within a site, this implies the + deployment of a "split-faced" or a fragmented DNS name space, for the + zones internal to the site, and the outsiders' view to it. The + procedures to achieve this are not elaborated here. The implication + is that site-local addresses must not be published in the public DNS. + + To faciliate reverse DNS (if desired) with site-local addresses, the + stub resolvers must look for DNS information from the local DNS + servers, not e.g. starting from the root servers, so that the + site-local information may be provided locally. Note that the + experience private addresses in IPv4 has shown that the root servers + get loaded for requests for private address lookups in any case. + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires May 1, 2004 [Page 17] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + +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. + + +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 + + + +Durand, et al. Expires May 1, 2004 [Page 18] + +Internet-Draft Considerations and Issues with IPv6 DNS Nov 2003 + + + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Durand, et al. Expires May 1, 2004 [Page 19] + +