draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt   rfc3364.txt 
Network Working Group R. Austein Network Working Group R. Austein
draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt Bourgeois Dilettant Request for Comments: 3364 Bourgeois Dilettant
June 2002 Updates: 2673, 2874 August 2002
Category: Informational
Tradeoffs in DNS support for IPv6
Status of this document
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Tradeoffs in Domain Name System (DNS) Support
Task Force (IETF), its areas, and its working groups. Note that for Internet Protocol version 6 (IPv6)
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of this Memo
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 This memo provides information for the Internet community. It does
<http://www.ietf.org/ietf/1id-abstracts.txt> not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
The list of Internet-Draft Shadow Directories can be accessed at Copyright Notice
<http://www.ietf.org/shadow.html>
Distribution of this document is unlimited. Please send comments to Copyright (C) The Internet Society (2002). All Rights Reserved.
the Namedroppers mailing list <namedroppers@ops.ietf.org>.
Abstract Abstract
The IETF has two different proposals on the table for how to do DNS The IETF has two different proposals on the table for how to do DNS
support for IPv6, and has thus far failed to reach a clear consensus support for IPv6, and has thus far failed to reach a clear consensus
on which approach is better. This note attempts to examine the pros on which approach is better. This note attempts to examine the pros
and cons of each approach, in the hope of clarifying the debate so and cons of each approach, in the hope of clarifying the debate so
that we can reach closure and move on. that we can reach closure and move on.
Introduction Introduction
RFC 1886 [RFC1886] specified straightforward mechanisms to support RFC 1886 [RFC1886] specified straightforward mechanisms to support
IPv6 addresses in the DNS. These mechanisms closely resemble the IPv6 addresses in the DNS. These mechanisms closely resemble the
mechanisms used to support IPv4, and with a minor improvement to the mechanisms used to support IPv4, with a minor improvement to the
reverse mapping mechanism based on experience with CIDR. RFC 1886 is reverse mapping mechanism based on experience with CIDR. RFC 1886 is
currently listed as a Proposed Standard. currently listed as a Proposed Standard.
RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6 RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
addresses in the DNS. These mechanisms provide new features that addresses in the DNS. These mechanisms provide new features that
make it possible for an IPv6 address stored in the DNS to be broken make it possible for an IPv6 address stored in the DNS to be broken
up into multiple DNS resource records in ways that can reflect the up into multiple DNS resource records in ways that can reflect the
network topology underlying the address, thus making it possible for network topology underlying the address, thus making it possible for
the data stored in the DNS to reflect certain kinds of network the data stored in the DNS to reflect certain kinds of network
topology changes or routing architectures that are either impossible topology changes or routing architectures that are either impossible
skipping to change at page 2, line 31 skipping to change at page 2, line 21
more general than the mechanisms proposed in [RFC1886], and that more general than the mechanisms proposed in [RFC1886], and that
these enhanced mechanisms might be valuable if IPv6's evolution goes these enhanced mechanisms might be valuable if IPv6's evolution goes
in certain directions. The questions are whether we really need the in certain directions. The questions are whether we really need the
more general mechanism, what new usage problems might come along with more general mechanism, what new usage problems might come along with
the enhanced mechanisms, and what effect all this will have on IPv6 the enhanced mechanisms, and what effect all this will have on IPv6
deployment. deployment.
The one thing on which there does seem to be widespread agreement is The one thing on which there does seem to be widespread agreement is
that we should make up our minds about all this Real Soon Now. that we should make up our minds about all this Real Soon Now.
Main advantages of going with A6 Main Advantages of Going with A6
While the A6 RR proposed in [RFC2874] is very general and provides a While the A6 RR proposed in [RFC2874] is very general and provides a
superset of the functionality provided by the AAAA RR in [RFC1886], superset of the functionality provided by the AAAA RR in [RFC1886],
many of the features of A6 can also be implemented with AAAA RRs via many of the features of A6 can also be implemented with AAAA RRs via
preprocessing during zone file generation. preprocessing during zone file generation.
There is one specific area where A6 RRs provide something that cannot There is one specific area where A6 RRs provide something that cannot
be provided using AAAA RRs: A6 RRs can represent addresses in which a be provided using AAAA RRs: A6 RRs can represent addresses in which a
prefix portion of the address can change without any action (or prefix portion of the address can change without any action (or
perhaps even knowledge) by the parties controlling the DNS zone perhaps even knowledge) by the parties controlling the DNS zone
skipping to change at page 3, line 16 skipping to change at page 3, line 5
generation requires exactly the sort of information that A6 RRs store generation requires exactly the sort of information that A6 RRs store
in the DNS. This begs the question of where the hypothetical in the DNS. This begs the question of where the hypothetical
preprocessor obtains that information if it's not getting it from the preprocessor obtains that information if it's not getting it from the
DNS. DNS.
Note also that the A6 RR, when restricted to its zero-length-prefix Note also that the A6 RR, when restricted to its zero-length-prefix
form ("A6 0"), is semantically equivalent to an AAAA RR (with one form ("A6 0"), is semantically equivalent to an AAAA RR (with one
"wasted" octet in the wire representation), so anything that can be "wasted" octet in the wire representation), so anything that can be
done with an AAAA RR can also be done with an A6 RR. done with an AAAA RR can also be done with an A6 RR.
Main advantages of going with AAAA Main Advantages of Going with AAAA
The AAAA RR proposed in [RFC1886], while providing only a subset of The AAAA RR proposed in [RFC1886], while providing only a subset of
the functionality provided by the A6 RR proposed in [RFC2874], has the functionality provided by the A6 RR proposed in [RFC2874], has
two main points to recommend it: two main points to recommend it:
- AAAA RRs are essentially identical (other than their length) to - AAAA RRs are essentially identical (other than their length) to
IPv4's A RRs, so we have more than 15 years of experience to help IPv4's A RRs, so we have more than 15 years of experience to help
us predict the usage patterns, failure scenarios and so forth us predict the usage patterns, failure scenarios and so forth
associated with AAAA RRs. associated with AAAA RRs.
- The AAAA RR is "optimized for read", in the sense that, by storing - The AAAA RR is "optimized for read", in the sense that, by storing
a complete address rather than making the resolver fetch the a complete address rather than making the resolver fetch the
address in pieces, it minimizes the effort involved in fetching address in pieces, it minimizes the effort involved in fetching
addresses from the DNS (at the expense of increasing the effort addresses from the DNS (at the expense of increasing the effort
involved in injecting new data into the DNS). involved in injecting new data into the DNS).
Less compelling arguments in favor of A6 Less Compelling Arguments in Favor of A6
Since the A6 RR allows a zone administrator to write zone files whose Since the A6 RR allows a zone administrator to write zone files whose
description of addresses maps to the underlying network topology, A6 description of addresses maps to the underlying network topology, A6
RRs can be construed as a "better" way of representing addresses than RRs can be construed as a "better" way of representing addresses than
AAAA. This may well be a useful capability, but in and of itself AAAA. This may well be a useful capability, but in and of itself
it's more of an argument for better tools for zone administrators to it's more of an argument for better tools for zone administrators to
use when constructing zone files than a justification for changing use when constructing zone files than a justification for changing
the resolution protocol used on the wire. the resolution protocol used on the wire.
Less compelling arguments in favor of AAAA Less Compelling Arguments in Favor of AAAA
Some of the pressure to go with AAAA instead of A6 appears to be Some of the pressure to go with AAAA instead of A6 appears to be
based on the wider deployment of AAAA. Since it is possible to based on the wider deployment of AAAA. Since it is possible to
construct transition tools (see discussion of AAAA synthesis, later construct transition tools (see discussion of AAAA synthesis, later
in this note), this does not appear to be a compelling argument if A6 in this note), this does not appear to be a compelling argument if A6
provides features that we really need. provides features that we really need.
Another argument in favor of AAAA RRs over A6 RRs appears to be that Another argument in favor of AAAA RRs over A6 RRs appears to be that
the A6 RR's advanced capabilities increase the number of ways in the A6 RR's advanced capabilities increase the number of ways in
which a zone administrator could build a non-working configuration. which a zone administrator could build a non-working configuration.
While operational issues are certainly important, this is more of While operational issues are certainly important, this is more of
argument that we need better tools for zone administrators than it is argument that we need better tools for zone administrators than it is
a justification for turning away from A6 if A6 provides features that a justification for turning away from A6 if A6 provides features that
we really need. we really need.
Potential problems with A6 Potential Problems with A6
The enhanced capabilities of the A6 RR, while interesting, are not in The enhanced capabilities of the A6 RR, while interesting, are not in
themselves justification for choosing A6 if we don't really need themselves justification for choosing A6 if we don't really need
those capabilities. The A6 RR is "optimized for write", in the sense those capabilities. The A6 RR is "optimized for write", in the sense
that, by making it possible to store fragmented IPv6 addresses in the that, by making it possible to store fragmented IPv6 addresses in the
DNS, it makes it possible to reduce the effort that it takes to DNS, it makes it possible to reduce the effort that it takes to
inject new data into the DNS (at the expense of increasing the effort inject new data into the DNS (at the expense of increasing the effort
involved in fetching data from the DNS). This may be justified if we involved in fetching data from the DNS). This may be justified if we
expect the effort involved in maintaining AAAA-style DNS entries to expect the effort involved in maintaining AAAA-style DNS entries to
be prohibitive, but in general, we expect the DNS data to be read be prohibitive, but in general, we expect the DNS data to be read
skipping to change at page 4, line 34 skipping to change at page 4, line 28
There are also several potential issues with A6 RRs that stem There are also several potential issues with A6 RRs that stem
directly from the feature that makes them different from AAAA RRs: directly from the feature that makes them different from AAAA RRs:
the ability to build up address via chaining. the ability to build up address via chaining.
Resolving a chain of A6 RRs involves resolving a series of what are Resolving a chain of A6 RRs involves resolving a series of what are
almost independent queries, but not quite. Each of these sub-queries almost independent queries, but not quite. Each of these sub-queries
takes some non-zero amount of time, unless the answer happens to be takes some non-zero amount of time, unless the answer happens to be
in the resolver's local cache already. Assuming that resolving an in the resolver's local cache already. Assuming that resolving an
AAAA RR takes time T as a baseline, we can guess that, on the AAAA RR takes time T as a baseline, we can guess that, on the
average, it will take something approaching time N*T to resolve an N- average, it will take something approaching time N*T to resolve an
link chain of A6 RRs, although we would expect to see a fairly good N-link chain of A6 RRs, although we would expect to see a fairly good
caching factor for the A6 fragments representing the more significant caching factor for the A6 fragments representing the more significant
bits of an address. This leaves us with two choices, neither of bits of an address. This leaves us with two choices, neither of
which is very good: we can decrease the amount of time that the which is very good: we can decrease the amount of time that the
resolver is willing to wait for each fragment, or we can increase the resolver is willing to wait for each fragment, or we can increase the
amount of time that a resolver is willing to wait before returning amount of time that a resolver is willing to wait before returning
failure to a client. What little data we have on this subject failure to a client. What little data we have on this subject
suggests that users are already impatient with the length of time it suggests that users are already impatient with the length of time it
takes to resolve A RRs in the IPv4 Internet, which suggests that they takes to resolve A RRs in the IPv4 Internet, which suggests that they
are not likely to be patient with significantly longer delays in the are not likely to be patient with significantly longer delays in the
IPv6 Internet. At the same time, terminating queries prematurely is IPv6 Internet. At the same time, terminating queries prematurely is
both a waste of resources and another source of user frustration. both a waste of resources and another source of user frustration.
Thus, we are forced to conclude that indiscriminate use of long A6 Thus, we are forced to conclude that indiscriminate use of long A6
chains is likely to lead to problems. chains is likely to lead to problems.
skipping to change at page 6, line 48 skipping to change at page 6, line 41
assuming one A RR, one AAAA RR, and one NXT RR per host, this assuming one A RR, one AAAA RR, and one NXT RR per host, this
suggests that it would take this laptop a few hours to sign a zone suggests that it would take this laptop a few hours to sign a zone
listing 10**5 hosts, or about a day to sign a zone listing 10**6 listing 10**5 hosts, or about a day to sign a zone listing 10**6
hosts using AAAA RRs. hosts using AAAA RRs.
This suggests that the additional effort of re-signing a large zone This suggests that the additional effort of re-signing a large zone
full of AAAA RRs during a re-numbering event, while noticeable, is full of AAAA RRs during a re-numbering event, while noticeable, is
only likely to be prohibitive in the rapid renumbering case where only likely to be prohibitive in the rapid renumbering case where
AAAA RRs don't work well anyway. AAAA RRs don't work well anyway.
Interactions with dynamic update Interactions with Dynamic Update
DNS dynamic update appears to work equally well for AAAA or A6 RRs, DNS dynamic update appears to work equally well for AAAA or A6 RRs,
with one minor exception: with A6 RRs, the dynamic update client with one minor exception: with A6 RRs, the dynamic update client
needs to know the prefix length and prefix name. At present, no needs to know the prefix length and prefix name. At present, no
mechanism exists to inform a dynamic update client of these values, mechanism exists to inform a dynamic update client of these values,
but presumably such a mechanism could be provided via an extension to but presumably such a mechanism could be provided via an extension to
DHCP, or some other equivalent could be devised. DHCP, or some other equivalent could be devised.
Transition from AAAA to A6 via AAAA synthesis Transition from AAAA to A6 Via AAAA Synthesis
While AAAA is at present more widely deployed than A6, it is possible While AAAA is at present more widely deployed than A6, it is possible
to transition from AAAA-aware DNS software to A6-aware DNS software. to transition from AAAA-aware DNS software to A6-aware DNS software.
A rough plan for this was presented at IETF-50 in Minneapolis and has A rough plan for this was presented at IETF-50 in Minneapolis and has
been discussed on the ipng mailing list. So if the IETF concludes been discussed on the ipng mailing list. So if the IETF concludes
that A6's enhanced capabilities are necessary, it should be possible that A6's enhanced capabilities are necessary, it should be possible
to transition from AAAA to A6. to transition from AAAA to A6.
The details of this transition have been left to a separate document, The details of this transition have been left to a separate document,
but the general idea is that the resolver that is performing but the general idea is that the resolver that is performing
iterative resolution on behalf of a DNS client program could iterative resolution on behalf of a DNS client program could
synthesize AAAA RRs representing the result of performing the synthesize AAAA RRs representing the result of performing the
equivalent A6 queries. Note that in this case it is not possible to equivalent A6 queries. Note that in this case it is not possible to
generate an equivalent DNSSEC signature for the AAAA RR, so clients generate an equivalent DNSSEC signature for the AAAA RR, so clients
that care about performing DNSSEC validation for themselves would that care about performing DNSSEC validation for themselves would
skipping to change at page 10, line 10 skipping to change at page 10, line 16
This note is based on a number of discussions both public and private This note is based on a number of discussions both public and private
over a period of (at least) eight years, but particular thanks go to over a period of (at least) eight years, but particular thanks go to
Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush, Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
and Sue Thomson, none of whom are responsible for what the author did and Sue Thomson, none of whom are responsible for what the author did
with their ideas. with their ideas.
References References
[RFC1886] Thomson, S., and Huitema, C., "DNS Extensions to support IP [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support
version 6", RFC 1886, December 1995. IP version 6", RFC 1886, December 1995.
[RFC2874] Crawford, M., and Huitema, C., "DNS Extensions to Support [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
IPv6 Address Aggregation and Renumbering" RFC 2874, July 2000. IPv6 Address Aggregation and Renumbering", RFC 2874,
July 2000.
[Sommerfeld] Private message to the author from Bill Sommerfeld dated [Sommerfeld] Private message to the author from Bill Sommerfeld dated
21 March 2001, summarizing the result of experiments he 21 March 2001, summarizing the result of experiments he
performed on a copy of the MIT.EDU zone. performed on a copy of the MIT.EDU zone.
[GSE] "GSE" was an evolution of the so-called "8+8" proposal [GSE] "GSE" was an evolution of the so-called "8+8" proposal
discussed by the IPng working group in 1996 and 1997. The GSE discussed by the IPng working group in 1996 and 1997.
proposal itself was written up as an Internet-Draft, which has The GSE proposal itself was written up as an Internet-
long since expired. Readers interested in the details and Draft, which has long since expired. Readers interested
history of GSE should review the IPng working group's mailing in the details and history of GSE should review the IPng
list archives and minutes from that period. working group's mailing list archives and minutes from
that period.
Author's addresses: Author's Address
Rob Austein Rob Austein
sra@hactrn.net
EMail: sra@hactrn.net
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 23 change blocks. 
48 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/