To
make renumbering easier, A6 records can specify only a part of an
IPv6 address, such as the last 64 bits (the interface ID) assigned to
a host's network interface, and then refer to the remainder of
the address by a symbolic domain name. This allows zone
administrators to specify only the part of the address under their
control. To build an entire address, a resolver or name server must
follow the chain of A6 records from a host's domain name to the
TLA ID. And that chain may branch if a site network is connected to
multiple NLAs or if an NLA is connected to multiple TLAs.
For example, the A6 record:
$ORIGIN movie.edu.
drunkenmaster IN A6 64 ::0210:4bff:fe10:0d24 subnet1.v6.movie.edu.
specifies the final 64 bits of
drunkenmaster.movie.edu's IPv6 address (64
is the number of bits of the prefix not
specified in this A6 record) and that the remaining 64
bits can be found by looking up an A6 record at
subnet1.v6.movie.edu.
subnet1.v6.movie.edu, in turn, specifies the
last 16 bits of the 64-bit prefix (the SLA ID) that we didn't
specify in drunkenmaster.movie.edu's A6
address as well as the domain name of the next A6 record to look up:
$ORIGIN v6.movie.edu.
subnet1 IN A6 48 0:0:0:1:: movie-u.nla-a.net.
subnet1 IN A6 48 0:0:0:1:: movie.nlab.net.
The first 48 bits of the prefix in
subnet1.v6.movie.edu's record-specific
data are set to zero, since they're not significant here.
In fact, these records tell us to look up two A6
records next, one at movie-u.nla-a.net and one
at movie.nlab.net. That's because Movie U.
has connections to two NLAs, NLA A and NLA B. In NLA A's zone,
we'd find:
$ORIGIN nla-a.net.
movie-u IN A6 40 0:0:21:: nla-a.tla-1.net.
indicating the eight-bit Site ID pattern within
the NLA IDfield set by NLA A for the Movie
University network. You see, the NLA ID field is hierarchical, too,
comprising both an identifier for our Next-Level Aggregator assigned
to it by its TLA, and its identifier for our
network. Since the NLA assigns our Site ID but has the rest of their
NLA ID assigned by its TLA, we'd expect to see only our Site ID
in our NLA's zone data. The remainder of its NLA ID would
appear in an A6 record in its TLA's zone.
In NLA B's zone, we'd find the following record showing
us their Site ID for our network:
$ORIGIN nlab.net.
movie IN A6 40 0:0:42:: nlab.tla-2.net.
In the TLAs' zones, we'd find:
$ORIGIN tla-1.net.
nla-a IN A6 16 0:10:2500:: tla-1.top-level-v6.net.
and:
$ORIGIN tla-2.net.
nlab IN A6 16 0:19:6600:: tla-2.top-level-v6.net.
Finally, in the top-level IPv6 address registry's zone,
we'd find this record showing us the TLA IDs assigned to TLA 1
and TLA 2:
$ORIGIN top-level-v6.net.
tla-1 IN A6 0 222::
tla-2 IN A6 0 242::
By following this chain of A6 records, a name server can assemble all
128 bits of drunkenmaster.movie.edu's two
IPv6 addresses. These turn out to be:
222:10:2521:1:210:4bff:fe10:d24
242:19:6642:1:210:4bff:fe10:d24
The first of these uses a route through TLA 1 and NLA A to the Movie
U. network, and the second uses a route through TLA 2 and NLA B.
(We're connected to two NLAs for redundancy.) Note that if TLA
1 changes its NLA assignment for NLA A, it only needs to change the
A6 record for nla-a.tla-1.net in its zone data;
the change "cascades" into all A6 chains that go through
NLA A. This makes the management of addressing on IPv6 networks very
convenient, and makes changing NLAs easy, too.