draft-ietf-dnsop-ipv6-dns-issues-06.txt   draft-ietf-dnsop-ipv6-dns-issues-07.txt 
DNS Operations WG A. Durand DNS Operations WG A. Durand
Internet-Draft SUN Microsystems, Inc. Internet-Draft SUN Microsystems, Inc.
Expires: September 30, 2004 J. Ihren Expires: November 10, 2004 J. Ihren
Autonomica Autonomica
P. Savola P. Savola
CSC/FUNET CSC/FUNET
Apr 2004 May 12, 2004
Operational Considerations and Issues with IPv6 DNS Operational Considerations and Issues with IPv6 DNS
draft-ietf-dnsop-ipv6-dns-issues-06.txt draft-ietf-dnsop-ipv6-dns-issues-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 30, 2004. This Internet-Draft will expire on November 10, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This memo presents operational considerations and issues with IPv6 This memo presents operational considerations and issues with IPv6
Domain Name System (DNS), including a summary of special IPv6 Domain Name System (DNS), including a summary of special IPv6
addresses, documentation of known DNS implementation misbehaviour, addresses, documentation of known DNS implementation misbehaviour,
recommendations and considerations on how to perform DNS naming for recommendations and considerations on how to perform DNS naming for
service provisioning and for DNS resolver IPv6 support, service provisioning and for DNS resolver IPv6 support,
considerations for DNS updates for both the forward and reverse considerations for DNS updates for both the forward and reverse
trees, and miscellaneous issues. This memo is aimed to include a trees, and miscellaneous issues. This memo is aimed to include a
summary of information about IPv6 DNS considerations for those who summary of information about IPv6 DNS considerations for those who
have experience with IPv4 DNS. have experience with IPv4 DNS.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 3 1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4
1.2 Independence of DNS Transport and DNS Records . . . . . . 3 1.2 Independence of DNS Transport and DNS Records . . . . . . 4
1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 4 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5
2. DNS Considerations about Special IPv6 Addresses . . . . . . . 4 1.4 Query Type 'ANY' and A/AAAA Records . . . . . . . . . . . 5
2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 4 2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5
2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 5 2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6
2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6
3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 5 2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 6 3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7
3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 6 3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7
4. Recommendations for Service Provisioning using DNS . . . . . . 6 3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7
4.1 Use of Service Names instead of Node Names . . . . . . . . 6 4. Recommendations for Service Provisioning using DNS . . . . . . 8
4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 7 4.1 Use of Service Names instead of Node Names . . . . . . . . 8
4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 8 4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8
4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 8 4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9
4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 10 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10
4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 11 4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 11
5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 11 4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 12
5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 11 5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13
5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 13 5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 13
5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 14 5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 14
6. Considerations about Forward DNS Updating . . . . . . . . . . 14 5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 15
6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 14 6. Considerations about Forward DNS Updating . . . . . . . . . . 15
6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 14 6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 15
7. Considerations about Reverse DNS Updating . . . . . . . . . . 15 6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 15
7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 15 7. Considerations about Reverse DNS Updating . . . . . . . . . . 16
7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 17
7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 16 7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 17
7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 17 7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 18
7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 18 7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 18
8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 19 7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 19
8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 19 8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 20
8.2 Renumbering Procedures and Applications' Use of DNS . . . 19 8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 20
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8.2 Renumbering Procedures and Applications' Use of DNS . . . 20
10. Security Considerations . . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . 21
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
11.2 Informative References . . . . . . . . . . . . . . . . . . . 20 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 11.2 Informative References . . . . . . . . . . . . . . . . . . . 21
A. Site-local Addressing Considerations for DNS . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 25 A. Site-local Addressing Considerations for DNS . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . 27
1. Introduction 1. Introduction
This memo presents operational considerations and issues with IPv6 This memo presents operational considerations and issues with IPv6
DNS; it is meant to be an extensive summary and a list of pointers DNS; it is meant to be an extensive summary and a list of pointers
for more information about IPv6 DNS considerations for those with for more information about IPv6 DNS considerations for those with
experience with IPv4 DNS. experience with IPv4 DNS.
The purpose of this document is to give information about various The purpose of this document is to give information about various
issues and considerations related to DNS operations with IPv6; it is issues and considerations related to DNS operations with IPv6; it is
skipping to change at page 4, line 8 skipping to change at page 5, line 8
stance on any other use of DNAME records [5]. stance on any other use of DNAME records [5].
1.2 Independence of DNS Transport and DNS Records 1.2 Independence of DNS Transport and DNS Records
DNS has been designed to present a single, globally unique name space DNS has been designed to present a single, globally unique name space
[7]. This property should be maintained, as described here and in [7]. This property should be maintained, as described here and in
Section 1.3. Section 1.3.
In DNS, the IP version used to transport the queries and responses is In DNS, the IP version used to transport the queries and responses is
independent of the records being queried: AAAA records can be queried 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 over IPv4, and A records over IPv6. The DNS servers must not make
assumptions about what data to return for Answer and Authority any assumptions about what data to return for Answer and Authority
sections. sections.
However, there is some debate whether the addresses in Additional However, there is some debate whether the addresses in Additional
section could be selected or filtered using hints obtained from which section could be selected or filtered using hints obtained from which
transport was being used; this has some obvious problems because in transport was being used; this has some obvious problems because in
many cases the transport protocol does not correlate with the many cases the transport protocol does not correlate with the
requests, and because a "bad" answer is in a way worse than no answer 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 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 name received in the additional record does not have any AAAA records
to begin with). to begin with).
skipping to change at page 4, line 35 skipping to change at page 5, line 35
IPv4 transport can be used to query IPv6 records and vice versa. IPv4 transport can be used to query IPv6 records and vice versa.
1.3 Avoiding IPv4/IPv6 Name Space Fragmentation 1.3 Avoiding IPv4/IPv6 Name Space Fragmentation
To avoid the DNS name space from fragmenting into parts where some To avoid the DNS name space from fragmenting into parts where some
parts of DNS are only visible using IPv4 (or IPv6) transport, the parts of DNS are only visible using IPv4 (or IPv6) transport, the
recommendation is to always keep at least one authoritative server recommendation is to always keep at least one authoritative server
IPv4-enabled, and to ensure that recursive DNS servers support IPv4. IPv4-enabled, and to ensure that recursive DNS servers support IPv4.
See DNS IPv6 transport guidelines [3] for more information. See DNS IPv6 transport guidelines [3] for more information.
1.4 Query Type 'ANY' and A/AAAA Records
QTYPE=* is typically only used for debugging or management purposes;
it is worth keeping in mind that QTYPE=* ("ANY" queries; note that
QTYPE=* is the technically correct, though oxymoronic, term)
literally return any available RRsets, not *all* the RRsets, as only
some of these may be present in the caches. Therefore, to get both A
and AAAA records reliably, two separate queries must be made.
2. DNS Considerations about Special IPv6 Addresses 2. DNS Considerations about Special IPv6 Addresses
There are a couple of IPv6 address types which are somewhat special; There are a couple of IPv6 address types which are somewhat special;
these are considered here. these are considered here.
2.1 Limited-scope Addresses 2.1 Limited-scope Addresses
The IPv6 addressing architecture [6] includes two kinds of local-use The IPv6 addressing architecture [6] includes two kinds of local-use
addresses: link-local (fe80::/10) and site-local (fec0::/10). The addresses: link-local (fe80::/10) and site-local (fec0::/10). The
site-local addresses are being deprecated [8], and are only discussed site-local addresses are being deprecated [8], and are only discussed
skipping to change at page 5, line 18 skipping to change at page 6, line 29
"privacy addresses") use a random number as the interface identifier. "privacy addresses") use a random number as the interface identifier.
Publishing DNS records relating to such addresses would defeat the Publishing DNS records relating to such addresses would defeat the
purpose of the mechanism and is not recommended. If absolutely purpose of the mechanism and is not recommended. If absolutely
necessary, a mapping could be made to some non-identifiable name, as necessary, a mapping could be made to some non-identifiable name, as
described in [10]. described in [10].
2.3 6to4 Addresses 2.3 6to4 Addresses
6to4 [11] specifies an automatic tunneling mechanism which maps a 6to4 [11] specifies an automatic tunneling mechanism which maps a
public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48. public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.
Providing reverse DNS delegation path for such addresses is a Providing reverse DNS delegation path for such addresses is not
challenge. straightforward and practically impossible.
Note that it does not seem feasible to provide reverse DNS with the Note that it does not seem feasible to provide reverse DNS with the
other automatic tunneling mechanism, Teredo [12]; this is because the other automatic tunneling mechanism, Teredo [12]; this is because the
IPv6 address is based on the IPv4 address and UDP port of the current IPv6 address is based on the IPv4 address and UDP port of the current
NAT mapping which is likely to be relatively short-lived. NAT mapping which is likely to be relatively short-lived.
If the reverse DNS population would be desirable (see Section 7.1 for If the reverse DNS population would be desirable (see Section 7.1 for
applicability), there are a number of ways to tackle the delegation applicability), there are a number of ways to tackle the delegation
path problem [13], some more applicable than the others. path problem [13], some more applicable than the others.
skipping to change at page 6, line 20 skipping to change at page 7, line 31
load-balancers which have been noticed and documented [16]: some load-balancers which have been noticed and documented [16]: some
implementations silently drop queries for unimplemented DNS records implementations silently drop queries for unimplemented DNS records
types, or provide wrong answers to such queries (instead of a proper types, or provide wrong answers to such queries (instead of a proper
negative reply). While typically these issues are not limited to negative reply). While typically these issues are not limited to
AAAA records, the problems are aggravated by the fact that AAAA AAAA records, the problems are aggravated by the fact that AAAA
records are being queried instead of (mainly) A records. records are being queried instead of (mainly) A records.
The problems are serious because when looking up a DNS name, typical The problems are serious because when looking up a DNS name, typical
getaddrinfo() implementations, with AF_UNSPEC hint given, first try getaddrinfo() implementations, with AF_UNSPEC hint given, first try
to query the AAAA records of the name, and after receiving a 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 response, query the A records. This is done in a serial fashion --
the first query is never responded to (instead of properly returning if the first query is never responded to (instead of properly
a negative answer), significant timeouts will occur. returning a negative answer), significant timeouts will occur.
In consequence, this is an enormous problem for IPv6 deployments, and In consequence, this is an enormous problem for IPv6 deployments, and
in some cases, IPv6 support in the software has even been disabled in some cases, IPv6 support in the software has even been disabled
due to these problems. due to these problems.
The solution is to fix or retire those misbehaving implementations, The solution is to fix or retire those misbehaving implementations,
but that is likely not going to be effective. There are some but that is likely not going to be effective. There are some
possible ways to mitigate the problem, e.g. by performing the lookups possible ways to mitigate the problem, e.g. by performing the
somewhat in parallel and reducing the timeout as long as at least one lookups somewhat in parallel and reducing the timeout as long as at
answer has been received; but such methods remain to be investigated; least one answer has been received; but such methods remain to be
slightly more on this is included in Section 5. investigated; slightly more on this is included in Section 5.
3.2 Misbehaviour of DNS Resolvers 3.2 Misbehaviour of DNS Resolvers
Several classes of misbehaviour have also been noticed in DNS Several classes of misbehaviour have also been noticed in DNS
resolvers [17]. However, these do not seem to directly impair IPv6 resolvers [17]. However, these do not seem to directly impair IPv6
use, and are only referred to for completeness. use, and are only referred to for completeness.
4. Recommendations for Service Provisioning using DNS 4. Recommendations for Service Provisioning using DNS
When names are added in the DNS to facilitate a service, there are When names are added in the DNS to facilitate a service, there are
skipping to change at page 7, line 18 skipping to change at page 8, line 30
For example, assume a node named "pobox.example.com" provides both For example, assume a node named "pobox.example.com" provides both
SMTP and IMAP service. Instead of configuring the MX records to SMTP and IMAP service. Instead of configuring the MX records to
point at "pobox.example.com", and configuring the mail clients 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 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 e.g. "smtp.example.com" for SMTP (for both message submission and
mail relaying between SMTP servers) and "imap.example.com" for IMAP. mail relaying between SMTP servers) and "imap.example.com" for IMAP.
Note that in the specific case of SMTP relaying, the server itself Note that in the specific case of SMTP relaying, the server itself
must typically also be configured to know all its names to ensure must typically also be configured to know all its names to ensure
loops do not occur. DNS can provide a layer of indirection between loops do not occur. DNS can provide a layer of indirection between
service names and where the service actually is, and using which service names and where the service actually is, and using which
addresses. addresses. (Obviously, when wanting to reach a specific node, one
should use the hostname rather than a service name.)
This is a good practice with IPv4 as well, because it provides more This is a good practice with IPv4 as well, because it provides more
flexibility and enables easier migration of services from one host to flexibility and enables easier migration of services from one host to
another. A specific reason why this is relevant for IPv6 is that the another. A specific reason why this is relevant for IPv6 is that the
different services may have a different level of IPv6 support -- that different services may have a different level of IPv6 support -- that
is, one node providing multiple services might want to enable just is, one node providing multiple services might want to enable just
one service to be IPv6-visible while keeping some others as one service to be IPv6-visible while keeping some others as
IPv4-only. Using service names enables more flexibility with IPv4-only. Using service names enables more flexibility with
different IP versions as well. different IP versions as well.
skipping to change at page 8, line 43 skipping to change at page 10, line 8
quality, using the appropriate metrics for the service (e.g., quality, using the appropriate metrics for the service (e.g.,
latency, throughput, low packet loss, general reliability, etc.) -- latency, throughput, low packet loss, general reliability, etc.) --
this is typically very important especially for interactive or this is typically very important especially for interactive or
real-time services. In many cases, the quality of IPv6 connectivity 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 is not yet equal to that of IPv4, at least globally -- this has to be
taken into consideration when enabling services [18]. taken into consideration when enabling services [18].
4.4 Behaviour of Additional Data in IPv4/IPv6 Environments 4.4 Behaviour of Additional Data in IPv4/IPv6 Environments
Consider the case where the query name is so long, the number of the Consider the case where the query name is so long, the number of the
additional records (originated from "glue") is so high, or for other additional records is so high, or for other reasons that the entire
reasons that the entire response would not fit in a single UDP response would not fit in a single UDP packet. In some cases, the
packet. In some cases, the responder truncates the response with the responder truncates the response with the TC bit being set (leading
TC bit being set (leading to a retry with TCP), in order for the to a retry with TCP), in order for the querier to get the entire
querier to get the entire response later. response later.
However, note that if too much additional information that is not However, note that if too much additional information that is not
strictly necessary would be added, one should remove unnecessary strictly necessary would be added, one should remove unnecessary
information instead of setting TC bit for this "courtesy" information information instead of setting TC bit for this "courtesy" information
[19]. [19].
Also notice that there are two kinds of additional data: Also notice that there are two kinds of additional data:
1. "critical" additional data; this must be included (all the 1. glue, i.e., "critical" additional data; this must be included in
possible RRsets) in all scenarios, and all scenarios, with all the RRsets as possible, and
2. "courtesy" additional data; this could be sent in full, with only 2. "courtesy" additional data; this could be sent in full, with only
a few RRsets, or with no RRsets, and can be fetched separately as a few RRsets, or with no RRsets, and can be fetched separately as
well, but which could lead to non-optimal results. well but could lead to non-optimal results.
Meanwhile, resource record sets (RRsets) are never "broken up", so if Meanwhile, resource record sets (RRsets) are never "broken up", so if
a name has 4 A records and 5 AAAA records, you can either return all a name has 4 A records and 5 AAAA records, you can either return all
9, all 4 A records, all 5 AAAA records or nothing. Notice that for 9, all 4 A records, all 5 AAAA records or nothing. Notice that for
the "critical" additional data getting all the RRsets can be the "critical" additional data getting all the RRsets can be
critical. critical.
An example of the "courtesy" additional data is A/AAAA records in An example of the "courtesy" additional data is A/AAAA records in
conjunction of MX records as shown in the next section; an example of conjunction of MX records as shown in the next section; an example of
the "critical" additional data is shown below (where getting both the the "critical" additional data is shown below (where getting both the
skipping to change at page 11, line 35 skipping to change at page 12, line 49
particular TTL configuration. For example, even if an application particular TTL configuration. For example, even if an application
gets a response that only has the A record in the example described gets a response that only has the A record in the example described
above, it should not assume there is no AAAA record for above, it should not assume there is no AAAA record for
"foo.example.com". Instead, the application should try to fetch the "foo.example.com". Instead, the application should try to fetch the
missing records by itself if it needs the record. missing records by itself if it needs the record.
4.6 IPv6 Transport Guidelines for DNS Servers 4.6 IPv6 Transport Guidelines for DNS Servers
As described in Section 1.3 and [3], there should continue to be at As described in Section 1.3 and [3], there should continue to be at
least one authoritative IPv4 DNS server for every zone, even if the least one authoritative IPv4 DNS server for every zone, even if the
zone has only IPv6 records. (Note that obviously, having more servers zone has only IPv6 records. (Note that obviously, having more
with robust connectivity would be preferable, but this is the minimum servers with robust connectivity would be preferable, but this is the
recommendation; also see [21].) minimum recommendation; also see [21].)
5. Recommendations for DNS Resolver IPv6 Support 5. Recommendations for DNS Resolver IPv6 Support
When IPv6 is enabled on a node, there are several things to consider When IPv6 is enabled on a node, there are several things to consider
to ensure that the process is as smooth as possible. to ensure that the process is as smooth as possible.
5.1 DNS Lookups May Query IPv6 Records Prematurely 5.1 DNS Lookups May Query IPv6 Records Prematurely
The system library that implements the getaddrinfo() function for The system library that implements the getaddrinfo() function for
looking up names is a critical piece when considering the robustness looking up names is a critical piece when considering the robustness
skipping to change at page 13, line 16 skipping to change at page 14, line 30
The second case is similar to the first, except it happens to a 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 smaller set of nodes when IPv6 has been enabled but connectivity has
not been provided yet; similar considerations apply, with the not been provided yet; similar considerations apply, with the
exception that IPv6 records, when returned, will be actually tried exception that IPv6 records, when returned, will be actually tried
first which may typically lead to long timeouts. first which may typically lead to long timeouts.
The third case is a bit more complex: optimizing away the DNS lookups 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 with only link-locals is probably safe (but may be desirable with
different lookup services which getaddrinfo() may support), as the different lookup services which getaddrinfo() may support), as the
link-locals are typically automatically generated when IPv6 is link-locals are typically automatically generated when IPv6 is
enabled, and do not indicate any form of IPv6 connectivity. That enabled, and do not indicate any form of IPv6 connectivity. That is,
is, performing DNS lookups only when a non-link-local address has performing DNS lookups only when a non-link-local address has been
been configured on any interface could be beneficial -- this would be configured on any interface could be beneficial -- this would be an
an indication that either the address has been configured either from indication that either the address has been configured either from a
a router advertisement, DHCPv6 [25], or manually. Each would router advertisement, DHCPv6 [25], or manually. Each would indicate
indicate at least some form of IPv6 connectivity, even though there at least some form of IPv6 connectivity, even though there would not
would not be guarantees of it. be guarantees of it.
These issues should be analyzed at more depth, and the fixes found These issues should be analyzed at more depth, and the fixes found
consensus on, perhaps in a separate document. consensus on, perhaps in a separate document.
5.2 Obtaining a List of DNS Recursive Resolvers 5.2 Obtaining a List of DNS Recursive Resolvers
In scenarios where DHCPv6 is available, a host can discover a list of In scenarios where DHCPv6 is available, a host can discover a list of
DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server" DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
option [29]. This option can be passed to a host through a subset of option [29]. This option can be passed to a host through a subset of
DHCPv6 [28]. DHCPv6 [28].
The IETF is considering the development of alternative mechanisms for The IETF is considering the development of alternative mechanisms for
obtaining the list of DNS recursive name servers when DHCPv6 is obtaining the list of DNS recursive name servers when DHCPv6 is
unavailable or inappropriate. No decision about taking on this unavailable or inappropriate. No decision about taking on this
development work has been reached as of this writing (April 2004). development work has been reached as of this writing (May 2004).
In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
under consideration for development of dnsop WG include the use of under consideration for development of dnsop WG include the use of
well-known addresses [26], the use of Router Advertisements to convey well-known addresses [26], the use of Router Advertisements to convey
the information [27]. the information [27].
Note that even though IPv6 DNS resolver discovery is a recommended Note that even though IPv6 DNS resolver discovery is a recommended
procedure, it is not required for dual-stack nodes in dual-stack procedure, it is not required for dual-stack nodes in dual-stack
networks as IPv6 DNS records can be queried over IPv4 as well as networks as IPv6 DNS records can be queried over IPv4 as well as
IPv6. Obviously, nodes which are meant to function without manual IPv6. Obviously, nodes which are meant to function without manual
skipping to change at page 17, line 5 skipping to change at page 18, line 19
The address space administrator decides whether the hosts are trusted The address space administrator decides whether the hosts are trusted
to update their reverse DNS records or not. If they are, a simple to update their reverse DNS records or not. If they are, a simple
address-based authorization is typically sufficient (i.e., check that address-based authorization is typically sufficient (i.e., check that
the DNS update is done from the same IP address as the record being the DNS update is done from the same IP address as the record being
updated); stronger security can also be used [32]. If they aren't updated); stronger security can also be used [32]. If they aren't
allowed to update the reverses, no update can occur. allowed to update the reverses, no update can occur.
Address-based authorization is simpler with reverse DNS (as there is Address-based authorization is simpler with reverse DNS (as there is
a connection between the record and the address) than with forward a connection between the record and the address) than with forward
DNS. However, when stronger form of security is used, forward DNS DNS. However, when a stronger form of security is used, forward DNS
updates are simpler to manage because the host knows the record it's updates are simpler to manage because the host knows the record it's
updating, and can be assumed to have an association with the domain. updating, and can be assumed to have an association with the domain.
Note that the user may roam to different networks, and does not Note that the user may roam to different networks, and does not
necessarily have any association with the owner of that address space necessarily have any association with the owner of that address space
-- so, assuming stronger form of authorization for reverse DNS -- so, assuming stronger form of authorization for reverse DNS
updates than an address association is generally unfeasible. updates than an address association is generally unfeasible.
Moreover, the reverse zones must be cleaned up by an unspecified Moreover, the reverse zones must be cleaned up by an unspecified
janitorial process: the node does not typically know a priori that it janitorial process: the node does not typically know a priori that it
will be disconnected, and cannot send a DNS update using the correct will be disconnected, and cannot send a DNS update using the correct
skipping to change at page 18, line 27 skipping to change at page 19, line 40
DDNS updates are made. That is, where the DNS server is located: DDNS updates are made. That is, where the DNS server is located:
1. At the same organization as the prefix delegator. 1. At the same organization as the prefix delegator.
2. At the site where the prefixes are delegated to. In this case, 2. At the site where the prefixes are delegated to. In this case,
the authority of the DNS reverse zone corresponding to the the authority of the DNS reverse zone corresponding to the
delegated prefix is also delegated to the site. delegated prefix is also delegated to the site.
3. Elsewhere; this implies a relationship between the site and where 3. Elsewhere; this implies a relationship between the site and where
DNS server is located, and such a relationship should be rather DNS server is located, and such a relationship should be rather
straightforward to secure as well. Like in the previous case, the straightforward to secure as well. Like in the previous case,
authority of the DNS reverse zone is also delegated. the authority of the DNS reverse zone is also delegated.
In the first case, managing the reverse DNS (delegation) is simpler In the first case, managing the reverse DNS (delegation) is simpler
as the DNS server and the prefix delegator are in the same as the DNS server and the prefix delegator are in the same
administrative domain (as there is no need to delegate anything at administrative domain (as there is no need to delegate anything at
all); alternatively, the prefix delegator might forgo DDNS reverse all); alternatively, the prefix delegator might forgo DDNS reverse
capability altogether, and use e.g., wildcard records (as described capability altogether, and use e.g., wildcard records (as described
in Section 7.2). In the other cases, it can be slighly more in Section 7.2). In the other cases, it can be slighly more
difficult, particularly as the site will have to configure the DNS difficult, particularly as the site will have to configure the DNS
server to be authoritative for the delegated reverse zone, implying server to be authoritative for the delegated reverse zone, implying
automatic configuration of the DNS server -- as the prefix may be automatic configuration of the DNS server -- as the prefix may be
skipping to change at page 19, line 15 skipping to change at page 20, line 26
8. Miscellaneous DNS Considerations 8. Miscellaneous DNS Considerations
This section describes miscellaneous considerations about DNS which This section describes miscellaneous considerations about DNS which
seem related to IPv6, for which no better place has been found in seem related to IPv6, for which no better place has been found in
this document. this document.
8.1 NAT-PT with DNS-ALG 8.1 NAT-PT with DNS-ALG
NAT-PT [36] DNS-ALG is a critical component (unless something NAT-PT [36] DNS-ALG is a critical component (unless something
replacing that functionality is specified) which mangles A records to replacing that functionality is specified) which mangles A records to
look like AAAA records to the IPv6-only nodes. Numerous problems have look like AAAA records to the IPv6-only nodes. Numerous problems
been identified with DNS-ALG [39]. have been identified with DNS-ALG [39].
8.2 Renumbering Procedures and Applications' Use of DNS 8.2 Renumbering Procedures and Applications' Use of DNS
One of the most difficult problems of systematic IP address One of the most difficult problems of systematic IP address
renumbering procedures [37] is that an application which looks up a renumbering procedures [37] is that an application which looks up a
DNS name disregards information such as TTL, and uses the result 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 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 the application. For applications which run for a long time, this
could be days, weeks or even months; some applications may be clever could be days, weeks or even months; some applications may be clever
enough to organize the data structures and functions in such a manner enough to organize the data structures and functions in such a manner
skipping to change at page 19, line 45 skipping to change at page 21, line 8
longer than expected. longer than expected.
9. Acknowledgements 9. Acknowledgements
Some recommendations (Section 4.3, Section 5.1) about IPv6 service Some recommendations (Section 4.3, Section 5.1) about IPv6 service
provisioning were moved here from [41] by Erik Nordmark and Bob provisioning were moved here from [41] by Erik Nordmark and Bob
Gilligan. Havard Eidnes and Michael Patton provided useful feedback Gilligan. Havard Eidnes and Michael Patton provided useful feedback
and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark and improvements. Scott Rose, Rob Austein, Masataka Ohta, and Mark
Andrews helped in clarifying the issues regarding additional data and Andrews helped in clarifying the issues regarding additional data and
the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei the use of TTL. Jefsey Morfin, Ralph Droms, Peter Koch, Jinmei
Tatuya, and Iljitsch van Beijnum provided useful feedback during the Tatuya, Iljitsch van Beijnum, and Edward Lewis provided useful
WG last call. feedback during the WG last call.
10. Security Considerations 10. Security Considerations
This document reviews the operational procedures for IPv6 DNS This document reviews the operational procedures for IPv6 DNS
operations and does not have security considerations in itself. operations and does not have security considerations in itself.
However, it is worth noting that in particular with Dynamic DNS However, it is worth noting that in particular with Dynamic DNS
Updates, security models based on the source address validation are Updates, security models based on the source address validation are
very weak and cannot be recommended. On the other hand, it should be very weak and cannot be recommended. On the other hand, it should be
noted that setting up an authorization mechanism (e.g., a shared noted that setting up an authorization mechanism (e.g., a shared
skipping to change at page 21, line 51 skipping to change at page 23, line 16
RFC 2181, July 1997. RFC 2181, July 1997.
[20] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks", [20] Wiljakka, J., "Analysis on IPv6 Transition in 3GPP Networks",
draft-ietf-v6ops-3gpp-analysis-09 (work in progress), March draft-ietf-v6ops-3gpp-analysis-09 (work in progress), March
2004. 2004.
[21] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and [21] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection and
Operation of Secondary DNS Servers", BCP 16, RFC 2182, July Operation of Secondary DNS Servers", BCP 16, RFC 2182, July
1997. 1997.
[22] Roy, S., "Dual Stack IPv6 on by Default", [22] Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack IPv6
draft-ietf-v6ops-v6onbydefault-01 (work in progress), February on by Default", draft-ietf-v6ops-v6onbydefault-02 (work in
2004. progress), May 2004.
[23] Roy, S., "IPv6 Neighbor Discovery On-Link Assumption Considered [23] Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
Harmful", draft-ietf-v6ops-onlinkassumption-01 (work in On-Link Assumption Considered Harmful",
progress), March 2004. draft-ietf-v6ops-onlinkassumption-02 (work in progress), May
2004.
[24] Shin, M., "Application Aspects of IPv6 Transition", [24] Shin, M., "Application Aspects of IPv6 Transition",
draft-ietf-v6ops-application-transition-02 (work in progress), draft-ietf-v6ops-application-transition-02 (work in progress),
March 2004. March 2004.
[25] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. [25] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[26] Ohta, M., "Preconfigured DNS Server Addresses", [26] Ohta, M., "Preconfigured DNS Server Addresses",
skipping to change at page 25, line 13 skipping to change at page 27, line 13
case. case.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can on the procedures with respect to rights in RFC documents can be
be found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/