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.