Network Working Group                                           Crawford
Internet Draft                                                  Fermilab
                                                           July 23, 2001

                <draft-ietf-dnsext-ipv6-dns-response-00.txt>





Status of this Memo

    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026.  Internet-Drafts are
    working documents of the Internet Engineering Task Force (IETF), its
    areas, and its working groups.  Note that other groups may also
    distribute working documents as Internet-Drafts.

    Internet-Drafts are draft documents valid for a maximum of six
    months 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."

    To view the list Internet-Draft Shadow Directories, see
    http://www.ietf.org/shadow.html.


Abstract

    This document provides additional information and opinions which the
    author considers to have been overlooked or misstated in [TRADE] and
    [COMPAR].


1.  Points Relating to A6


1.1.  Optimized for Write?

    The A6 method of recording IPv6 addresses has been said to be
    optimized for insertion of data at the expense of additional work in
    retrieving data.  This "additional expense" may vanish, or even
    become an additional savings, if one takes into account possible
    locality of reference, either in topological space or in time.

    A6 allows a site's subnet assignments and interface identifiers to
    be split from its global routing information.  Only a single record
    need be retrieved if one looks up several names that turn out to be



Expires January 28, 2002        Crawford                        [Page 1]

Internet Draft         Response to Tradeoffs ...           July 23, 2001


    within a common routing aggregate -- and if the A6 structure
    reflects this commonality.  If the common aggregate is a site, it
    would be expected to always be visible in the A6 chaining.  A larger
    aggregation would sometimes be visible.

    And if a lookup is cause by the timing out of a short-lived A6
    prefix record, one transaction may serve to restore the validity of
    a large number of cached IPv6 addresses.

    A more accurate characterization would be that A6 is "optimized for
    locality of reference."  This is a condition that always exists for
    a "write" of a zone of non-trivial size, and which exists for many
    common sorts of "read" operations.


1.2.  Less Novel Than Some Think

    [COMPAR] makes the statement that "there has been no DNS record
    types that require multiple queries for resolution of the address".
    This is not so.  Almost all CNAME records are exactly such record
    types, differing only in that the last iteration obtains a different
    record type from the first N-1 iterations.  Experience with CNAME
    has some relevance for estimating the performance of A6.

    Servers returning a CNAME record (when CNAME does not match the
    QTYPE) return the "chained" records along with the CNAME, if they
    are available.  The specified processing [DNSEXT] for A6 does so as
    well.  Any demands that CNAME records be banned on performance
    ground have been very faint indeed.


1.3.  DNSSEC - Aggravation or Amelioration?

    An extreme case of A6 deployment (some might say a nightmare case),
    in the A6 record for each portion of an address is in a zone
    belonging to the party by whom that set of bits has been assigned.
    This is a situation which is improved by ubiquitous use of DNSSEC
    [DNSSEC] since the leaf site can cache authenticated data for its
    entire prefix chain and a DNS client can confidently accept that
    data without having to make extra queries.  (Except perhaps for the
    KEY records required to verify the signatures, but those records
    will be long-lived.)

    If leaf-site DNS servers proactively fetch and cache the A6 prefix
    records their data point to, DNSSEC completely offsets concerns
    about increased query time and failure probability.

    In addition, A6 may be found to complement DNSSEC.  If prefix A6



Expires January 28, 2002        Crawford                        [Page 2]

Internet Draft         Response to Tradeoffs ...           July 23, 2001


    records are held in a separate zone, they can be signed with a
    separate key which may reflect and be held by a different authority.

    Little weight should be given to consideration of signature
    verification time for end-nodes when transaction security [TSIG] can
    be exploited.


1.4.  A6 Chaining Follows Routing Aggregation

    Early adopters of A6 records will probably continue for some time to
    hold all portions of their A6 chains in their own zone file(s).
    When and if they move on to a more renumbering-agile configuration,
    the A6 prefix records will be held by the same entity that provides
    them IPv6 connectivity.  This is an entity with whom they maintain
    some relationship and share some configuration information.  (Even
    if that information flows in only one direction.)  There is little
    reason to worry that the information required to construct and
    maintain agile A6 chains will be unavailable.  Comparisons to the
    sorry state of the IPv4 in-addr.arpa data are exaggerations.


1.5.  DoS Attacks

    The Denial of Service attack outlined in [COMPAR] is based on a
    particular and questionable treatment of TTLs for records being
    assembled to answer a query.  But aside from that, it has analogues
    which employ only CNAME and/or NS records, so A6 introduces no
    really novel problem.


1.6.  A Nitty-Gritty Detail

    [COMPAR] asserts, " if we would like to advertise only
    2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not
    possible to do so.  It becomes mandatory for us to define the whole
    IPv6 address by using ``A6 0'' for N.X.EXAMPLE, and in effect, the
    benefit of A6 (renumber friendliness) goes away."  This is not at
    all the case.  The site can maintain A6 prefix records for "Provider
    A", "Provider B" and "All My Prefixes".


2.  Points Not Directly Related to A6

    The points below generally concern the other side of the coin, the
    address-to-name data and lookups.  This is fairly independent of the
    A6 vs. AAAA choice, but [TRADE] and other documents sometimes
    present the question as one of RFC 1886 vs. RFC 2874, each of which



Expires January 28, 2002        Crawford                        [Page 3]

Internet Draft         Response to Tradeoffs ...           July 23, 2001


    includes both a forward and reverse mechanism.


2.1.  Aid to Reverse-Zone Maintenance

    Proper maintenance of the so-called "reverse" information, that
    which maps addresses to names, has at times been considered very
    useful, or even important.  Its general state in the internet has
    been poor for many years.  RFC 2874 [DNSEXT] includes a method for
    putting both "forward" and "reverse" information in the same zone.
    [DNSEXT presents this method in the context of A6 and bit-string
    labels, but it is not strictly dependent on either.  It does,
    however, require the use of the DNAME mechanism.


3.  IANA Considerations

    No codepoints, parameters or name spaces are defined by this
    document.


4.  Security Considerations

    This document discusses security considerations in an offhand
    manner, but does not specify any standards or practices.


5.  Acknowledgments


6.  References

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

    [DNSSEC]
         D. Eastlake, "Domain Name System Security Extensions", RFC
         2535.

    [TSIG]Vixie, P., and O. Gudmundsson, "Secret Key Transaction
         Authentication for DNS (TSIG)", RFC 2845.

    [TRADE]
         R. Austein, "Tradeoffs in DNS support for IPv6", Work in
         progress.  (Currently draft-ietf-dnsext-ipv6-dns-tradeoffs-
         00.txt.)




Expires January 28, 2002        Crawford                        [Page 4]

Internet Draft         Response to Tradeoffs ...           July 23, 2001


    [COMPAR]
         J. Hagino, "Comparison of AAAA and A6 (do we really need A6?)",
         Work in progress.  (Currently draft-ietf-dnsext-aaaa-a6-
         01.txt.)

7.  Author's Address

    Matt Crawford
    Fermilab MS 368
    PO Box 500
    Batavia, IL 60510
    USA

    Phone: +1 630 840-3461
    EMail: crawdad@fnal.gov




































Expires January 28, 2002        Crawford                        [Page 5]