+++ /dev/null
-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
- <draft-ietf-dnsop-ipv6-dns-issues-02.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
-
-
-
-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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
--- /dev/null
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+
projects / thirdparty / bind9.git / commitdiff
