WDIFF

draft-ietf-dnsop-ipv6-dns-issues-09.txt --> draft-ietf-dnsop-ipv6-dns-issues-10.txt

DNS Operations WG A. Durand
Internet-Draft SUN Microsystems, Inc.
Expires: February 7, April 24, 2005 J. Ihren
Autonomica
P. Savola
CSC/FUNET
August 9,
October 24, 2004

Operational Considerations and Issues with IPv6 DNS
draft-ietf-dnsop-ipv6-dns-issues-09.txt
draft-ietf-dnsop-ipv6-dns-issues-10.txt

Status of this Memo

This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.

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.
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 February 7, April 24, 2005.

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

Durand, et al. Expires February 7, April 24, 2005 [Page 1]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

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.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Representing IPv6 Addresses in DNS Records . . . . . . . . 4
1.2 Independence of DNS Transport and DNS Records . . . . . . 4
1.3 Avoiding IPv4/IPv6 Name Space Fragmentation . . . . . . . 5
1.4 Query Type '*' and A/AAAA Records . . . . . . . . . . . . 5
2. DNS Considerations about Special IPv6 Addresses . . . . . . . 5
2.1 Limited-scope Addresses . . . . . . . . . . . . . . . . . 6
2.2 Temporary Addresses . . . . . . . . . . . . . . . . . . . 6
2.3 6to4 Addresses . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Other Transition Mechanisms . . . . . . . . . . . . . . . 6
3. Observed DNS Implementation Misbehaviour . . . . . . . . . . . 7
3.1 Misbehaviour of DNS Servers and Load-balancers . . . . . . 7
3.2 Misbehaviour of DNS Resolvers . . . . . . . . . . . . . . 7
4. Recommendations for Service Provisioning using DNS . . . . . . 8
4.1 Use of Service Names instead of Node Names . . . . . . . . 8
4.2 Separate vs the Same Service Names for IPv4 and IPv6 . . . 8
4.3 Adding the Records Only when Fully IPv6-enabled . . . . . 9
4.4 Behaviour of Additional Data in IPv4/IPv6 Environments . . 10
4.4.1 Description of Additional Data Scenarios . . . . . . . 10
4.4.2 Which Additional Data to Keep, If Any? . . . . . . . . 11
4.4.3 Discussion of the Problems . . . . . . . . . . . . . . 11 12
4.5 The Use of TTL for IPv4 and IPv6 RRs . . . . . . . . . . . 12 13
4.6 IPv6 Transport Guidelines for DNS Servers . . . . . . . . 13 14
5. Recommendations for DNS Resolver IPv6 Support . . . . . . . . 13 15
5.1 DNS Lookups May Query IPv6 Records Prematurely . . . . . . 14 15
5.2 Obtaining a List of DNS Recursive Resolvers . . . . . . . 15 16
5.3 IPv6 Transport Guidelines for Resolvers . . . . . . . . . 16 17
6. Considerations about Forward DNS Updating . . . . . . . . . . 16 17
6.1 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 16 17
6.2 Dynamic DNS . . . . . . . . . . . . . . . . . . . . . . . 17 18
7. Considerations about Reverse DNS Updating . . . . . . . . . . 18 19
7.1 Applicability of Reverse DNS . . . . . . . . . . . . . . . 18 19
7.2 Manual or Custom DNS Updates . . . . . . . . . . . . . . . 19 20
7.3 DDNS with Stateless Address Autoconfiguration . . . . . . 19 20
7.4 DDNS with DHCP . . . . . . . . . . . . . . . . . . . . . . 20 21
7.5 DDNS with Dynamic Prefix Delegation . . . . . . . . . . . 21 22
8. Miscellaneous DNS Considerations . . . . . . . . . . . . . . . 22 23
8.1 NAT-PT with DNS-ALG . . . . . . . . . . . . . . . . . . . 22 23
8.2 Renumbering Procedures and Applications' Use of DNS . . . 22 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 23

Durand, et al. Expires April 24, 2005 [Page 2]
Internet-Draft Considerations and Issues with IPv6 DNS October 2004

10. Security Considerations . . . . . . . . . . . . . . . . . . 22

Durand, et al. Expires February 7, 2005 [Page 2]
Internet-Draft Considerations and Issues with IPv6 DNS August 2004 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 24
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 23 24
11.2 Informative References . . . . . . . . . . . . . . . . . . . 25 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 28
A. Site-local Addressing Considerations for DNS . . . . . . . . . 28
B. Issues about Additional Data or TTL . . . . . . . . . . . . . 28 29
Intellectual Property and Copyright Statements . . . . . . . . 30

Durand, et al. Expires February 7, April 24, 2005 [Page 3]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

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 with IPv4 DNS.

The purpose of this document is to give information about various
issues and considerations related to DNS operations with IPv6; it is
not meant to be a normative specification or standard for IPv6 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 misbehaviours 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 seventh
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
[RFC3596] for more about IPv6 DNS usage, and [RFC3363] or [RFC3152]
for background information.

In particular one should note that the use of A6 records in the
forward tree or Bitlabels in the reverse tree is not recommended
[RFC3363]. Using DNAME records is not recommended in the reverse
tree in conjunction with A6 records; the document did not mean to
take a stance on any other use of DNAME records [RFC3364].

1.2 Independence of DNS Transport and DNS Records

DNS has been designed to present a single, globally unique name space
[RFC2826]. This property should be maintained, as described here and

Durand, et al. Expires February 7, April 24, 2005 [Page 4]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

in Section 1.3.

The IP version used to transport the DNS 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 based on the underlying transport used in a query.

However, there is some debate whether the addresses in Additional
section could be selected or filtered using hints obtained from which
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
at all).

As stated in [RFC3596]:

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
[I-D.ietf-dnsop-ipv6-transport-guidelines] [RFC3901] for more information.

1.4 Query Type '*' and A/AAAA Records

QTYPE=* is typically only used for debugging or management purposes;
it is worth keeping in mind that QTYPE=* ("ANY" queries) only return
any available RRsets, not *all* the RRsets, because the caches do not
necessarily have all the RRsets and have no way of guaranteeing that
they have all the RRsets. Therefore, to get both A and AAAA records
reliably, two separate queries must be made.

2. DNS Considerations about Special IPv6 Addresses

There are a couple of IPv6 address types which are somewhat special;
these are considered here.

Durand, et al. Expires February 7, April 24, 2005 [Page 5]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

2.1 Limited-scope Addresses

The IPv6 addressing architecture [RFC3513] includes two kinds of
local-use addresses: link-local (fe80::/10) and site-local (fec0::/
10).
(fec0::/10). The site-local addresses have been deprecated
[I-D.ietf-ipv6-deprecate-site-local],
[RFC3879], and are only discussed in Appendix A.

Link-local addresses should never be published in DNS (whether in
forward or reverse tree), because they have only local (to the
connected link) significance
[I-D.ietf-dnsop-dontpublish-unreachable].

2.2 Temporary Addresses

Temporary addresses defined in RFC3041 [RFC3041] (sometimes called
"privacy addresses") use a random number as the interface identifier.
Publishing (useful)
Having DNS AAAA records relating that are updated to such addresses always contain the
current value of a node's temporary address would defeat the purpose
of the mechanism and is not recommended. However, it would still be
possible to return a non-identifiable name (e.g., the IPv6 address in
hexadecimal format), as described in [RFC3041].

2.3 6to4 Addresses

6to4 [RFC3056] specifies an automatic tunneling mechanism which maps
a public IPv4 address V4ADDR to an IPv6 prefix 2002:V4ADDR::/48.

If the reverse DNS population would be desirable (see Section 7.1 for
applicability), there are a number of possible ways to do so
[I-D.moore-6to4-dns], some more applicable than the others.

The main proposal [I-D.huston-6to4-reverse-dns] aims to design an
autonomous reverse-delegation system that anyone being capable of
communicating using a specific 6to4 address would be able to set up a
reverse delegation to the corresponding 6to4 prefix. This could be
deployed by e.g., Regional Internet Registries (RIRs). This is a
practical solution, but may have some scalability concerns.

2.4 Other Transition Mechanisms

6to4, above, is mentioned as a case of an IPv6 transition mechanism
requiring special considerations. In general, mechanisms which
include a special prefix may need a custom solution; otherwise, for
example when IPv4 address is embedded as the suffix or not embedded
at all, special solutions are likely not needed. This is why only
6to4 and Teredo [I-D.huitema-v6ops-teredo] are described.

Note that it does not seem feasible to provide reverse DNS with

Durand, et al. Expires February 7, April 24, 2005 [Page 6]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

another automatic tunneling mechanism, Teredo; this is because the
IPv6 address is based on the IPv4 address and UDP port of the current
NAT mapping which is likely to be relatively short-lived.

3. Observed DNS Implementation Misbehaviour

Several classes of misbehaviour in DNS servers, load-balancers and
resolvers have 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
[I-D.ietf-dnsop-misbehavior-against-aaaa]: 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 to (instead of properly
returning a negative answer), significant timeouts will occur.

In consequence, this is an enormous problem for IPv6 deployments, and
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 is included in Section 5.

3.2 Misbehaviour of DNS Resolvers

Several classes of misbehaviour have also been noticed in DNS
resolvers [I-D.ietf-dnsop-bad-dns-res]. However, these do not seem
to directly impair IPv6 use, and are only referred to for
completeness.

Durand, et al. Expires February 7, April 24, 2005 [Page 7]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

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 provides multiple services which should not be
fate-sharing, or might support different IP versions, one should

It makes sense to keep
them logically separate services by a node separate
in the DNS. DNS, due to a number of reasons, for example:

o It allows more flexibility and ease for migration of (only a part
of) services from one node to another,

o It allows configuring different properties (e.g., TTL) for each
service, and

o It allows deciding separately for each service whether to publish
the IPv6 addresses or not (in cases if some services are more
IPv6-ready than others).

Using SRV records [RFC2782] would avoid these problems.
Unfortunately, those are not sufficiently widely used to be
applicable in most cases. Hence an operation technique is to use
service names instead of node names (or, "hostnames"). This
operational technique is not specific to IPv6, but required to
understand the considerations described in Section 4.2 and Section
4.3.

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 could 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 SMTP 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. (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
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, improving flexibility.

4.2 Separate vs the Same Service Names for

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 under a different name, e.g., in a sub-domain, like,
"service.ipv6.example.com".

These two methods have different characteristics. Using a different

Durand, et al. Expires February 7, April 24, 2005 [Page 8]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

"service.ipv6.example.com".

These two methods have different characteristics. Using a different
name allows for easier service piloting, minimizing the disturbance
to the "regular" users of IPv4 service; however, the service would
not be used transparently, without the user/application explicitly
finding it and asking for it -- which would be a disadvantage in most
cases. When the different name is under a sub-domain, if the
services are deployed within a restricted network (e.g., inside an
enterprise), it's possible to prefer them transparently, at least to
a degree, by modifying the DNS search path; however, this is a
suboptimal solution. 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 Section
4.3 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 resource 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 have been unsuccessful, is even attempted.

The issues are not always so black-and-white. Usually it's important

Durand, et al. Expires April 24, 2005 [Page 9]
Internet-Draft Considerations and Issues with IPv6 DNS October 2004

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.) --

Durand, et al. Expires February 7, 2005 [Page 9]
Internet-Draft Considerations and Issues with IPv6 DNS August 2004
this is typically very important especially for interactive or
real-time services. In many cases, the quality of IPv6 connectivity
may not yet be equal to that of IPv4, at least globally -- this has
to be taken into consideration when enabling services
[I-D.savola-v6ops-6bone-mess].

4.4 Behaviour of Additional Data in IPv4/IPv6 Environments

4.4.1 Description of Additional Data Scenarios

Consider the case where the query name is so long, the number of the
additional records is so high, or for other reasons that the entire
response would

DNS responses do not always fit in a single UDP packet. In some cases, the
responder truncates the response with We'll
examine the TC bit being set (leading cases which happen when this is due to a retry with TCP), too much data in order for the querier to get
the entire
response later. Additional Section.

4.4.1 Description of Additional Data Scenarios

There are two kinds of additional data:

1. glue, i.e., "critical" additional data; this must be included in all
scenarios, with all the RRsets as possible, RRsets, and

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
well, but at the cost of additional queries. This data must
never cause setting of the TC bit.

The responding server can algorithmically determine which type the
additional data is by checking whether it's at or below a zone cut.

Meanwhile,

Only those additional data records (even if sometimes carelessly
termed "glue") are considered "critical" or real "glue" if and only
if they meet the abovementioned condition, as specified in Section
4.2.1 of [RFC1034].

Remember that 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 9, all 4 A records, all 5 AAAA records or nothing. In
particular, notice that for the "critical" additional data getting
all the RRsets can be critical.

An example of the "courtesy" additional data is A/AAAA records in
conjunction of MX records as shown in

In particular, [RFC2181] specifies (in Section 4.5; an example of 9) that:

a. if all the "critical" RRsets do not fit, the sender should set
the TC bit, and the recipient should discard the whole response
and retry using mechanism allowing larger responses such as TCP.

b. "courtesy" additional data should not cause the setting of TC
bit, but instead all the non-fitting additional data RRsets

Durand, et al. Expires April 24, 2005 [Page 10]
Internet-Draft Considerations and Issues with IPv6 DNS October 2004

should be removed.

An example of the "courtesy" additional data is A/AAAA records in
conjunction of MX records is shown in Section 4.5; an example of the
"critical" additional data is shown below (where getting both the A
and AAAA RRsets is critical):

child.example.com. IN NS ns.child.example.com.
ns.child.example.com. IN A 192.0.2.1
ns.child.example.com. IN AAAA 2001:db8::1

When there is too much courtesy additional data, some or all of it
need to at least the
non-fitting RRsets should be removed [RFC2181]; if some is left in the response, however, as the
issue is which
additional data should is not critical, even all of it could be retained. safely
removed.

When there is too much

Durand, et al. Expires February 7, 2005 [Page 10]
Internet-Draft Considerations and Issues with IPv6 DNS August 2004 critical additional data, TC bit will have to
be set, and the recipient should ignore the response and retry using
TCP; if some or all
of it need data were to be removed; if some is left in the UDP response, the issue is
which data should could be retained.

Failing to discard the response with TC bit set leads to a protocol
problem. Omitting only some of the RRsets if all would not fit leads
to a performance problem. These are discussed in Section 4.4.3.

4.4.2 Which Additional Data to Keep, If Any?

If the implementation decides to keep as much data (whether
"critical" or "courtesy") as possible, possible in the UDP responses, it might
be tempting to use the transport of the DNS query as a hint in either
of these cases: return the AAAA records if the query was done over
IPv6, or return the A records if the query was done over IPv4.
However, this breaks the model of independence of DNS transport and
resource records, as noted in Section 1.2.

It is worth remembering

With courtesy additional data, as long as enough RRsets will be
removed so that often the host using the records TC will not be set, it is
different from allowed to send as many
complete RRsets as the node requesting them from implementations prefers. However, the authoritative DNS
server (or even a caching resolver). So, whichever version the
requestor (e.g., a recursive server in the middle) uses makes no
difference to the ultimate user of the records, whose transport
capabilities might differ from those of the requestor. This might
result in e.g., inappropriately returning A records
implementations are also free to an IPv6-only
node, going through a translation, or opening up another IP-level
session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
Therefore, at least in many scenarios, it would be very useful omit all such RRsets, even if
complete. Removing all the
information returned would be consistent and complete -- or RRsets if that
is some would not feasible, return no misleading information but rather leave it
to fit obviates a
performance problem, which would require the client users to query again.

4.4.2 Discussion of the Problems

As noted above, the temptation for omitting only some of the
additional data based on the transport of the query could be
problematic. In particular, there appears issue second
queries to be little justification
for doing so in the case of "courtesy" data.

However, with obtain consistent information.

With critical additional data, the alternatives are either returning
nothing (and absolutely requiring a retry with TCP) or returning
something (possibly obviating (working also in the need for a case if the recipient does not discard
the response and retry with TCP). using TCP) in addition to setting the TC bit.
If the process for selecting "something" from the critical data would

Durand, et al. Expires April 24, 2005 [Page 11]
Internet-Draft Considerations and Issues with IPv6 DNS October 2004

otherwise be practically "flipping the coin" between A and AAAA
records, it could be argued that if one looked at the transport of
the query, it would have a larger possibility of being right than
just 50/50. In other words, if the returned critical additional data
would have to be selected somehow, using something more sophisticated
than a random process would seem justifiable.

The problem of too much

That is, leaving in some intelligently selected critical additional
data seems to be is a tradeoff between creating an operational
one: the zone administrator entering too many records optimization for those
resolvers which will be
returned either truncated or missing some RRsets to ignore the users. A "should discard" recommendation, and a
causing a protocol fix for this is using EDNS0 [RFC2671] to signal problem by propagating inconsistent information
about "critical" records in the capacity
for larger UDP packet sizes, pushing up caches.

Similarly, leaving in the relevant threshold.

Durand, et al. Expires February 7, 2005 [Page 11]
Internet-Draft Considerations and Issues with IPv6 DNS August 2004

Further, DNS server implementations should rather omit complete courtesy additional data completely rather than including only some RRsets
[RFC2181]. An operational fix for this is having
instead of removing all the DNS server
implementations return RRsets is a warning when the administrators create zones
which would result performance tradeoff as
described in too much additional data being returned.
Further, DNS server implementations should warn the next section.

4.4.3 Discussion of or disallow such
zone configurations which are recursive or otherwise difficult to
manage by the protocol.

Additionally, to avoid Problems

As noted above, the case where an application would not get an
address at all due to temptation for omitting only some of "courtesy" the
additional data being
omitted, the resolvers should be able to query based on the specific records transport of the desired protocol, not just rely on getting all the required
RRsets query could be
problematic. In particular, there appears to be little justification
for doing so in the additional section.

4.5 The Use case of TTL "courtesy" data.

For courtesy additional data, this causes a performance problem as
this requires that the clients issue re-query for IPv4 and IPv6 RRs

In the previous section, we discussed a danger with queries, potentially leading to omitting RRsets from the additional section;
this could happen to both
omitted RRsets. For critical and "courtesy" additional data.
This section discusses another data, this causes a
potential protocol problem if the response is not discarded and the
query not re-tried with TCP, as the latter, leading to
omitting RRsets in cached data, highlighted in nameservers might be reachable
only through the IPv4/IPv6
environment.

The behaviour of DNS caching when different TTL values are omitted RRsets.

If an implementation would look at the transport used for the query,
it is worth remembering that often the host using the records is
different RRsets of from the same name requires explicit discussion. For
example, let's consider a part of a zone:

example.com. 300 IN MX foo.example.com.
foo.example.com. 300 IN A 192.0.2.1
foo.example.com. 100 IN AAAA 2001:db8::1

When node requesting them from the authoritative DNS
server (or even a caching resolver asks for resolver). So, whichever version the MX record
requestor (e.g., a recursive server in the middle) uses makes no
difference to the ultimate user of example.com, it
gets back "foo.example.com". It may also get back either one or both the records, whose transport
capabilities might differ from those of the A and AAAA records requestor. This might
result in the additional section. So, there are
three cases about e.g., inappropriately returning A records for the MX to an IPv6-only
node, going through a translation, or opening up another IP-level
session (e.g., a PDP context [I-D.ietf-v6ops-3gpp-analysis]).
Therefore, at least in many scenarios, it would be very useful if the additional
section:

1. We get back no A
information returned would be consistent and complete -- or AAAA RRsets: this if that
is not feasible, return no misleading information but rather leave it
to the simplest case,
because then we have client to query which information is required
explicitly, guaranteeing that we get all the information we're
interested in.

2. We get back all the RRsets: this is an optimization as there is
no need to perform more queries, causing lower latency. However,
it is impossible to guarantee that in fact we would always get
back all again.

The problem of too much additional data seems to be an operational
one: the zone administrator entering too many records (the only way to ensure that is to send a
AAAA query for the name after getting the cached reply with A which will be

Durand, et al. Expires February 7, April 24, 2005 [Page 12]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

records or vice versa).

3. We only get back

returned either truncated (or missing some RRsets, depending on
implementations) to the users. A or AAAA protocol fix for this is using
EDNS0 [RFC2671] to signal the capacity for larger UDP packet sizes,
pushing up the relevant threshold. Further, DNS server
implementations should rather omit courtesy additional data
completely rather than including only some RRsets even if both existed: [RFC2181]. An
operational fix for this is
indistinguishable from having the previous case, and may have problems
at least in certain environments as described DNS server implementations
return a warning when the administrators create zones which would
result in too much additional data being returned. Further, DNS
server implementations should warn of or disallow such zone
configurations which are recursive or otherwise difficult to manage
by the previous
section.

As protocol.

Additionally, to avoid the third case was considered in the previous section, we assume
we where an application would not get back both A and AAAA an
address at all due to some of "courtesy" additional data being
omitted, the resolvers should be able to query the specific records
of foo.example.com, or the stub
resolver explicitly asks, desired protocol, not just rely on getting all the required
RRsets in two separate queries, both A the additional section.

4.5 The Use of TTL for IPv4 and AAAA
records.

After 100 seconds, IPv6 RRs

In the AAAA record is removed previous section, we discussed a danger with queries,
potentially leading to omitting RRsets from the cache(s)
because its TTL expired. It additional section;
this could be argued happen to be useful for the
caching resolvers both critical and "courtesy" additional data
(however, both of these are recommended against in [RFC2181]). This
section discusses another problem with courtesy additional data,
leading to discard omitting RRsets in cached data, highlighted in the A record
IPv4/IPv6 environment.

The behaviour of DNS caching when the shorter different TTL (in
this case, values are used for
different RRsets of the same name requires explicit discussion. For
example, let's consider a part of a zone:

example.com. 300 IN MX foo.example.com.
foo.example.com. 300 IN A 192.0.2.1
foo.example.com. 100 IN AAAA record) expires; this would avoid the
situation where there would be 2001:db8::1

When a window caching resolver asks for the MX record of example.com, it
gets back "foo.example.com". It may also get back either one or both
of 200 seconds when
incomplete information is returned from the cache. The behaviour A and AAAA records in
this scenario is unspecified.

To simplify the situation, it might help to use the same TTL additional section. So, there are
three cases about returning records for all the resource record sets referring to MX in the same name, unless there additional
section:

1. We get back no A or AAAA RRsets: this is
a particular reason for not doing so. However, there are some
scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
a different strategy is preferable.

Thus, applications that use the response should not rely on a
particular TTL configuration. For example, even if an application
gets a response that only has the A record in the example described
above, it should be still aware that there could be a AAAA record for
"foo.example.com". That is, the application should try to fetch the
missing records itself if it needs the record.

4.6 IPv6 Transport Guidelines for DNS Servers

As described in Section 1.3 and
[I-D.ietf-dnsop-ipv6-transport-guidelines], there should continue simplest case,
because then we have to
be at least one authoritative 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 preferable, but this is the
minimum recommendation; also see [RFC2182].)

5. Recommendations for DNS Resolver IPv6 Support

When IPv6 query which information is enabled on a node, there are several things to consider
to ensure required
explicitly, guaranteeing that we get all the process is as smooth as possible. information we're
interested in.

Durand, et al. Expires February 7, April 24, 2005 [Page 13]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

5.1 DNS Lookups May Query IPv6 Records Prematurely

The system library that implements

2. We get back all the getaddrinfo() function for
looking up names RRsets: this is a critical piece when considering the robustness
of enabling IPv6; an optimization as there is
no need to perform more queries, causing lower latency. However,
it may come is impossible to guarantee that in basically three flavours:

1. The system library does not know whether IPv6 has been enabled in
the kernel of fact we would always get
back all the operating system: it may start looking up AAAA records with getaddrinfo() and AF_UNSPEC hint when the system (the only way to ensure that is
upgraded to send 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.,
AAAA query for the node could be isolated from name after getting the
other IPv6 networks, only having link-local addresses). cached reply with A
records or vice versa).

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 whether We only link-local IPv6 address(es) exists, get back A or AAAA RRsets even if both existed: this is
indistinguishable from the previous case, and may have
performance problems at least one
global IPv6 address exists.

First, let us consider generic implications of unnecessary queries
for AAAA records: when looking up all in certain environments as
described in the records previous section.

As the third case was considered in the DNS, previous section, we assume
we get back both A and AAAA records are typically tried first, and then A records. These are
done of foo.example.com, or the stub
resolver explicitly asks, in serial, two separate queries, both A and AAAA
records.

After 100 seconds, the A query is not performed until a response AAAA record is
received to removed from 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 cache(s)
because its TTL expired. It could be argued to do the queries partially in parallel; be useful for
example, if the final response
caching resolvers to the AAAA query is not received in
0.5 seconds, start performing discard the A query while waiting record when the shorter TTL (in
this case, for the
result (immediate parallelism might be unoptimal, at least without
information sharing between AAAA record) expires; this would avoid the look-up threads, as that
situation where there would
probably lead to duplicate non-cached delegation chain lookups).

An additional concern be a window of 200 seconds when
incomplete information is returned from the address selection, which may, cache. Further argument
for discarding is that in some
circumstances, prefer AAAA records over A records even when the node
does not have any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
In some cases, normal operation, the implementation may attempt to connect or send a
datagram on a physical link [I-D.ietf-v6ops-onlinkassumption],
incurring TTL values are so
high that very long protocol timeouts, instead of quickly failing
back to IPv4.

Now, we can consider likely the issues specific incurred additional queries would not be
noticeable, compared to each of the three

Durand, et al. Expires February 7, 2005 [Page 14]
Internet-Draft Considerations and Issues with IPv6 DNS August 2004

possibilities:

In the first case, obtained performance optimization. The
behaviour in this scenario is unspecified.

To simplify the node performs a number of completely useless
DNS lookups as situation, it will not be able might help to use the returned AAAA records
anyway. (The only exception is where the application desires same TTL for all
the resource record sets referring to know
what's in the DNS, but same name, unless there is
a particular reason for not doing so. However, there are some
scenarios (e.g., when renumbering IPv6 but keeping IPv4 intact) where
a different strategy is preferable.

Thus, applications that use the result for communication.) One response 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 rely on a
particular TTL configuration. For example, even if the
application is programmed properly, the an application can fall
gracefully back to IPv4 [I-D.ietf-v6ops-application-transition].

The second case is similar to the first, except it happens to
gets a
smaller set of nodes when IPv6 has been enabled but connectivity response that only has
not been provided yet; similar considerations apply, with the
exception A record in the example described
above, it should be still aware that IPv6 records, when returned, will there could be actually tried
first which may typically lead to long timeouts.

The third case is a bit more complex: optimizing away AAAA record for
"foo.example.com". That is, the application should try to fetch the
missing records itself if it needs the record.

4.6 IPv6 Transport Guidelines for DNS lookups
with only link-locals is probably safe (but may Servers

As described in Section 1.3 and [RFC3901], there should continue to
be desirable with
different lookup services which getaddrinfo() may support), as at least one authoritative IPv4 DNS server for every zone, even if
the
link-locals are typically automatically generated when zone has only 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 records. (Note that either the address has been configured either from a
router advertisement, DHCPv6 [RFC3315], or manually. Each would
indicate at least some form of IPv6 connectivity, even though there
would not be guarantees of it.

These issues should be analyzed at obviously, having more depth, and the fixes found
consensus on, perhaps in a separate document.

5.2 Obtaining a List of DNS Recursive Resolvers

In scenarios where DHCPv6 is available, a host can discover a list of
DNS recursive resolvers through DHCPv6 "DNS Recursive Name Server"
option [RFC3646]. This option can be passed to a host through a
subset of DHCPv6 [RFC3736].

The IETF is considering the development of alternative mechanisms for
obtaining the list of DNS recursive name
servers when DHCPv6 is
unavailable or inappropriate. No decision about taking on this
development work has been reached as of with robust connectivity would be preferable, but this writing (Aug 2004)
[I-D.ietf-dnsop-ipv6-dns-configuration].

In scenarios where DHCPv6 is unavailable or inappropriate, mechanisms
under consideration for development include the use of well-known
minimum recommendation; also see [RFC2182].)

Durand, et al. Expires February 7, April 24, 2005 [Page 15] 14]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

addresses [I-D.ohta-preconfigured-dns] and the use of Router
Advertisements to convey the information
[I-D.jeong-dnsop-ipv6-dns-discovery].

Note that even though IPv6

5. Recommendations for DNS resolver discovery Resolver IPv6 Support

When IPv6 is enabled on a recommended
procedure, it node, there are several things to consider
to ensure that the process is not required for dual-stack nodes in dual-stack
networks as IPv6 DNS records can be queried over IPv4 as well smooth as
IPv6. Obviously, nodes which are meant to function without manual
configuration in IPv6-only networks must implement the possible.

5.1 DNS resolver
discovery function.

5.3 Lookups May Query IPv6 Transport Guidelines for Resolvers

As described in Section 1.3 and
[I-D.ietf-dnsop-ipv6-transport-guidelines], the recursive resolvers
should be IPv4-only or dual-stack to be able to reach any IPv4-only
DNS server. Note Records Prematurely

The system library 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., implements the
mapping from getaddrinfo() function for
looking up names to the correct new addresses, is not specific to
IPv6, it should be considered especially due to a critical piece when considering the advent robustness
of
Stateless Address Autoconfiguration [RFC2462].

Typically forward DNS updates are more manageable than doing them enabling IPv6; it may come in basically three flavours:

1. The system library does not know whether IPv6 has been enabled in
the reverse DNS, because the updater can often be assumed to "own" a
certain DNS name -- and we can create a form kernel of security relationship
with the DNS name operating system: it may start looking up AAAA
records with getaddrinfo() and AF_UNSPEC hint when the node which system is allowed to update it to point
upgraded to a new address.

A more complex form of DNS updates -- adding a whole new name into a
DNS zone, instead of updating an existing name -- is considered out
of scope for this memo as it could require zone-wide authentication.
Adding a new name in the forward zone is a problem system library version which is still
being explored supports IPv6.

2. The system library might start to perform IPv6 queries with IPv4, and
getaddrinfo() only when IPv6 has been enabled in the kernel.
However, this does not seem to add much new in guarantee that area.

6.1 Manual or Custom DNS Updates

The DNS mappings can also there exists any useful
IPv6 connectivity (e.g., the node could 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 February 7, 2005 [Page 16]
Internet-Draft Considerations and Issues with isolated from the
other IPv6 DNS August 2004

6.2 Dynamic DNS

Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is networks, only having link-local addresses).

3. The system library might implement a standardized
mechanism for dynamically updating toggle which would apply
some heuristics to the DNS. It works equally well
with stateless address autoconfiguration (SLAAC), DHCPv6 "IPv6-readiness" of the node before
starting to perform queries; for example, it could check whether
only link-local IPv6 address(es) exists, or manual if at least one
global IPv6 address configuration. It is important to exists.

First, let us consider how each of these
behave if IP address-based authentication, instead generic implications of stronger
mechanisms [RFC3007], was used unnecessary queries
for AAAA records: when looking up all the records in the updates.

1. manual addresses DNS, AAAA
records are static typically tried first, and can be configured

2. DHCPv6 addresses could be reasonably static or dynamic, depending
on the deployment, then A records. These are
done in serial, and could or could the A query is not be configured on performed until a response is
received to the AAAA query. Considering the misbehaviour of DNS server for
servers and load-balancers, as described in Section 3.1, the long term

3. SLAAC addresses are typically stable look-up
delay for AAAA may incur additional unnecessary latency, and
introduce a long time, but component of unreliability.

One option here could
require work to be configured and maintained.

As relying on IP addresses for Dynamic DNS is rather insecure at
best, stronger authentication should always be used; however, this
requires that to do the authorization keying will be explicitly configured
using unspecified operational methods.

Note that with DHCP it is also possible that queries partially in parallel; for
example, if the DHCP server updates final response to the DNS, AAAA query is not the host. The host might only indicate received in
0.5 seconds, start performing the DHCP
exchange which hostname it would prefer, and the DHCP server would
make the appropriate updates. Nonetheless, A query while this makes setting
up a secure channel between waiting for the updater and
result (immediate parallelism might be unoptimal, at least without
information sharing between the DNS server easier, it
does not help much with "content" security, i.e., whether look-up threads, as that would
probably lead to duplicate non-cached delegation chain lookups).

An additional concern is the
hostname was acceptable -- if address selection, which may, in some
circumstances, prefer AAAA records over A records even when the DNS server node
does not include
policies, they must be included in the DHCP server (e.g., a regular
host should not be able to state that its name is "www.example.com").
DHCP-initiated DDNS updates have been extensively described in
[I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and
[I-D.ietf-dnsext-dhcid-rr].

The nodes must somehow be configured with the information about any IPv6 connectivity [I-D.ietf-v6ops-v6onbydefault].
In some cases, the
servers where they will implementation may 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 authoritative name servers
for the hostname; the second must be configured explicitly unless one
chooses to trust the IP address-based authentication (not connect or send 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 addresses, so

Durand, et al. Expires February 7, April 24, 2005 [Page 17] 15]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

that if the node is renumbered in

datagram on a managed fashion, the amount physical link [I-D.ietf-v6ops-onlinkassumption],
incurring very long protocol timeouts, instead of
stale DNS information is kept quickly failing
back to IPv4.

Now, we can consider the minimum. That is, if the
preferred lifetime of an address expires, the TTL issues specific to each of the record needs
be modified unless it was already done before three
possibilities:

In the expiration. For
better flexibility, first case, the DNS TTL should be much shorter (e.g., a half
or node performs a third) than the lifetime number of an address; that way, the node can
start lowering the completely useless
DNS TTL if it seems like the address has lookups as it will not been
renewed/refreshed in a while. Some discussion on how an
administrator could manage the DNS TTL is included in
[I-D.ietf-v6ops-renumbering-procedure]; this could be applied able to
(smart) hosts as well.

7. Considerations about Reverse DNS Updating

Updating use the reverse DNS zone may be difficult because of returned AAAA records
anyway. (The only exception is where the split
authority over an address. However, first we have application desires to consider the
applicability of reverse DNS know
what's 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 DNS, but not use of the address (on the premises that adding a
reverse record result for an address would signal some form of
authorization). communication.) One additional, maybe slightly more useful usage is ensuring that the
reverse
should be able to disable these unnecessary queries, for both latency
and forward DNS contents match (by looking up reliability reasons. However, as IPv6 has not been enabled, the pointer
connections to
the name by the IP address from the reverse tree, IPv6 addresses fail immediately, and ensuring that a
record under if the name in
application is programmed properly, the forward tree points application can fall
gracefully back to IPv4 [I-D.ietf-v6ops-application-transition].

The second case is similar to the IP address)
and correspond first, except it happens to a configured name or domain. As a security check,
it is
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 accompanied by other mechanisms, such as lead to long timeouts.

The third case is a user/
password login; the main purpose of bit more complex: optimizing away the reverse+forward DNS check lookups
with only link-locals 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 probably safe (but may also be desirable to store IPsec keying material corresponding
to an IP address to the reverse DNS, with
different lookup services which getaddrinfo() may support), as justified and described in
[I-D.ietf-ipseckey-rr].

It the
link-locals are typically automatically generated when IPv6 is
enabled, and do not clear whether it makes sense to require or recommend that
reverse indicate any form of IPv6 connectivity. That is,
performing DNS records lookups only when a non-link-local address has been
configured on any interface could be updated. In many cases, it beneficial -- this would just make
more sense to use proper mechanisms for security (or topological
information lookup) in the first place. At minimum, be an
indication that either the applications
which use it as address has been configured either from a generic authorization (in
router advertisement, DHCPv6 [RFC3315], or manually. Each would
indicate at least some form of IPv6 connectivity, even though there
would not be guarantees of it.

These issues should be analyzed at more depth, and the sense that fixes found
consensus on, perhaps in a record separate document.

5.2 Obtaining a List of DNS Recursive Resolvers

The IETF is considering the development of alternative mechanisms for
obtaining the list of DNS recursive name servers when DHCPv6 is
unavailable or inappropriate. No decision about taking on this

Durand, et al. Expires February 7, April 24, 2005 [Page 18] 16]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

exists at all) should be modified as soon

development work has been reached as possible to avoid such
lookups completely.

The applicability of this writing (Aug 2004)
[I-D.ietf-dnsop-ipv6-dns-configuration].

In scenarios where DHCPv6 is discussed at more length in
[I-D.ietf-dnsop-inaddr-required].

7.2 Manual unavailable or Custom inappropriate, mechanisms
under consideration for development include the use of well-known
addresses [I-D.ohta-preconfigured-dns] and the use of Router
Advertisements to convey the information
[I-D.jeong-dnsop-ipv6-dns-discovery].

Note that even though IPv6 DNS Updates

Reverse resolver discovery is a recommended
procedure, it is not required for dual-stack nodes in dual-stack
networks as IPv6 DNS records can of course be updated using manual or custom methods.
These queried over IPv4 as well as
IPv6. Obviously, nodes which are not further described here, except for one special case.

One way meant to deploy reverse function without manual
configuration in IPv6-only networks must implement the DNS would be to use wildcard records, for
example, by configuring one name resolver
discovery function.

5.3 IPv6 Transport Guidelines for a subnet (/64) or a site (/48). Resolvers

As a concrete example, a site (or the site's ISP) could configure the
reverses of described in Section 1.3 and [RFC3901], the prefix 2001:db8:f00::/48 to point to one name using a
wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
site.example.com." Naturally, such a name could not recursive resolvers
should be verified from
the forward DNS, but would at least provide some form of "topological
information" IPv4-only or "weak authorization" if that is really considered dual-stack to be useful. able to reach any IPv4-only
DNS server. Note that this requirement is not actually 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 DNS as such,
as forward DNS, i.e., the whole point
mapping from names to the correct new addresses, is not specific to avoid DNS updates completely by manually
configuring a generic name.

7.3 DDNS with
IPv6, it should be considered especially due to the advent of
Stateless Address Autoconfiguration

Dynamic reverse DNS with SLAAC is simpler than [RFC2462].

Typically forward DNS updates in
some regard, while being are more difficult manageable than doing them in another, as described
below.

The address space administrator decides whether
the hosts are trusted
to update their reverse DNS, because the updater can often be assumed to "own" a
certain DNS records or not. If they are, name -- and we can create a simple
address-based authorization is typically sufficient (i.e., check that form of security relationship
with the DNS update is done from the same IP address as name and the record being
updated); stronger security can also be used [RFC3007]. If they
aren't node which is allowed to update the reverses, no update can occur. (Such
address-based update authorization operationally requires that
ingress filtering [RFC3704] has been set up at the border it to point
to a new address.

A more complex form of the site
where the DNS updates occur, and as close to the updater as possible.)

Address-based authorization is simpler with reverse -- adding a whole new name into a
DNS (as there zone, instead of updating an existing name -- is considered out
of scope for this memo as it could require zone-wide authentication.
Adding a connection between the record and new name in the address) than with forward
DNS. However, when zone is a stronger form of security problem which is used, forward DNS
updates are simpler to manage because the host can be assumed to have
an association still
being explored with the domain. Note that the user may roam to
different networks, IPv4, and IPv6 does not necessarily have any association
with the owner of seem to add much new in
that address space -- so, assuming stronger form of
authorization for reverse area.

6.1 Manual or Custom DNS updates than an address association is
generally unfeasible. Updates

The DNS mappings can also be maintained by hand, in a semi-automatic
fashion or by running non-standardized protocols. These are not

Durand, et al. Expires February 7, April 24, 2005 [Page 19] 17]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

Moreover, the reverse zones must be cleaned up by an unspecified
janitorial process: the node does not typically know a priori that it
will be disconnected, and cannot send a

considered at more length in this memo.

6.2 Dynamic DNS update using the correct
source address to remove

Dynamic DNS updates (DDNS) [RFC2136][RFC3007] is a record.

A problem with defining standardized
mechanism for dynamically updating the clean-up process is that it DNS. It works equally well
with stateless address autoconfiguration (SLAAC), DHCPv6 or manual
address configuration. It is difficult important to ensure that a specific consider how each of these
behave if IP address and address-based authentication, instead of stronger
mechanisms [RFC3007], was used in the corresponding record updates.

1. manual addresses are
no longer being used. Considering the huge address space, static and can be configured

2. DHCPv6 addresses could be reasonably static or dynamic, depending
on the
unlikelihood of collision within 64 bits of deployment, and could or could not be configured on the interface
identifiers, a process which would remove
DNS server for the record after no traffic
has been seen from a node in a long period of time (e.g., term

3. SLAAC addresses are typically stable for a month or
year) might long time, but could
require work to be one configured and maintained.

As relying on IP addresses for Dynamic DNS is rather insecure at
best, stronger authentication should always be used; however, this
requires that the authorization keying will be explicitly configured
using unspecified operational methods.

Note that with DHCP it is also possible approach.

To insert or update that the record, DHCP server updates
the node must discover DNS, not the DNS host. The host might only indicate in the DHCP
exchange which hostname it would prefer, and the DHCP server
to send would
make the update to somehow, similar to as discussed in Section
6.2. One way to automate appropriate updates. Nonetheless, while this is looking makes setting
up a secure channel between the updater and the DNS server
authoritative (e.g., through SOA record) for the IP address being
updated, but easier, it
does not help much with "content" security, i.e., whether the security material (unless
hostname was acceptable -- if the IP address-based
authorization is trusted) DNS server does not include
policies, they must also be established by some other
means.

One included in the DHCP server (e.g., a regular
host should note not be able to state that Cryptographically Generated Addresses
[I-D.ietf-send-cga] (CGAs) may require a slightly different kind of
treatment. CGAs are addresses where the interface identifier its name is
calculated from a public key, a modifier (used as a nonce), the
subnet prefix, "www.example.com").
DHCP-initiated DDNS updates have been extensively described in
[I-D.ietf-dhc-ddns-resolution], [I-D.ietf-dhc-fqdn-option] and other data. Depending on the usage profile, CGAs
might or might not
[I-D.ietf-dnsext-dhcid-rr].

The nodes must somehow be changed periodically due configured with the information about the
servers where they will attempt to update their addresses, sufficient
security material for authenticating themselves to e.g., privacy
reasons. As the CGA address is not predicatable, a reverse record
can only reasonably server, and
the hostname they will be inserted in updating. Unless otherwise configured, the DNS
first could be obtained by looking up the node which
generates authoritative name servers
for the address.

7.4 DDNS with DHCP

With DHCPv4, hostname; the reverse DNS name 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 already inserted to pre-configured somehow
on the node, e.g., at install time.

Durand, et al. Expires April 24, 2005 [Page 18]
Internet-Draft Considerations and Issues with IPv6 DNS that reflects to October 2004

Care should be observed when updating the name (e.g., "dhcp-67.example.com"). One
can assume similar practice may become commonplace with DHCPv6 as
well; all such mappings would be pre-configured, and would require no
updating.

If a more explicit control is required, similar considerations as
with SLAAC apply, except addresses not to use longer
TTLs for addresses than are preferred lifetimes for the fact addresses, so
that typically one must update if the node is renumbered in a reverse managed fashion, the amount of
stale DNS record instead information is kept to the minimum. That is, if the
preferred lifetime of inserting one (if an address
assignment policy that reassigns disused addresses is adopted) and
updating a expires, the TTL of the record seems like a slightly more difficult thing to
secure. However, it is yet uncertain how DHCPv6 is going to needs
be used
for address assignment.

Note that when using DHCP, either modified unless it was already done before the host or expiration. For
better flexibility, the DHCP server could

Durand, et al. Expires February 7, 2005 [Page 20]
Internet-Draft Considerations and Issues with IPv6 DNS August 2004

perform TTL should be much shorter (e.g., a half
or a third) than the DNS updates; see lifetime of an address; that way, the implications in Section 6.2.

If disused addresses were to be reassigned, host-based DDNS reverse
updates would need policy considerations for DNS record modification,
as noted above. On node can
start lowering the other hand, DNS TTL if disused it seems like the address were has not to be
assigned, host-based been
renewed/refreshed in a while. Some discussion on how an
administrator could manage the DNS reverse updates would have similar
considerations as SLAAC TTL is included in Section 7.3. Server-based updates have
similar properties except that the janitorial process
[I-D.ietf-v6ops-renumbering-procedure]; this could be
integrated with DHCP address assignment.

7.5 DDNS with Dynamic Prefix Delegation

In cases where a prefix, instead applied to
(smart) hosts as well.

7. Considerations about Reverse DNS Updating

Updating the reverse DNS zone may be difficult because of the split
authority over an address, is being used and
updated, one should address. However, first we have to consider what is the location
applicability of the server where
DDNS updates are made. That is, where the reverse DNS server is located:

1. At the same organization as the prefix delegator.

2. At the site where the prefixes are delegated to. In this case, in the authority first place.

7.1 Applicability of the Reverse DNS

Today, some applications use reverse zone corresponding to the
delegated prefix is also delegated DNS to either look up some hints
about the site.

3. Elsewhere; this implies a relationship between the site and where
DNS topological information associated with an address (e.g.
resolving web server is located, and such access logs), or as a relationship should be rather
straightforward weak form of a security
check, to secure as well. Like in get a feel whether the previous case, user's network administrator has
"authorized" the authority use of the DNS address (on the premises that adding a
reverse zone record for an address would signal some form of
authorization).

One additional, maybe slightly more useful usage is also delegated.

In the first case, managing ensuring that the
reverse and forward DNS (delegation) is simpler
as contents match (by looking up the DNS server and pointer to
the prefix delegator are in name by the same
administrative domain (as there is no need to delegate anything at
all); alternatively, IP address from the prefix delegator might forgo DDNS reverse
capability altogether, tree, and use e.g., wildcard records (as described
in Section 7.2). In ensuring that a
record under the other cases, it can be slighly more
difficult, particularly as name in the site will have forward tree points to configure the DNS
server IP address)
and correspond to be authoritative for the delegated reverse zone, implying
automatic configuration of the DNS server -- as the prefix may be
dynamic.

Managing the DDNS reverse updates a configured name or domain. As a security check,
it is typically simple in the second
case, accompanied by other mechanisms, such as a
user/password login; the updated server main purpose of the reverse+forward DNS
check is located at to weed out the local site, majority of unauthorized users, and
arguably IP address-based authentication could be sufficient (or if
not, setting up security relationships
someone managed to bypass the checks, he would still need to
authenticate "properly".

It may also be simpler). As there
is desirable to store IPsec keying material corresponding
to an explicit (security) relationship between the parties in the
third case, setting up the security relationships IP address to allow the reverse
DDNS updates should be rather straightforward DNS, as well (but IP
address-based authentication might justified and described in
[I-D.ietf-ipseckey-rr].

It is not clear whether it makes sense to require or recommend that
reverse DNS records be acceptable). updated. In the first
case, however, setting up and managing such relationships might be a
lot many cases, it would just make
more difficult. sense to use proper mechanisms for security (or topological

Durand, et al. Expires February 7, April 24, 2005 [Page 21] 19]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

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

The DNS-ALG component of NAT-PT mangles A records to look like AAAA
records to the IPv6-only nodes. Numerous problems have been
identified with DNS-ALG [I-D.durand-v6ops-natpt-dns-alg-issues].
This is a strong reason not to use NAT-PT

information lookup) in the first place.

8.2 Renumbering Procedures and Applications' Use of DNS

One of At minimum, the most difficult problems of systematic IP address
renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
an application applications
which looks up a DNS name disregards information such use it as TTL, and uses a generic authorization (in the result obtained from DNS sense that a record
exists at all) should be modified as long soon as it happens possible to be stored avoid such
lookups completely.

The applicability is discussed at more length in the memory
[I-D.ietf-dnsop-inaddr-required].

7.2 Manual or Custom DNS Updates

Reverse DNS can of the application. For applications
which run for a long time, this could course be days, weeks updated using manual or even months;
some applications may custom methods.
These are not further described here, except for one special case.

One way to deploy reverse DNS would be clever enough to organize the data
structures and functions in such use wildcard records, for
example, by configuring one name for a manner that look-ups get refreshed
now and then.

While the issue appears to have subnet (/64) or a clear solution, "fix site (/48).
As a concrete example, a site (or the
applications", practically this is site's ISP) could configure the
reverses of the prefix 2001:db8:f00::/48 to point to one name using a
wildcard record like "*.0.0.f.0.8.b.d.0.1.0.0.2.ip6.arpa. IN PTR
site.example.com." Naturally, such a name could not reasonable immediate advice; be verified from
the TTL information 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 typically available actually updating the DNS as such,
as the whole point is to avoid DNS updates completely by manually
configuring a generic name.

7.3 DDNS with Stateless Address Autoconfiguration

Dynamic reverse DNS with SLAAC is simpler than forward DNS updates in
some regard, while being more difficult in another, as described
below.

The address space administrator decides whether the APIs hosts are trusted
to update their reverse DNS records or not. If they are trusted and
libraries (so,
deployed at the advice becomes "fix same site (e.g., not across the applications, APIs and
libraries"), and Internet), a lot more analysis simple
address-based authorization is needed on how to practically
go about typically sufficient (i.e., check that
the DNS update is done from the same IP address as the record being
updated); stronger security can also be used [RFC3007]. If they
aren't allowed to achieve update the ultimate goal reverses, no update can occur. However,
such address-based update authorization operationally requires that
ingress filtering [RFC3704] has been set up at the border of avoiding using the names
longer than expected.

9. Acknowledgements

Some recommendations (Section 4.3, Section 5.1) about IPv6 service
provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
Nordmark site
where the updates occur, and Bob Gilligan. Havard Eidnes and Michael Patton provided
useful feedback and improvements. Scott Rose, Rob Austein, Masataka
Ohta, and Mark Andrews helped in clarifying as close to the issues regarding
additional data updater as possible.

Address-based authorization is simpler with reverse DNS (as there is
a connection between the record and the use address) than with forward
DNS. However, when a stronger form of TTL. Jefsey Morfin, Ralph Droms,
Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
Rob Austein provided useful feedback during security is used, forward DNS
updates are simpler to manage because the WG last call. Thomas
Narten provided extensive feedback during host can be assumed to have
an association with the IESG evaluation.

10. Security Considerations

This document reviews domain. Note that the operational procedures for IPv6 DNS user may roam to
different networks, and does not necessarily have any association

Durand, et al. Expires February 7, April 24, 2005 [Page 22] 20]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

operations and does not have security considerations in itself.

However, it is worth noting that in particular

with Dynamic DNS
Updates, security models based on the source owner of that address validation are
very weak and cannot be recommended space -- they could only be considered
in the environments where ingress filtering [RFC3704] has been
deployed. On so, assuming stronger form of
authorization for reverse DNS updates than an address association is
generally unfeasible.

Moreover, the other hand, it should reverse zones must be noted that setting cleaned up by an
authorization mechanism (e.g., a shared secret, or public-private
keys) between a unspecified
janitorial process: the node does not typically know a priori that it
will be disconnected, and the DNS server has cannot send a DNS update using the correct
source address to be done manually, remove a record.

A problem with defining the clean-up process is that it is difficult
to ensure that a specific IP address and
may require quite the corresponding record are
no longer being used. Considering the huge address space, and the
unlikelihood of collision within 64 bits of the interface
identifiers, a bit process which would remove the record after no traffic
has been seen from a node in a long period of time and expertise. (e.g., a month or
year) might be one possible approach.

To re-emphasize which was already stated, insert or update the record, the node must discover the reverse+forward DNS
check provides very weak security at best, and server
to send the only
(questionable) security-related use update to somehow, similar to as discussed in Section
6.2. One way to automate this is looking up the DNS server
authoritative (e.g., through SOA record) for them may the IP address being
updated, but the security material (unless the IP address-based
authorization is trusted) must also be in conjunction
with established by some other mechanisms when authenticating
means.

One should note that Cryptographically Generated Addresses
[I-D.ietf-send-cga] (CGAs) may require a user.

11. References

11.1 Normative References

[I-D.ietf-dnsop-ipv6-dns-configuration]
Jeong, J., "IPv6 Host Configuration slightly different kind of DNS Server
Information Approaches",
draft-ietf-dnsop-ipv6-dns-configuration-02 (work in
progress), July 2004.

[I-D.ietf-dnsop-ipv6-transport-guidelines]
Durand, A.
treatment. CGAs are addresses where the interface identifier is
calculated from a public key, a modifier (used as a nonce), the
subnet prefix, and J. Ihren, "DNS IPv6 transport operational
guidelines", draft-ietf-dnsop-ipv6-transport-guidelines-02
(work in progress), March 2004.

[I-D.ietf-dnsop-misbehavior-against-aaaa]
Morishita, Y. and T. Jinmei, "Common Misbehavior against
DNS Queries for IPv6 Addresses",
draft-ietf-dnsop-misbehavior-against-aaaa-01 (work other data. Depending on the usage profile, CGAs
might or might not be changed periodically due to e.g., privacy
reasons. As the CGA address is not predicatable, a reverse record
can only reasonably be inserted in
progress), April 2004.

[I-D.ietf-ipv6-deprecate-site-local]
Huitema, C. the DNS by the node which
generates the address.

7.4 DDNS with DHCP

With DHCPv4, the reverse DNS name is typically already inserted to
the DNS that reflects to the name (e.g., "dhcp-67.example.com"). One
can assume similar practice may become commonplace with DHCPv6 as
well; all such mappings would be pre-configured, and B. Carpenter, "Deprecating Site Local
Addresses", draft-ietf-ipv6-deprecate-site-local-03 (work
in progress), March 2004.

[I-D.ietf-v6ops-application-transition]
Shin, M., "Application Aspects would require no
updating.

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 IPv6 Transition",
draft-ietf-v6ops-application-transition-03 (work in
progress), June 2004.

[I-D.ietf-v6ops-renumbering-procedure] inserting one (if an address
assignment policy that reassigns disused addresses is adopted) and
updating a record seems like a slightly more difficult thing to

Durand, et al. Expires February 7, April 24, 2005 [Page 23] 21]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

Baker, F., Lear, E. and R. Droms, "Procedures

secure. However, it is yet uncertain how DHCPv6 is going to be used
for
Renumbering an IPv6 Network without a Flag Day",
draft-ietf-v6ops-renumbering-procedure-01 (work in
progress), July 2004.

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in address assignment.

Note that when using DHCP, either the Domain Name System (DNS UPDATE)", RFC 2136,
April host or the DHCP server could
perform the DNS updates; see the implications in Section 6.2.

If disused addresses were to be reassigned, host-based DDNS reverse
updates would need policy considerations for DNS record modification,
as noted above. On the other hand, if disused address were not to be
assigned, host-based DNS reverse updates would have similar
considerations as SLAAC in Section 7.3. Server-based updates have
similar properties except that the janitorial process could be
integrated with DHCP address assignment.

7.5 DDNS with Dynamic Prefix Delegation

In cases where a prefix, instead of an address, is being used and
updated, one should consider what is the location of the server where
DDNS updates are made. That is, where the DNS server is located:

1. At the same organization as the prefix delegator.

2. At the site where the prefixes are delegated to. In this case,
the authority of the DNS reverse zone corresponding to the
delegated prefix is also delegated to the site.

3. Elsewhere; this implies a relationship between the site and where
DNS server is located, and such a relationship should be rather
straightforward to secure as well. Like in the previous case,
the authority of the DNS reverse zone is also delegated.

In the first case, managing the reverse DNS (delegation) is simpler
as the DNS server and the prefix delegator are in the same
administrative domain (as there is no need to delegate anything at
all); alternatively, the prefix delegator might forgo DDNS reverse
capability altogether, and use e.g., wildcard records (as described
in Section 7.2). In the other cases, it can be slighly more
difficult, particularly as the site will have to configure the DNS
server to be authoritative for the delegated reverse zone, implying
automatic configuration of the DNS server -- as the prefix may be
dynamic.

Managing the DDNS reverse updates is typically simple in the second
case, as the updated server is located at the local site, and
arguably IP address-based authentication could be sufficient (or if
not, setting up security relationships would be simpler). As there
is an explicit (security) relationship between the parties in the
third case, setting up the security relationships to allow reverse

Durand, et al. Expires April 24, 2005 [Page 22]
Internet-Draft Considerations and Issues with IPv6 DNS October 2004

DDNS updates should be rather straightforward as well (but IP
address-based authentication might not be acceptable). In the first
case, however, setting up and managing such relationships might be a
lot more difficult.

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

8.2 Renumbering Procedures and Applications' Use of DNS

One of the most difficult problems of systematic IP address
renumbering procedures [I-D.ietf-v6ops-renumbering-procedure] is that
an application which looks up 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.

While the issue appears to have a clear solution, "fix the
applications", practically this is not reasonable immediate advice;
the TTL information is not typically available in the APIs and
libraries (so, the advice becomes "fix the applications, APIs and
libraries"), and a lot more analysis is needed on how to practically
go about to achieve the ultimate goal of avoiding using the names
longer than expected.

9. Acknowledgements

Some recommendations (Section 4.3, Section 5.1) about IPv6 service
provisioning were moved here from [I-D.ietf-v6ops-mech-v2] by Erik
Nordmark and Bob Gilligan. Havard Eidnes and Michael Patton provided
useful feedback and improvements. Scott Rose, Rob Austein, Masataka
Ohta, and Mark Andrews helped in clarifying the issues regarding
additional data and the use of TTL. Jefsey Morfin, Ralph Droms,
Peter Koch, Jinmei Tatuya, Iljitsch van Beijnum, Edward Lewis, and
Rob Austein provided useful feedback during the WG last call. Thomas

Durand, et al. Expires April 24, 2005 [Page 23]
Internet-Draft Considerations and Issues with IPv6 DNS October 2004

Narten provided extensive feedback during the IESG evaluation.

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 noting that in particular with Dynamic DNS
Updates, security models based on the source address validation are
very weak and cannot be recommended -- they could only be considered
in the environments where ingress filtering [RFC3704] has been
deployed. 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, the reverse+forward DNS
check provides 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.

11. References

11.1 Normative References

[I-D.ietf-dnsop-ipv6-dns-configuration]
Jeong, J., "IPv6 Host Configuration of DNS Server
Information Approaches",
draft-ietf-dnsop-ipv6-dns-configuration-04 (work in
progress), September 2004.

[I-D.ietf-v6ops-application-transition]
Shin, M., "Application Aspects of IPv6 Transition",
draft-ietf-v6ops-application-transition-03 (work in
progress), June 2004.

[I-D.ietf-v6ops-renumbering-procedure]
Baker, F., Lear, E. and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day",
draft-ietf-v6ops-renumbering-procedure-01 (work in
progress), July 2004.

Durand, et al. Expires April 24, 2005 [Page 24]
Internet-Draft Considerations and Issues with IPv6 DNS October 2004

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.

[RFC2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.

[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.

[RFC2182] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
and Operation of Secondary DNS Servers", BCP 16, RFC 2182,
July 1997.

[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.

[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.

[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.

[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.

[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.

[RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
August 2001.

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.

[RFC3363] 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.

[RFC3364] Austein, R., "Tradeoffs in Domain Name System (DNS)
Support for Internet Protocol version 6 (IPv6)", RFC 3364,
August 2002.

Durand, et al. Expires February 7, 2005 [Page 24]
Internet-Draft Considerations and Issues with IPv6 DNS August 2004

[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.

Durand, et al. Expires April 24, 2005 [Page 25]
Internet-Draft Considerations and Issues with IPv6 DNS October 2004

[RFC3596] Thomson, S., Huitema, C., Ksinant, V. and M. Souissi, "DNS
Extensions to Support IP Version 6", RFC 3596, October
2003.

[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", RFC 3646,
December 2003.

[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004.

11.2 Informative References

[I-D.durand-v6ops-natpt-dns-alg-issues]
Durand, A., "Issues with NAT-PT DNS ALG in RFC2766",
draft-durand-v6ops-natpt-dns-alg-issues-00 (work in
progress), February 2003.

[I-D.huitema-v6ops-teredo]
Huitema, C., "Teredo: Tunneling IPv6 over UDP through
NATs", draft-huitema-v6ops-teredo-02 (work in progress),
June 2004.

[I-D.huston-6to4-reverse-dns]
Huston, G., "6to4 Reverse DNS",
draft-huston-6to4-reverse-dns-02 (work in progress), April
2004.

[I-D.ietf-dhc-ddns-resolution]
Stapp, M., "Resolution of DNS Name Conflicts Among DHCP
Clients", draft-ietf-dhc-ddns-resolution-07 (work in
progress), July 2004.

[I-D.ietf-dhc-fqdn-option]
Stapp, M. and Y. Rekhter, "The DHCP Client FQDN Option",
draft-ietf-dhc-fqdn-option-07 (work in progress), July
2004.

[I-D.ietf-dnsext-dhcid-rr]
Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for
encoding DHCP information (DHCID RR)",
draft-ietf-dnsext-dhcid-rr-08 (work in progress), July
2004.

[I-D.ietf-dnsop-bad-dns-res]

Durand, et al. Expires February 7, 2005 [Page 25]
Internet-Draft Considerations and Issues with IPv6 DNS August 2004

Larson, M. and P. Barber, "Observed DNS Resolution
Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in
progress), July 2004.

[I-D.ietf-dnsop-dontpublish-unreachable]
Hazel, P., "IP Addresses that should never appear in the
public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
(work in progress), February 2002.

[I-D.ietf-dnsop-inaddr-required]
Senie, D., "Requiring DNS IN-ADDR Mapping",
draft-ietf-dnsop-inaddr-required-05 (work in progress),
April 2004.

[I-D.ietf-ipseckey-rr]
Richardson, M., "A method for storing IPsec keying
material in DNS", draft-ietf-ipseckey-rr-11 (work in
progress), July 2004.

[I-D.ietf-ipv6-unique-local-addr]
Hinden, R. 2004.

[RFC3879] Huitema, C. and B. Haberman, "Unique Carpenter, "Deprecating Site Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
progress), June 2004.

[I-D.ietf-send-cga]
Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004.

[I-D.ietf-v6ops-3gpp-analysis]
Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
progress), May 2004.

[I-D.ietf-v6ops-mech-v2]
Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-04
(work in progress), July RFC 3879, September 2004.

[I-D.ietf-v6ops-onlinkassumption]
Roy, S.,

[RFC3901] Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
On-Link Assumption Considered Harmful",
draft-ietf-v6ops-onlinkassumption-02 (work in progress),
May Ihren, "DNS IPv6 Transport Operational
Guidelines", BCP 91, RFC 3901, September 2004.

[I-D.ietf-v6ops-v6onbydefault]
Roy, S.,

11.2 Informative References

[I-D.durand-v6ops-natpt-dns-alg-issues]
Durand, A. and J. Paugh, A., "Issues with Dual Stack
IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03 NAT-PT DNS ALG in RFC2766",
draft-durand-v6ops-natpt-dns-alg-issues-00 (work in
progress), July 2004.

Durand, et al. Expires February 7, 2005 [Page 26]
Internet-Draft Considerations and Issues with 2003.

[I-D.huitema-v6ops-teredo]
Huitema, C., "Teredo: Tunneling IPv6 DNS August 2004

[I-D.jeong-dnsop-ipv6-dns-discovery]
Jeong, J., "IPv6 DNS Discovery based on Router
Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02 over UDP through
NATs", draft-huitema-v6ops-teredo-02 (work in progress), July
June 2004.

[I-D.moore-6to4-dns]
Moore, K.,

[I-D.huston-6to4-reverse-dns]
Huston, G., "6to4 and DNS", draft-moore-6to4-dns-03 Reverse DNS Delegation",
draft-huston-6to4-reverse-dns-03 (work in progress),
October 2002.

[I-D.ohta-preconfigured-dns]
Ohta, 2004.

[I-D.ietf-dhc-ddns-resolution]
Stapp, M., "Preconfigured "Resolution of DNS Server Addresses",
draft-ohta-preconfigured-dns-01 Name Conflicts Among DHCP
Clients", draft-ietf-dhc-ddns-resolution-08 (work in
progress),
February October 2004.

[I-D.savola-v6ops-6bone-mess]
Savola, P., "Moving from 6bone to IPv6 Internet",
draft-savola-v6ops-6bone-mess-01 (work in progress),
November 2002.

[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.

[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.

[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000.

[RFC3704] Baker, F.

[I-D.ietf-dhc-fqdn-option]
Stapp, M. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March Y. Rekhter, "The DHCP Client FQDN Option",
draft-ietf-dhc-fqdn-option-07 (work in progress), July
2004.

Authors' Addresses

Alain Durand
SUN Microsystems, Inc.
17 Network circle UMPL17-202
Menlo Park, CA 94025
USA

EMail: Alain.Durand@sun.com

[I-D.ietf-dnsext-dhcid-rr]
Stapp, M., Lemon, T. and A. Gustafsson, "A DNS RR for
encoding DHCP information (DHCID RR)",
draft-ietf-dnsext-dhcid-rr-08 (work in progress), July

Durand, et al. Expires February 7, April 24, 2005 [Page 27] 26]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm
Sweden

EMail: johani@autonomica.se

Pekka Savola
CSC/FUNET
Espoo
Finland

EMail: psavola@funet.fi

Appendix A. Site-local Addressing Considerations for

2004.

[I-D.ietf-dnsop-bad-dns-res]
Larson, M. and P. Barber, "Observed DNS

As site-local addressing has been deprecated, Resolution
Misbehavior", draft-ietf-dnsop-bad-dns-res-02 (work in
progress), July 2004.

[I-D.ietf-dnsop-dontpublish-unreachable]
Hazel, P., "IP Addresses that should never appear in the considerations for
site-local addressing are discussed briefly here. Unique local
addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed
as a replacement, but being work-in-progress, it is not considered
further.

The interactions with
public DNS", draft-ietf-dnsop-dontpublish-unreachable-03
(work in progress), February 2002.

[I-D.ietf-dnsop-inaddr-required]
Senie, D., "Requiring DNS come IN-ADDR Mapping",
draft-ietf-dnsop-inaddr-required-05 (work in two flavors: forward progress),
April 2004.

[I-D.ietf-ipseckey-rr]
Richardson, M., "A method for storing IPsec keying
material in DNS", draft-ietf-ipseckey-rr-11 (work in
progress), July 2004.

[I-D.ietf-ipv6-unique-local-addr]
Hinden, R. 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, B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-06 (work in
progress), September 2004.

[I-D.ietf-send-cga]
Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004.

[I-D.ietf-v6ops-3gpp-analysis]
Wiljakka, J., "Analysis on IPv6 Transition in 3GPP
Networks", draft-ietf-v6ops-3gpp-analysis-10 (work in
progress), May 2004.

[I-D.ietf-v6ops-mech-v2]
Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for the
zones internal to the site, IPv6 Hosts 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 Routers", draft-ietf-v6ops-mech-v2-06
(work in the public DNS.

To faciliate reverse DNS (if desired) progress), September 2004.

[I-D.ietf-v6ops-onlinkassumption]
Roy, S., Durand, A. and J. Paugh, "IPv6 Neighbor Discovery
On-Link Assumption Considered Harmful",
draft-ietf-v6ops-onlinkassumption-02 (work in progress),
May 2004.

[I-D.ietf-v6ops-v6onbydefault]

Durand, et al. Expires April 24, 2005 [Page 27]
Internet-Draft Considerations and Issues with site-local addresses, the
stub resolvers must look for IPv6 DNS information from the local October 2004

Roy, S., Durand, A. and J. Paugh, "Issues with Dual Stack
IPv6 on by Default", draft-ietf-v6ops-v6onbydefault-03
(work in progress), July 2004.

[I-D.jeong-dnsop-ipv6-dns-discovery]
Jeong, J., "IPv6 DNS
servers, not e.g. starting from the root servers, so that the
site-local information may be provided locally. Note that the
experience of private addresses Discovery based on Router
Advertisement", draft-jeong-dnsop-ipv6-dns-discovery-02
(work in IPv4 has shown that the root
servers get loaded for requests for private address lookups progress), July 2004.

[I-D.moore-6to4-dns]
Moore, K., "6to4 and DNS", draft-moore-6to4-dns-03 (work
in any
case.

Appendix B. Issues about Additional Data or TTL

[[ note progress), October 2002.

[I-D.ohta-preconfigured-dns]
Ohta, M., "Preconfigured DNS Server Addresses",
draft-ohta-preconfigured-dns-01 (work in progress),
February 2004.

[I-D.savola-v6ops-6bone-mess]
Savola, P., "Moving from 6bone to IPv6 Internet",
draft-savola-v6ops-6bone-mess-01 (work in progress),
November 2002.

[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address
Translation - Protocol Translation (NAT-PT)", RFC 2766,
February 2000.

[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the RFC-editor: remove this section upon publication. ]]

This appendix tries to describe location of services (DNS SRV)", RFC 2782,
February 2000.

[RFC2826] Internet Architecture Board, "IAB Technical Comment on the apparent rought consensus about
additional data and TTL issues (sections 4.4 and 4.5),
Unique DNS Root", RFC 2826, May 2000.

[RFC3704] Baker, F. and present
questions when there appears to be no consensus. The point of P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.

Authors' Addresses

Alain Durand
SUN Microsystems, Inc.
17 Network circle UMPL17-202
Menlo Park, CA 94025
USA

EMail: Alain.Durand@sun.com

Durand, et al. Expires February 7, April 24, 2005 [Page 28]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

recording them here is to focus the discussion and get feedback.

Resolved:

a. If some critical additional data RRsets wouldn't fit, you set the
TC bit even if some RRsets did fit.

b. If some courtesy additional data RRsets wouldn't fit, you never
set the TC bit, but rather remove (at least some of) the courtesy
RRsets.

Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm
Sweden

EMail: johani@autonomica.se

Pekka Savola
CSC/FUNET
Espoo
Finland

EMail: psavola@funet.fi

Appendix A. Site-local Addressing Considerations for DNS servers should implement sanity checks on the resulting glue,
e.g., to disable circular dependencies. Then the responding
servers can use at-or-below-a-zone-cut criterion to determine
whether the additional data is critical or not.

Open issues (at least):

1. if some critical additional data RRsets would fit, but some
wouldn't, and TC

As site-local addressing has to be set (see above), should one rather
remove been deprecated, the additional data that did fit, keep it, or leave
unspecified?

2. if some courtesy additional data RRsets would fit, considerations for
site-local addressing are discussed briefly here. Unique local
addressing format [I-D.ietf-ipv6-unique-local-addr] has been proposed
as a replacement, but some
wouldn't, and some will have to be removed from the response (no
TC is set, see above), what to do -- remove all courtesy RRsets,
keep all that fit, or leave unspecified?

3. is being work-in-progress, it acceptable to use the transport used is not considered
further.

The interactions with DNS come in two flavors: forward and reverse
DNS.

To actually use site-local addresses within a site, this implies the DNS query as
deployment of a
hint which records to keep if not removing all "split-faced" or a fragmented DNS name space, for the RRsets, if: a)
having to decide which critical additional data
zones internal to keep, or b)
having the site, and the outsiders' view to decide which courtesy additional data it. The
procedures to keep?

4. (this issue was discussed achieve this are not elaborated here. The implication
is that site-local addresses must not be published in section 4.5) if one RRset has TTL of
100 seconds, and another the TTL of 300 seconds, what should the
caching server do after 100 seconds? Keep returning just one
RRset when returning additional data, or discard public DNS.

To faciliate reverse DNS (if desired) with site-local addresses, the other RRset
stub resolvers must look for DNS information from the cache?

5. how do we move forward local DNS
servers, not e.g. starting from here? If we manage to get to some
form the root servers, so that the
site-local information may be provided locally. Note that the
experience of consensus, how do we record it: a) just private addresses in
draft-ietf-dnsop-ipv6-dns-issues (note IPv4 has shown that it's Informational
category only!), b) a separate BCP or similar by DNSEXT WG(?),
clarifying and giving recommendations, c) something else, what? the root
servers get loaded for requests for private address lookups in any
case.

Durand, et al. Expires February 7, April 24, 2005 [Page 29]
Internet-Draft Considerations and Issues with IPv6 DNS August October 2004

Intellectual Property Statement

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.

Disclaimer of Validity

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.

Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.

Acknowledgment

Funding for the RFC Editor function is currently provided by the
Internet Society.

Durand, et al. Expires February 7, April 24, 2005 [Page 30]
----