draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt

bind-3.2.


draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt                    July 2001


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

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



Austein                  Expires 12 January 2002                [Page 6]

draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt                    July 2001


   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.

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

   [Tweedledee] 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 RRs per label;
   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.

   [Tweedledum] 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



Austein                  Expires 12 January 2002                [Page 7]

draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt                    July 2001


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

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

Other topics ???

Recommendation

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

   (a) Is IPv6 going to do rapid renumber 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.



Austein                  Expires 12 January 2002                [Page 8]

draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt                    July 2001


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

   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 [Tweedledee] rather than the bit
       label representation described in [Tweedledum].
   (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

   ???

IANA Considerations

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

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

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

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



Austein                  Expires 12 January 2002                [Page 9]

draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt                    July 2001


        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.

Author's addresses:

      Rob Austein
      InterNetShare, Inc.
      505 West Olive Ave., Suite 321
      Sunnyvale, CA 94086
      USA
      [e-mail]





































Austein                  Expires 12 January 2002               [Page 10]