rfc3364.txt

RFC 的详细文档！

Network Working Group                                         R. Austein
Request for Comments: 3364                           Bourgeois Dilettant
Updates: 2673, 2874                                          August 2002
Category: Informational


             Tradeoffs in Domain Name System (DNS) Support
                 for Internet Protocol version 6 (IPv6)

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Abstract

   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
   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
   that we can reach closure and move on.

Introduction

   RFC 1886 [RFC1886] specified straightforward mechanisms to support
   IPv6 addresses in the DNS.  These mechanisms closely resemble the
   mechanisms used to support IPv4, with a minor improvement to the
   reverse mapping mechanism based on experience with CIDR.  RFC 1886 is
   currently listed as a Proposed Standard.

   RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
   addresses in the DNS.  These mechanisms provide new features that
   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
   network topology underlying the address, thus making it possible for
   the data stored in the DNS to reflect certain kinds of network
   topology changes or routing architectures that are either impossible
   or more difficult to represent without these mechanisms.  RFC 2874 is
   also currently listed as a Proposed Standard.







Austein                      Informational                      [Page 1]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002


   Both of these Proposed Standards were the output of the IPNG Working
   Group.  Both have been implemented, although implementation of
   [RFC1886] is more widespread, both because it was specified earlier
   and because it's simpler to implement.

   There's little question that the mechanisms proposed in [RFC2874] are
   more general than the mechanisms proposed in [RFC1886], and that
   these enhanced mechanisms might be valuable if IPv6's evolution goes
   in certain directions.  The questions are whether we really need the
   more general mechanism, what new usage problems might come along with
   the enhanced mechanisms, and what effect all this will have on IPv6
   deployment.

   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.

Main Advantages of Going with A6

   While the A6 RR proposed in [RFC2874] is very general and provides a
   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
   preprocessing during zone file generation.

   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
   prefix portion of the address can change without any action (or
   perhaps even knowledge) by the parties controlling the DNS zone
   containing the terminal portion (least significant bits) of the
   address.  This includes both so-called "rapid renumbering" scenarios
   (where an entire network's prefix may change very quickly) and
   routing architectures such as the former "GSE" proposal [GSE] (where
   the "routing goop" portion of an address may be subject to change
   without warning).  A6 RRs do not completely remove the need to update
   leaf zones during all renumbering events (for example, changing ISPs
   would usually require a change to the upward delegation pointer), but
   careful use of A6 RRs could keep the number of RRs that need to
   change during such an event to a minimum.

   Note that constructing AAAA RRs via preprocessing during zone file
   generation requires exactly the sort of information that A6 RRs store
   in the DNS.  This begs the question of where the hypothetical
   preprocessor obtains that information if it's not getting it from the
   DNS.

   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
   "wasted" octet in the wire representation), so anything that can be
   done with an AAAA RR can also be done with an A6 RR.



Austein                      Informational                      [Page 2]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002


Main Advantages of Going with AAAA

   The AAAA RR proposed in [RFC1886], while providing only a subset of
   the functionality provided by the A6 RR proposed in [RFC2874], has
   two main points to recommend it:

   - 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
     us predict the usage patterns, failure scenarios and so forth
     associated with AAAA RRs.

   - The AAAA RR is "optimized for read", in the sense that, by storing
     a complete address rather than making the resolver fetch the
     address in pieces, it minimizes the effort involved in fetching
     addresses from the DNS (at the expense of increasing the effort
     involved in injecting new data into the DNS).

Less Compelling Arguments in Favor of A6

   Since the A6 RR allows a zone administrator to write zone files whose
   description of addresses maps to the underlying network topology, A6
   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
   it's more of an argument for better tools for zone administrators to
   use when constructing zone files than a justification for changing
   the resolution protocol used on the wire.

Less Compelling Arguments in Favor of AAAA

   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
   construct transition tools (see discussion of AAAA synthesis, later
   in this note), this does not appear to be a compelling argument if A6
   provides features that we really need.

   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
   which a zone administrator could build a non-working configuration.
   While operational issues are certainly important, this is more of
   argument that we need better tools for zone administrators than it is
   a justification for turning away from A6 if A6 provides features that
   we really need.









Austein                      Informational                      [Page 3]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002


Potential Problems with A6

   The enhanced capabilities of the A6 RR, while interesting, are not in
   themselves justification for choosing A6 if we don't really need
   those capabilities.  The A6 RR is "optimized for write", in the sense
   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
   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
   expect the effort involved in maintaining AAAA-style DNS entries to
   be prohibitive, but in general, we expect the DNS data to be read
   more frequently than it is written, so we need to evaluate this
   particular tradeoff very carefully.

   There are also several potential issues with A6 RRs that stem
   directly from the feature that makes them different from AAAA RRs:
   the ability to build up address via chaining.

   Resolving a chain of A6 RRs involves resolving a series of what are
   almost independent queries, but not quite.  Each of these sub-queries
   takes some non-zero amount of time, unless the answer happens to be
   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
   average, it will take something approaching time N*T to resolve an
   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
   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
   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
   failure to a client.  What little data we have on this subject
   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
   are not likely to be patient with significantly longer delays in the
   IPv6 Internet.  At the same time, terminating queries prematurely is
   both a waste of resources and another source of user frustration.
   Thus, we are forced to conclude that indiscriminate use of long A6
   chains is likely to lead to problems.

   To make matters worse, the places where A6 RRs are likely to be most
   critical for rapid renumbering or GSE-like routing are situations
   where the prefix name field in the A6 RR points to a target that is
   not only outside the DNS zone containing the A6 RR, but is
   administered by a different organization (for example, in the case of
   an end user's site, the prefix name will most likely point to a name
   belonging to an ISP that provides connectivity for the site).  While
   pointers out of zone are not a problem per se, pointers to other
   organizations are somewhat more difficult to maintain and less



Austein                      Informational                      [Page 4]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002


   susceptible to automation than pointers within a single organization
   would be.  Experience both with glue RRs and with PTR RRs in the IN-
   ADDR.ARPA tree suggests that many zone administrators do not really
   understand how to set up and maintain these pointers properly, and we
   have no particular reason to believe that these zone administrators
   will do a better job with A6 chains than they do today.  To be fair,
   however, the alternative case of building AAAA RRs via preprocessing
   before loading zones has many of the same problems; at best, one can
   claim that using AAAA RRs for this purpose would allow DNS clients to
   get the wrong answer somewhat more efficiently than with A6 RRs.

   Finally, assuming near total ignorance of how likely a query is to
   fail, the probability of failure with an N-link A6 chain would appear
   to be roughly proportional to N, since each of the queries involved
   in resolving an A6 chain would have the same probability of failure
   as a single AAAA query.  Note again that this comment applies to
   failures in the the process of resolving a query, not to the data
   obtained via that process.  Arguably, in an ideal world, A6 RRs would
   increase the probability of the answer a client (finally) gets being
   right, assuming that nothing goes wrong in the query process, but we
   have no real idea how to quantify that assumption at this point even
   to the hand-wavey extent used elsewhere in this note.

   One potential problem that has been raised in the past regarding A6
   RRs turns out not to be a serious issue.  The A6 design includes the
   possibility of there being more than one A6 RR matching the prefix
   name portion of a leaf A6 RR.  That is, an A6 chain may not be a
   simple linked list, it may in fact be a tree, where each branch
   represents a possible prefix.  Some critics of A6 have been concerned
   that this will lead to a wild expansion of queries, but this turns
   out not to be a problem if a resolver simply follows the "bounded
   work per query" rule described in RFC 1034 (page 35).  That rule
   applies to all work resulting from attempts to process a query,
   regardless of whether it's a simple query, a CNAME chain, an A6 tree,
   or an infinite loop.  The client may not get back a useful answer in
   cases where the zone has been configured badly, but a proper
   implementation should not produce a query explosion as a result of
   processing even the most perverse A6 tree, chain, or loop.

Interactions with DNSSEC

   One of the areas where AAAA and A6 RRs differ is in the precise
   details of how they interact with DNSSEC.  The following comments
   apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
   semantically equivalent to AAAA RRs).






Austein                      Informational                      [Page 5]

RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002


   Other things being equal, the time it takes to re-sign all of the
   addresses in a zone after a renumbering event is longer with AAAA RRs
   than with A6 RRs (because each address record has to be re-signed
   rather than just signing a common prefix A6 RR and a few A6 0 RRs
   associated with the zone's name servers).  Note, however, that in
   general this does not present a serious scaling problem, because the
   re-signing is performed in the leaf zones.

   Other things being equal, there's more work involved in verifying the
   signatures received back for A6 RRs, because each address fragment
   has a separate associated signature.  Similarly, a DNS message
   containing a set of A6 address fragments and their associated
   signatures will be larger than the equivalent packet with a single
   AAAA (or A6 0) and a single associated signature.

   Since AAAA RRs cannot really represent rapid renumbering or GSE-style
   routing scenarios very well, it should not be surprising that DNSSEC
   signatures of AAAA RRs are also somewhat problematic.  In cases where
   the AAAA RRs would have to be changing very quickly to keep up with
   prefix changes, the time required to re-sign the AAAA RRs may be
   prohibitive.

   Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
   333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the