draft-ietf-dnsext-ipv6-dns-tradeoffs-01.txt   draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt 
Network Working Group R. Austein Network Working Group R. Austein
draft-ietf-dnsext-ipv6-dns-tradeoffs-01.txt Bourgeois Dilettant draft-ietf-dnsext-ipv6-dns-tradeoffs-02.txt Bourgeois Dilettant
May 2002 June 2002
Tradeoffs in DNS support for IPv6 Tradeoffs in DNS support for IPv6
Status of this document Status of this document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 [Tweedledee] 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, and 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 [Tweedledum] 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
or more difficult to represent without these mechanisms. RFC 2874 is or more difficult to represent without these mechanisms. RFC 2874 is
also currently listed as a Proposed Standard. also currently listed as a Proposed Standard.
Both of these Proposed Standards were the output of the IPNG Working Both of these Proposed Standards were the output of the IPNG Working
Group. Both have been implemented, although implementation of Group. Both have been implemented, although implementation of
[Tweedledee] is more widespread, both because it was specified [RFC1886] is more widespread, both because it was specified earlier
earlier and because it's simpler to implement. and because it's simpler to implement.
There's little question that the mechanisms proposed in [Tweedledum] There's little question that the mechanisms proposed in [RFC2874] are
are more general than the mechanisms proposed in [Tweedledee], and more general than the mechanisms proposed in [RFC1886], and that
that these enhanced mechanisms might be valuable if IPv6's evolution these enhanced mechanisms might be valuable if IPv6's evolution goes
goes in certain directions. The questions are whether we really need in certain directions. The questions are whether we really need the
the more general mechanism, what new usage problems might come along more general mechanism, what new usage problems might come along with
with the enhanced mechanisms, and what effect all this will have on the enhanced mechanisms, and what effect all this will have on IPv6
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 [Tweedledum] is very general and provides While the A6 RR proposed in [RFC2874] is very general and provides a
a superset of the functionality provided by the AAAA RR in superset of the functionality provided by the AAAA RR in [RFC1886],
[Tweedledee], many of the features of A6 can also be implemented with many of the features of A6 can also be implemented with AAAA RRs via
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
containing the terminal portion (least significant bits) of the containing the terminal portion (least significant bits) of the
address. This includes both so-called "rapid renumbering" scenarios address. This includes both so-called "rapid renumbering" scenarios
(where an entire network's prefix may change very quickly) and (where an entire network's prefix may change very quickly) and
routing architectures such as GSE (where the "routing goop" portion routing architectures such as the former "GSE" proposal [GSE] (where
of an address may be subject to change without warning). A6 RRs do the "routing goop" portion of an address may be subject to change
not completely remove the need to update leaf zones during all without warning). A6 RRs do not completely remove the need to update
renumbering events (for example, changing ISPs would usually require leaf zones during all renumbering events (for example, changing ISPs
a change to the upward delegation pointer), but careful use of A6 RRs would usually require a change to the upward delegation pointer), but
could keep the number of RRs that need to change during such an event careful use of A6 RRs could keep the number of RRs that need to
to a minimum. change during such an event to a minimum.
Note that constructing AAAA RRs via preprocessing during zone file Note that constructing AAAA RRs via preprocessing during zone file
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 [Tweedledee], while providing only a subset The AAAA RR proposed in [RFC1886], while providing only a subset of
of the functionality provided by the A6 RR proposed in [Tweedledum], the functionality provided by the A6 RR proposed in [RFC2874], has
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
skipping to change at page 7, line 34 skipping to change at page 7, line 34
have to issue A6 queries directly rather than relying on AAAA have to issue A6 queries directly rather than relying on AAAA
synthesis. synthesis.
Bitlabels Bitlabels
While the differences between AAAA and A6 RRs have generated most of While the differences between AAAA and A6 RRs have generated most of
the discussion to date, there are also two proposed mechanisms for the discussion to date, there are also two proposed mechanisms for
building the reverse mapping tree (the IPv6 equivalent of IPv4's IN- building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
ADDR.ARPA tree). ADDR.ARPA tree).
[Tweedledee] proposes a mechanism very similar to the IN-ADDR.ARPA [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
mechanism used for IPv4 addresses: the RR name is the hexadecimal mechanism used for IPv4 addresses: the RR name is the hexadecimal
representation of the IPv6 address, reversed and concatenated with a representation of the IPv6 address, reversed and concatenated with a
well-known suffix, broken up with a dot between each hexadecimal well-known suffix, broken up with a dot between each hexadecimal
digit. The resulting DNS names are somewhat tedious for humans to digit. The resulting DNS names are somewhat tedious for humans to
type, but are very easy for programs to generate. Making each type, but are very easy for programs to generate. Making each
hexadecimal digit a separate label means that delegation on arbitrary hexadecimal digit a separate label means that delegation on arbitrary
bit boundaries will result in a maximum of 16 NS RRs per label; bit boundaries will result in a maximum of 16 NS RRsets per label
again, the mechanism is somewhat tedious for humans, but is very easy level; again, the mechanism is somewhat tedious for humans, but is
to program. As with IPv4's IN-ADDR.ARPA tree, the one place where very easy to program. As with IPv4's IN-ADDR.ARPA tree, the one
this scheme is weak is in handling delegations in the least place where this scheme is weak is in handling delegations in the
significant label; however, since there appears to be no real need to least significant label; however, since there appears to be no real
delegate the least significant four bits of an IPv6 address, this need to delegate the least significant four bits of an IPv6 address,
does not appear to be a serious restriction. this does not appear to be a serious restriction.
[Tweedledum] proposed a radically different way of naming entries in [RFC2874] proposed a radically different way of naming entries in the
the reverse mapping tree: rather than using textual representations reverse mapping tree: rather than using textual representations of
of addresses, it proposes to use a new kind of DNS label (a "bit addresses, it proposes to use a new kind of DNS label (a "bit label")
label") to represent binary addresses directly in the DNS. This has to represent binary addresses directly in the DNS. This has the
the advantage of being significantly more compact than the textual advantage of being significantly more compact than the textual
representation, and arguably might have been a better solution for representation, and arguably might have been a better solution for
DNS to use for this purpose if it had been designed into the protocol DNS to use for this purpose if it had been designed into the protocol
from the outset. Unfortunately, experience to date suggests that from the outset. Unfortunately, experience to date suggests that
deploying a new DNS label type is very hard: all of the DNS name deploying a new DNS label type is very hard: all of the DNS name
servers that are authoritative for any portion of the name in servers that are authoritative for any portion of the name in
question must be upgraded before the new label type can be used, as question must be upgraded before the new label type can be used, as
must any resolvers involved in the resolution process. Any name must any resolvers involved in the resolution process. Any name
server that has not been upgraded to understand the new label type server that has not been upgraded to understand the new label type
will reject the query as being malformed. will reject the query as being malformed.
Since the main benefit of the bit label approach appears to be an Since the main benefit of the bit label approach appears to be an
ability that we don't really need (delegation in the least ability that we don't really need (delegation in the least
significant four bits of an IPv6 address), and since the upgrade significant four bits of an IPv6 address), and since the upgrade
problem is likely to render bit labels unusable until a significant problem is likely to render bit labels unusable until a significant
portion of the DNS code base has been upgraded, it is difficult to portion of the DNS code base has been upgraded, it is difficult to
escape the conclusion that the textual solution is good enough. escape the conclusion that the textual solution is good enough.
DNAME RRs DNAME RRs
[Tweedledum] also proposes using DNAME RRs as a way of providing the [RFC2874] also proposes using DNAME RRs as a way of providing the
equivalent of A6's fragmented addresses in the reverse mapping tree. equivalent of A6's fragmented addresses in the reverse mapping tree.
That is, by using DNAME RRs, one can write zone files for the reverse That is, by using DNAME RRs, one can write zone files for the reverse
mapping tree that have the same ability to cope with rapid mapping tree that have the same ability to cope with rapid
renumbering or GSE-style routing that the A6 RR offers in the main renumbering or GSE-style routing that the A6 RR offers in the main
portion of the DNS tree. Consequently, the need to use DNAME in the portion of the DNS tree. Consequently, the need to use DNAME in the
reverse mapping tree appears to be closely tied to the need to use reverse mapping tree appears to be closely tied to the need to use
fragmented A6 in the main tree: if one is necessary, so is the other, fragmented A6 in the main tree: if one is necessary, so is the other,
and if one isn't necessary, the other isn't either. and if one isn't necessary, the other isn't either.
Other uses have also been proposed for the DNAME RR, but since they Other uses have also been proposed for the DNAME RR, but since they
are outside the scope of the IPv6 address discussion, they will not are outside the scope of the IPv6 address discussion, they will not
be addressed here. be addressed here.
Recommendation Recommendation
Distilling the above feature comparisons down to their key elements, Distilling the above feature comparisons down to their key elements,
the important questions appear to be: the important questions appear to be:
(a) Is IPv6 going to do rapid renumber or GSE-like routing? (a) Is IPv6 going to do rapid renumbering or GSE-like routing?
(b) Is the reverse mapping tree for IPv6 going to require delegation (b) Is the reverse mapping tree for IPv6 going to require delegation
in the least significant four bits of the address? in the least significant four bits of the address?
Question (a) appears to be the key to the debate. This is really a Question (a) appears to be the key to the debate. This is really a
decision for the IPv6 community to make, not the DNS community. decision for the IPv6 community to make, not the DNS community.
Question (b) is also for the IPv6 community to make, but it seems Question (b) is also for the IPv6 community to make, but it seems
fairly obvious that the answer is "no". fairly obvious that the answer is "no".
Recommendations based on these questions: Recommendations based on these questions:
(1) If the IPv6 working groups seriously intend to specify and deploy (1) If the IPv6 working groups seriously intend to specify and deploy
rapid renumbering or GSE-like routing, we should transition to rapid renumbering or GSE-like routing, we should transition to
using the A6 RR in the main tree and to using DNAME RRs as using the A6 RR in the main tree and to using DNAME RRs as
necessary in the reverse tree. necessary in the reverse tree.
(2) Otherwise, we should keep the simpler AAAA solution in the main (2) Otherwise, we should keep the simpler AAAA solution in the main
tree and should not use DNAME RRs in the reverse tree. tree and should not use DNAME RRs in the reverse tree.
(3) In either case, the reverse tree should use the textual (3) In either case, the reverse tree should use the textual
representation described in [Tweedledee] rather than the bit representation described in [RFC1886] rather than the bit label
label representation described in [Tweedledum]. representation described in [RFC2874].
(4) If we do go to using A6 RRs in the main tree and to using DNAME (4) If we do go to using A6 RRs in the main tree and to using DNAME
RRs in the reverse tree, we should write applicability statements RRs in the reverse tree, we should write applicability statements
and implementation guidelines designed to discourage excessively and implementation guidelines designed to discourage excessively
complex uses of these features; in general, any network that can complex uses of these features; in general, any network that can
be described adequately using A6 0 RRs and without using DNAME be described adequately using A6 0 RRs and without using DNAME
RRs should be described that way, and the enhanced features RRs should be described that way, and the enhanced features
should be used only when absolutely necessary, at least until we should be used only when absolutely necessary, at least until we
have much more experience with them and have a better have much more experience with them and have a better
understanding of their failure modes. understanding of their failure modes.
skipping to change at page 9, line 40 skipping to change at page 9, line 40
characteristics, but there are a few security implications to the characteristics, but there are a few security implications to the
choice between these two mechanisms: choice between these two mechanisms:
(1) The two mechanisms have similar but not identical interactions (1) The two mechanisms have similar but not identical interactions
with DNSSEC. Please see the section entitled "Interactions with with DNSSEC. Please see the section entitled "Interactions with
DNSSEC" (above) for a discussion of these issues. DNSSEC" (above) for a discussion of these issues.
(2) To the extent that operational complexity is the enemy of (2) To the extent that operational complexity is the enemy of
security, the tradeoffs in operational complexity discussed security, the tradeoffs in operational complexity discussed
throughout this note have an impact on security. throughout this note have an impact on security.
(3) To the extent that protocol complexity is the enemy of security, (3) To the extent that protocol complexity is the enemy of security,
the additional protocol complexity of [Tweedledum] as compared to the additional protocol complexity of [RFC2874] as compared to
[Tweedledee] has some impact on security. [RFC1886] has some impact on security.
IANA Considerations IANA Considerations
None, since all of these RR types have already been allocated. None, since all of these RR types have already been allocated.
Acknowledgments Acknowledgments
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
[Tweedledee] Thomson, S., and Huitema, C., "DNS Extensions to support [RFC1886] Thomson, S., and Huitema, C., "DNS Extensions to support IP
IP version 6", RFC 1886, December 1995. version 6", RFC 1886, December 1995.
[Tweedledum] Crawford, M., and Huitema, C., "DNS Extensions to [RFC2874] Crawford, M., and Huitema, C., "DNS Extensions to Support
Support IPv6 Address Aggregation and Renumbering" RFC 2874, July IPv6 Address Aggregation and Renumbering" RFC 2874, July 2000.
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
discussed by the IPng working group in 1996 and 1997. The GSE
proposal itself was written up as an Internet-Draft, which has
long since expired. Readers interested in the details and
history of GSE should review the IPng working group's mailing
list archives and minutes from that period.
Author's addresses: Author's addresses:
Rob Austein Rob Austein
sra@hactrn.net sra@hactrn.net
 End of changes. 

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