RFC 3364 (rfc3364) - Page 2 of 11
Tradeoffs in Domain Name System (DNS) Support for Internet Protocol version 6 (IPv6)
Alternative Format: Original Text Document
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 [RFC 1886] 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 [RFC 2874] are more general than the mechanisms proposed in [RFC 1886], 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 [RFC 2874] is very general and provides a superset of the functionality provided by the AAAA RR in [RFC 1886], 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
