The A6 record is a new DNS record, described in detail in RFC 2874, meant to replace the AAAA record in IPv6 address resolution.

The primary new feature of A6 records is the possibility to divide the IPv6 address to a chain formed by several A6 records residing on different name servers, to ease the generation of aggregatable and renumberable IPv6 addresses.

The concept of an A6 record chain can be hard to grasp without an example, so an example shall be provided:

Consider the host foo, on site bar.baz. bar.baz has bought their Internet connectivity from ISPs isp-1.baz and isp-2.baz. Both ISPs have their own IPv6 address spaces, with prefixes 2001:1::/32 and 2001:2::/32. Both ISPs have also assigned the number 42 as the next level aggregation identifier for bar.baz.

The site bar.baz now has two address ranges, 2001:1:42::/48 and 2001:2:42::/48. For the host foo they have assigned the subnet ID 1 and the interface ID 2a. So the two addresses for foo.bar.baz are 2001:1:42:1::2a and 2001:2:42:1::2a. Using AAAA records, this would be expressed in the zone file of bar.baz as:

$ORIGIN bar.baz.
foo   IN   AAAA   2001:1:42:1::2a
           AAAA   2001:2:42:1::2a

The drawback for this approach is that the addresses contained in bar.baz would have to be changed, should isp-1 or isp-2 for some reason renumber its network. With A6 records, the site bar.baz only needs to give the part of the IPv6 address they themselves decide (in this case, the last 80 bits), and point out which DNS names contain the A6 records for the prefixes in the first 48 bits.

The format of an A6 record is:
A6 <prefix-len> <ipv6-address> [dns-name]
Here the prefix-len is a decimal number between 0 and 128, inclusive. The prefix lenght is the amount of bits that are missing from the ipv6-address part, and are supposed to be retrieved querying the name specified, dns-name. In the special case when prefix length is 0 (and the address is complete), the dns-name may be omitted. (Obviously, if the address is complete, there's no need to do further queries.)

So, using A6 chains, the addresses for foo.bar.baz would be in the DNS zones like this:

On the name servers of bar.baz:

$ORIGIN bar.baz.
foo            A6   64 ::2a subnet-1.ip6
subnet-1.ip6   A6   48 0:0:0:1:: ip6
ip6            A6   48 0::0 subscriber-bar.ip6.isp1.baz.
ip6            A6   48 0::0 subscriber-bar.ip6.isp2.baz.
On the name servers of isp-1.baz:
$ORIGIN isp-1.baz.
subscriber-bar.ip6     A6   32 0:0:42:: isp-1.ip6.tla-admin.baz.
isp-2.baz:
$ORIGIN isp-2.baz.
subscriber-bar.ip6     A6   32 0:0:42:: isp-2.ip6.tla-admin.baz.
tla-admin.baz:
$ORIGIN tla-admin.baz.
isp-1.ip6      A6   0 2001:1::
isp-2.ip6      A6   0 2001:2::

This example is far too simple to occur in Real World - there would undoubtedly be more levels of aggregation (and thus more levels of indirection in the DNS records), but it was simplified in order to be more understandable. For a "better" example, see the aforementioned RFC, 2874.

Currently the A6 record proposal hasn't received much popularity (a bit like the ip6.arpa zone), perhaps because of the added complexity and the fact that very few resolver libraries support the resolving of A6 chains properly. Still, it might very well be the future.

Log in or register to write something here or to contact authors.