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

Document Type RFC - Informational (August 2002; Errata)
Last updated 2015-10-14
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3364 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Thomas Narten
IESG note Published as RFC 3363 and 3364
Send notices to <>
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.


   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.


   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

   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

   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]
Show full document text