10.16 IPv6 Forward and Reverse Mapping
Clearly, the existing A
record won't accommodate IPv6's 128-bit addresses; BIND
expects an A record's record-specific data to be a 32-bit
address in dotted-octet format.
The IETF came up with a simple solution to this problem, described in
RFC 1886. A new
address record, AAAA, is used to store a 128-bit IPv6
address, and there's a new IPv6 reverse-mapping domain,
ip6.int. This solution was straightforward
enough to implement in BIND 4.9. Unfortunately, not everyone liked
the simple solution, so they came up with a much more complicated
one. This solution, which we'll describe shortly, involves the
new A6 and DNAME records and required a complete overhaul of the BIND
name server to implement.
Use of the old AAAA record and ip6.int is now
deprecated, but there's enough IPv6 software out there still
using it—and not the new stuff—that it's important
to understand both methods.
10.16.1 AAAA and ip6.int
Now the simple way to handle this, described in RFC 1886, is with an
address record that's four times as long as an A record.
That's the AAAA (pronounced "quad A")
record. The AAAA record takes as its record-specific data the textual
format of an IPv6 record as described earlier. So for example,
you'd see AAAA records like this one:
ipv6-host IN AAAA 4321:0:1:2:3:4:567:89ab
RFC 1886 also established
ip6.int
,
a new reverse-mapping name space for IPv6 addresses. Each level of
subdomain under ip6.int represents four bits of
the 128-bit address, encoded as a hexadecimal digit just like in the
record-specific data of the AAAA record. The least significant
(lowest order) bits appear at the far left of the domain name. Unlike
the format of addresses in AAAA records, omitting leading zeros is
not allowed, so there are always 32 hexadecimal digits and 32 levels
of subdomain below ip6.int in a domain name
corresponding to a full IPv6 address. The domain name that
corresponds to the address in the previous example is:
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int.
These domain names have PTR records attached, just as the domain
names under in-addr.arpa do:
b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.ip6.int. IN PTR mash.ip6.movie.edu.
10.16.2 A6, DNAMEs, Bitstring Labels, and ip6.arpa
That's the easy way. The more difficult—and now
official—way of handling IPv6 forward and reverse mapping uses
two new record types, A6 and DNAME records. A6 and DNAME records are
described in RFCs 2874 and 2672, respectively. Version 9.0.0 is the
first version of BIND to support these records.
The main reason the AAAA record and the ip6.int
reverse-mapping scheme were replaced was because they made network
renumbering difficult. For example, if an organization were to change
Next-Level Aggregators, it would have to change all the AAAA records
in its zone data files since 24 of the bits of an IPv6 address are an
identifier for the NLA. Or imagine an NLA changing TLAs: this would
wreak havoc with its customers' zone data.
10.16.2.1 A6 records and forward mapping
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.
 |
If a name server appears in an NS record and owns one or more A6
records, those A6 records should specify all 128 bits of the IPv6
address. This helps avoid deadlock problems, where a resolver or name
server needs to talk to a remote name server to resolve part of that
name server's IPv6 address.
|
|
10.16.2.2 DNAME records and reverse mapping
Now that you've seen how forward
mapping works with A6 records, let's look at how reverse
mapping IPv6 addresses works. As with A6 records, unfortunately, this
isn't nearly as simple as ip6.int.
Reverse mapping IPv6 addresses involves DNAME records, described in
RFC 2672, and
bitstring labels, introduced in RFC 2673. DNAME records are a little like
wildcard CNAME records. They're used to substitute one suffix
of a domain name with another. For example, if we had previously used
the domain name movieu.edu at Movie University
but had since changed to movie.edu, we could
have replaced the old movieu.edu zone with this
one:
$TTL 1d
@ IN SOA terminator.movie.edu. root.movie.edu. (
2000102300
3h
30m
30d
1h )
IN NS terminator.movie.edu.
IN NS wormhole.movie.edu.
IN MX 10 postmanrings2x.movie.edu.
IN DNAME movie.edu.
The DNAME record in the movieu.edu zone applies
to any domain name that ends in movieu.edu
except movieu.edu itself. Unlike the CNAME
record, the DNAME record can coexist with other record types owned by
the same domain name as long as they aren't CNAME or other
DNAME records. The owner of the DNAME record may
not have any subdomains, though.
When the movieu.edu name server receives a query
for any domain name that ends in movieu.edu, say
cuckoosnest.movieu.edu, the DNAME record tells
it to "synthesize" an alias from
cuckoosnest.movieu.edu to
cuckoosnest.movie.edu, replacing
movieu.edu with movie.edu:
cuckoosnest.movieu.edu. IN CNAME cuckoosnest.movie.edu.
It's a little like sed 's
"s" (substitute) command. The
movieu.edu name server replies with this CNAME
record. If it's responding to a newer name server, it also
sends the DNAME record in the response, and the recipient name server
can then synthesize its own CNAME records from the cached DNAME.
Bitstring labels are
the other half of the magic involved in IPv6 reverse mapping.
Bitstring labels are simply a compact way of representing a long
sequence of binary (i.e., one-bit) labels in a domain name. Say you
wanted to permit delegation between any two bits of an IP address.
That might compel you to represent each bit of the address as a label
in a domain name. But that would require over 128 labels for a domain
name that represented an IPv6 address! Oy!
Bitstring labels concatenate the bits in successive labels into a
shorter hexadecimal, octal, binary or dotted-octet string. The string
is encapsulated between the tokens "\[" and
"]" to distinguish it from a traditional label, and
begins with one letter that determines the base of the string:
b for binary, o for octal,
and x for hexadecimal.
Here are the bitstring labels that correspond to
drunkenmaster.movie.edu's two IPv6
addresses:
\[x022200102521000102104bfffe100d24]
\[x024200196642000102104bfffe100d24]
Notice that the most significant bit begins the string, as in the
text representation of an IPv6 address, but in the opposite order of
the labels in the in-addr.arpa domain. Despite
this, these two bitstring labels are simply a different encoding of
traditional domain names that begin:
0.0.1.0.0.1.0.0.1.0.1.1.0.0.0.0.0.0.0.0.1.0.0.0.0.1.1.1.1.1.1.1...
Also note that all 32 hex digits in the address are present—you
can't drop leading zeros, because there are no colons to
separate groups of four digits.
Bitstring labels can also represent parts of IPv6 addresses, in which
case you need to specify the number of significant bits in the
string, separated from the string by a slash. So TLA 1's TLA ID
is \[x0222/16].
Together, DNAMEs and bitstring labels are used to match portions of a
long domain name that encodes an IPv6 address and to iteratively
change the domain name looked up to a domain name in a zone under the
control of the organization that manages the host with that IPv6
address.
Imagine we're reverse mapping
\[x024200196642000102104bfffe100d24].ip6.arpa,
the domain name that corresponds to
drunkenmaster.movie.edu's network
interface (when reached through TLA 2 and NLA B). The root name
servers would probably refer our name server to the
ip6.arpa name servers, which contain these
records:
$ORIGIN ip6.arpa.
\[x0222/16] IN DNAME ip6.tla-1.net.
\[x0242/16] IN DNAME ip6.tla-2.net.
The first of these matches the beginning of the domain name
we're looking up, so the ip6.arpa name
servers reply to our name server with an alias that says:
\[x024200196642000102104bfffe100d24].ip6.arpa. IN CNAME
\[x00196642000102104bfffe100d24].ip6.tla-2.net.
Notice that the first four hex digits (the most significant 16 bits)
of the address are stripped off, and the end of the target of the
alias is now ip6.tla-2.net, since we know this
address belongs to TLA 2. In ip6.tla-2.net, we
find:
$ORIGIN ip6.tla-2.net.
\[x00196600/24] IN DNAME ip6.nlab.net.
This turns the domain name in our new query:
\[x00196642000102104bfffe100d24].ip6.tla-2.net
into:
\[x42000102104bfffe100d24].ip6.nlab.net
Next, our name server queries the ip6.nlab.net
name servers for the new domain name. This record in the
ip6.nlab.net zone:
$ORIGIN ip6.nlab.net.
\[x0042/8] IN DNAME ip6.movie.edu.
turns the domain name we're looking up into:
\[x000102104bfffe100d24].ip6.movie.edu
The ip6.movie.edu zone, finally, contains the
PTR record that gives us the domain name of the host we're
after:
$ORIGIN ip6.movie.edu.
\[x000102104bfffe100d24/80] IN PTR drunkenmaster.ip6.movie.edu.
Mercifully, as a zone administrator you'll probably only be
responsible for maintaining PTR records like the ones in
ip6.movie.edu. Even if you work for a Top-Level
or Next-Level Aggregator, creating DNAME records that
"extract" the appropriate NLA ID or Site ID from your
customers' addresses isn't too tough. And you gain the
convenience of using a single zone data file for your reverse-mapping
information, even though each of your hosts has multiple addresses,
and of being able to switch NLAs without changing all of your
zone
data
files.
|
