rfc3364.txt

RFC 的详细文档！

   BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
   1024-bit RSA signatures per second.  Extrapolating from 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
   listing 10**5 hosts, or about a day to sign a zone listing 10**6
   hosts using AAAA RRs.

   This suggests that the additional effort of re-signing a large zone
   full of AAAA RRs during a re-numbering event, while noticeable, is
   only likely to be prohibitive in the rapid renumbering case where
   AAAA RRs don't work well anyway.

Interactions with Dynamic Update

   DNS dynamic update appears to work equally well for AAAA or A6 RRs,
   with one minor exception: with A6 RRs, the dynamic update client
   needs to know the prefix length and prefix name.  At present, no
   mechanism exists to inform a dynamic update client of these values,
   but presumably such a mechanism could be provided via an extension to
   DHCP, or some other equivalent could be devised.







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


Transition from AAAA to A6 Via AAAA Synthesis

   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.
   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
   that A6's enhanced capabilities are necessary, it should be possible
   to transition from AAAA to A6.

   The details of this transition have been left to a separate document,
   but the general idea is that the resolver that is performing
   iterative resolution on behalf of a DNS client program could
   synthesize AAAA RRs representing the result of performing the
   equivalent A6 queries.  Note that in this case it is not possible to
   generate an equivalent DNSSEC signature for the AAAA RR, so clients
   that care about performing DNSSEC validation for themselves would
   have to issue A6 queries directly rather than relying on AAAA
   synthesis.

Bitlabels

   While the differences between AAAA and A6 RRs have generated most of
   the discussion to date, there are also two proposed mechanisms for
   building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
   ADDR.ARPA tree).

   [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
   mechanism used for IPv4 addresses: the RR name is the hexadecimal
   representation of the IPv6 address, reversed and concatenated with a
   well-known suffix, broken up with a dot between each hexadecimal
   digit.  The resulting DNS names are somewhat tedious for humans to
   type, but are very easy for programs to generate.  Making each
   hexadecimal digit a separate label means that delegation on arbitrary
   bit boundaries will result in a maximum of 16 NS RRsets per label
   level; again, the mechanism is somewhat tedious for humans, but is
   very easy to program.  As with IPv4's IN-ADDR.ARPA tree, the one
   place where this scheme is weak is in handling delegations in the
   least significant label; however, since there appears to be no real
   need to delegate the least significant four bits of an IPv6 address,
   this does not appear to be a serious restriction.

   [RFC2874] proposed a radically different way of naming entries in the
   reverse mapping tree: rather than using textual representations of
   addresses, it proposes to use a new kind of DNS label (a "bit label")
   to represent binary addresses directly in the DNS.  This has the
   advantage of being significantly more compact than the textual
   representation, and arguably might have been a better solution for
   DNS to use for this purpose if it had been designed into the protocol



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


   from the outset.  Unfortunately, experience to date suggests that
   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
   question must be upgraded before the new label type can be used, as
   must any resolvers involved in the resolution process.  Any name
   server that has not been upgraded to understand the new label type
   will reject the query as being malformed.

   Since the main benefit of the bit label approach appears to be an
   ability that we don't really need (delegation in the least
   significant four bits of an IPv6 address), and since the upgrade
   problem is likely to render bit labels unusable until a significant
   portion of the DNS code base has been upgraded, it is difficult to
   escape the conclusion that the textual solution is good enough.

DNAME RRs

   [RFC2874] also proposes using DNAME RRs as a way of providing the
   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
   mapping tree that have the same ability to cope with rapid
   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
   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,
   and if one isn't necessary, the other isn't either.

   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
   be addressed here.

Recommendation

   Distilling the above feature comparisons down to their key elements,
   the important questions appear to be:

   (a) Is IPv6 going to do rapid renumbering or GSE-like routing?

   (b) Is the reverse mapping tree for IPv6 going to require delegation
       in the least significant four bits of the address?

   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.

   Question (b) is also for the IPv6 community to make, but it seems
   fairly obvious that the answer is "no".





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


   Recommendations based on these questions:

   (1) If the IPv6 working groups seriously intend to specify and deploy
       rapid renumbering or GSE-like routing, we should transition to
       using the A6 RR in the main tree and to using DNAME RRs as
       necessary in the reverse tree.

   (2) Otherwise, we should keep the simpler AAAA solution in the main
       tree and should not use DNAME RRs in the reverse tree.

   (3) In either case, the reverse tree should use the textual
       representation described in [RFC1886] rather than the bit label
       representation described in [RFC2874].

   (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
       and implementation guidelines designed to discourage excessively
       complex uses of these features; in general, any network that can
       be described adequately using A6 0 RRs and without using DNAME
       RRs should be described that way, and the enhanced features
       should be used only when absolutely necessary, at least until we
       have much more experience with them and have a better
       understanding of their failure modes.

Security Considerations

   This note compares two mechanisms with similar security
   characteristics, but there are a few security implications to the
   choice between these two mechanisms:

   (1) The two mechanisms have similar but not identical interactions
       with DNSSEC.  Please see the section entitled "Interactions with
       DNSSEC" (above) for a discussion of these issues.

   (2) To the extent that operational complexity is the enemy of
       security, the tradeoffs in operational complexity discussed
       throughout this note have an impact on security.

   (3) To the extent that protocol complexity is the enemy of security,
       the additional protocol complexity of [RFC2874] as compared to
       [RFC1886] has some impact on security.

IANA Considerations

   None, since all of these RR types have already been allocated.






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


Acknowledgments

   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
   Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
   Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
   and Sue Thomson, none of whom are responsible for what the author did
   with their ideas.

References

   [RFC1886]    Thomson, S. and C. Huitema, "DNS Extensions to support
                IP version 6", RFC 1886, December 1995.

   [RFC2874]    Crawford, M. and C. Huitema, "DNS Extensions to Support
                IPv6 Address Aggregation and Renumbering", RFC 2874,
                July 2000.

   [Sommerfeld] Private message to the author from Bill Sommerfeld dated
                21 March 2001, summarizing the result of experiments he
                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 Address

   Rob Austein

   EMail: [e-mail]
















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


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.



















Austein                      Informational                     [Page 11]