draft-ietf-dnsext-aaaa-a6-01.txt [plain text]
Internet Engineering Task Force Jun-ichiro itojun Hagino
INTERNET-DRAFT IIJ Research Laboratory
Expires: January 19, 2002 July 19, 2001
Comparison of AAAA and A6 (do we really need A6?)
draft-ietf-dnsext-aaaa-a6-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as ``work in progress.''
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
The internet-draft will expire in 6 months. The date of expiration will
be January 19, 2002.
Abstract
At this moment, there are two DNS resource record types defined for
holding IPv6 address in the DNS database; AAAA [Thomson, 1995] and A6
[Crawford, 2000] . AAAA has been used for IPv6 network operation since
1996. Questions arose whether we really need A6 or not, or whether it
is really possible to migrate to A6 or not. Some says AAAA is enough
and A6 is not necessary. Some says A6 is necessary and AAAA should get
deprecated.
The draft tries to understand pros and cons between these two record
types, and makes suggestions on deployment of IPv6 record type.
The draft does not cover the use of bit string label and DNAME resource
record (reverse mapping), as it seems that nibble form is well accepted
in the community, newer formats have too much deployment costs, thus we
see few need/voice that calls for migration. Refer to IETF50 dnsext
working group minutes for more details.
HAGINO Expires: January 19, 2002 [Page 1]
DRAFT Comparison of AAAA and A6 July 2001
1. A brief summary of the IPv6 resource record types
1.1. AAAA record
AAAA resource record is formatted as follows. DNS record type value for
AAAA is 28 (assigned by IANA). Note that AAAA record is formatted as a
fixed-length data.
+------------+
|IPv6 Address|
| (16 octets)|
+------------+
With AAAA, we can define DNS records for IPv6 address resolution as
follows, just like A records for IPv4.
$ORIGIN X.EXAMPLE.
N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
1.2. A6 record
A6 resource record is formatted as follows. DNS record type value for
A6 is 38 (assigned by IANA). Note that A6 record is formatted as a
variable-length data.
+-----------+------------------+-------------------+
|Prefix len.| Address suffix | Prefix name |
| (1 octet) | (0..16 octets) | (0..255 octets) |
+-----------+------------------+-------------------+
With A6, it is possible to define an IPv6 address by using multiple DNS
records. Here is an example taken from RFC2874:
HAGINO Expires: January 19, 2002 [Page 2]
DRAFT Comparison of AAAA and A6 July 2001
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
SUBNET-1.IP6 A6 48 0:0:0:1:: IP6
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.A.NET.
IP6 A6 48 0::0 SUBSCRIBER-X.IP6.B.NET.
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
B-NET.IP6.E.NET. A6 32 0:0:EB00:: E.NET.ALPHA-TLA.ORG.
C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
If we translate the above into AAAA records, it will be as follows:
$ORIGIN X.EXAMPLE.
N AAAA 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
N AAAA 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
N AAAA 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
It is also possible to use A6 records in ``non-fragmented'' manner, like
below.
$ORIGIN X.EXAMPLE.
N A6 0 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
N A6 0 2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
N A6 0 2345:000E:EB22:0001:1234:5678:9ABC:DEF0
There is a large design difference between A6 and AAAA. A6 imposes
address resolutions tasks more to the resolver side, to reduce the
amount of zone file maintenance cost. The complexity is in the resolver
side. AAAA asks zone file maintainers to supply the full 128bit IPv6
address in one record, and the resolver side can be implemented very
simple.
2. Deployment status
2.1. Name servers/resolvers
As of writing, AAAA is deployed pretty widely. BIND4 (since 4.9.4),
BIND8, BIND9 and other implementations support AAAA, as both DNS servers
and as resolver libraries. On the contrary, the author knows of only
one DNS server/resolver implementation that supports A6; BIND9.
HAGINO Expires: January 19, 2002 [Page 3]
DRAFT Comparison of AAAA and A6 July 2001
Almost all of the IPv6-ready operating systems ship with BIND4 or BIND8
resolver library. [need to check situations with resolver libraries
based on non-BIND code] Therefore, they cannot query A6 records (unless
applications gets linked with BIND9 libraries explicitly).
2.2. IPv6 network
IPv6 network has been deployed widely since 1996. Though many of the
participants consider it to be experimental, commercial IPv6 services
has been deployed since around 1999, especially in Asian countries.
Even today, there are numerous IPv6 networks operated just as serious as
IPv4.
2.3. DNS database
There are no IPv6-reachable root DNS servers, partly because we have
both AAAA and A6, and we are not decided about which is the one we would
like to really deploy (so we cannot put IPv6 root NS records). The lack
of IPv6-reachable root DNS servers is now preventing IPv6-only or
IPv4/v6 dual stack network operations.
At this moment, very small number of ccTLD registries accept
registeration requests for IPv6 glue records. Many of the ccTLDs and
gTLDs do not take IPv6 glue records, partly because of the lack of
consensus between AAAA and A6. Again, the lack of IPv6 glue records is
causing pain in IPv6-ready network operations. For example, JP ccTLD
accepts IPv6 glue records and registers them as AAAA records. IPv6 NS
records (with AAAA) works flawlessly from our experiences. For example,
try the following commands to see how JP ccTLD registers IPv6 glue
records (``/e'' is for English-language output):
% whois -h whois.nic.ad.jp wide.ad.jp/e
% whois -h whois.nic.ad.jp ns1.v6.wide.ad.jp/e
3. Deploying DNS records
At this moment, the following four strategies are proposed for the
deployment of IPv6 DNS resource record; AAAA, fragmented A6 records,
non-fragmented A6 records, and AAAA synthesis.
3.1. AAAA records
AAAA records have been used on IPv6 network (also known as 6bone) since
it has started in 1996 and has been working just fine ever since. AAAA
record is a straight extension of A record; it needs a single query-
response roundtrip to resolve a name into an IPv6 address.
A6 was proposed to add network renumbering friendliness to AAAA. With
AAAA, a full 128bit IPv6 address needs to be supplied in a DNS resource
record. Therefore, in the event of network renumber, administrators
need to update the whole DNS zone file with the new IPv6 address
HAGINO Expires: January 19, 2002 [Page 4]
DRAFT Comparison of AAAA and A6 July 2001
prefixes. We will discuss the issues with renumbering in a dedicated
section.
3.2. Fragmented A6 records
If we are to use fragmented A6s (128bit splitted into multiple A6s), we
have a lot of issues/worries.
If we are to resolve IPv6 addresses using fragmented A6 records, we need
to query DNS multiple times to resolve a single DNS name into an IPv6
address. Since there has been no DNS record types that require multiple
queries for resolution of the address itself, we have very little
experience on such resource records.
There will be more delays in name resolution compared to queries to
A/AAAA records. If we define a record with more number of fragments,
there will be more query roundtrips. There are only few possibilities
to query fragments in parallel. In the above example, we can resolve
A.NET.IP6.C.NET and A.NET.IP6.D.NET in parallel, but not others.
At this moment, there is very little documents available, regarding to
the relationship between DNS record TTL and the query delays. For
example, if the DNS record TTL is smaller than the communication delays
between the querier and the DNS servers, what should happen?
o If we compute DNS record TTL based on the wallclock on the DNS server
side, the DNS records are already expired and the querier will not be
able to reassemble a complete IPv6 record. Worse, by setting up
records with very low TTL, we can let recursive DNS resolvers to go
into infinite loop by letting them chase a wrong A6 chain (see the
section on security considration) [BIND 9.2.0snap: resolver does not
go into infinite loop, meaning that BIND 9.2.0snap resolver does not
really honor DNS record TTL during A6 reassembly].
o If we compute it starting from the time the querier got the record, we
will have some jitter in TTL computation among multiple queriers. If
the query delays are long enough, the querier would end up having
inconsistent A6 fragments, and the IPv6 address can be bogus after
reassembly. With record types other than A6, we had no such problem,
since we have never tried to reassemble an address out of multiple DNS
records (with CNAME chain chasing a similar problem can arise, but the
failure mode is much simpler to diagnose as the records are considered
as an atomic entity).
Some says that caches will avoid querying fragmented A6s again and
again. However, most of the library resolver implementations do not
cache anything. The traffic between library resolver and the first-hop
nameserver will not be decreased by the cached records. The TTL problem
(see above) is unavoidable for the library resolver without cache. [XXX
will they interpret TTL field? BIND8 resolver does not]
HAGINO Expires: January 19, 2002 [Page 5]
DRAFT Comparison of AAAA and A6 July 2001
If some of the fragments are DNSSEC-signed and some are not, how should
we treat that address? RFC2874 section 6 briefly talks about it, not
sure if complete answer is given.
It is much harder to implement A6 fragment reassemble code, than to
implement AAAA record resolver. AAAA record resolver can be implemented
as a straight extension of A record resolver.
o It is much harder to design timeout handling for the A6 reassembly.
There would be multiple timeout parameters, including (1) communcation
timeout for a single A6 fragment, (2) communcation timeout for the
IPv6 address itself (total time needed for reassembly) and (3) TTL
timeout for A6 fragment records.
o In the case of library resolver implementation, it is harder to deal
with exceptions (signals in UNIX case) for the large code fragment for
resolvers.
o When A6 prefix length field is not multiple of 8, address suffix
portion needs to be shifted bitwise while A6 fragments are
reassembled. Also, resolver implementations must be careful about
overwraps of the bits. From our implementatation experiences, the
logic gets very complex and we (unfortunately) expect to see a lot of
security-critical bugs in the future.
In RFC2874, a suggestion is made to use limited number of fragments per
an IPv6 address. However, there is no protocol limitation defined. The
lack makes it easier for malicious parties to impose DoS attacks using
lots of A6 fragments (see the section on security consideration). [BIND
9.2.0snap: The implementation limits the number of fragments within an
A6 chain to be smaller than 16; It is not a protocol limitation but an
implementation choice. Not sure if it is the right choice or not]
With fragmented A6 records, in multi-prefix network configuration, it is
not possible for us to limit the address on the DNS database to the
specific set of records, like for load distribution purposes. Consider
the following example. Even if we would like to advertise only
2345:00D2:DA11:1:1234:5678:9ABC:DEF0 for N.X.EXAMPLE, it is not possible
to do so. It becomes mandatory for us to define the whole IPv6 address
by using ``A6 0'' for N.X.EXAMPLE, and in effect, the benefit of A6
(renumber friendliness) goes away.
HAGINO Expires: January 19, 2002 [Page 6]
DRAFT Comparison of AAAA and A6 July 2001
; with the following record we would advertise both records
$ORIGIN X.EXAMPLE.
N A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6
SUBNET-1.IP6 A6 0 2345:00C1:CA11:1::
A6 0 2345:00D2:DA11:1::
; we need to do the following, jeopardizing renumbering
; friendliness for N.X.EXAMPLE
$ORIGIN X.EXAMPLE.
N A6 0 2345:00C1:CA11:1:1234:5678:9ABC:DEF0
M A6 64 ::2345:2345:2345:2345 SUBNET-1.IP6
SUBNET-1.IP6 A6 0 2345:00C1:CA11:1::
A6 0 2345:00D2:DA11:1::
A6 resource record type and A6 fragment/reassembly were introduced to
help administrators on network renumber. When network gets renumbered,
the administrator needs to update A6 fragment for the higher address
bits (prefixes) only. Again, we will discuss the issues with
renumbering in a dedicated section.
3.3. Non-fragmented A6 records
There are proposals to use non-fragmented A6 records in most of the
places, like ``A6 0 <128bit>'', so that we would be able to switch to
fragmented A6 records when we find a need for A6.
>From the packet format point of view, the approach has no benefit
against AAAA. Rather, there is a one-byte overhead to every
(unfragmented) A6 record compared to a AAAA record.
If the nameserver/resolver programs hardcode A6 processing to handle no
fragments, there will be no future possibility for us to introduce
fragmented A6 records. When there is no need for A6 reassembly, there
will be no code deployment, and even if the reassembly code gets
deployed they will not be tested enough. The author believes that the
``prepare for the future, use non-fragmented A6'' argument is not
worthwhile.
In the event of renumbering, non-fragmented A6 record has the same
property as AAAA (the whole zone file has to be updated).
3.4. AAAA synthesis (A6 and AAAA hybrid approach)
At this moment, end hosts support AAAA records only. Some people would
like to see A6 deployment in DNS databases even with the lack of end
hosts support. To workaround the deployment issues of A6, the following
approach is proposed in IETF50 dnsext working group slot. It is called
``AAAA synthesis'' [Austein, 2001] :
HAGINO Expires: January 19, 2002 [Page 7]
DRAFT Comparison of AAAA and A6 July 2001
o Deploy A6 DNS records worldwide. The proposal was not specific about
whether we would deploy fragmented A6 records, or non-fragmented A6
records (``A6 0'').
o When a host queries AAAA record to a DNS server, the DNS server
queries A6 fragments, reassemble it, and respond with a AAAA record.
The approach needs to be diagnosed/specified in far more detail. For
example, the following questions need to be answered:
o What is the DNS error code against AAAA querier, if the A6 reassembly
fails?
o What TTL should the synthesized AAAA record have? [BIND 9.2.0snap
uses TTL=0]
o Which nameserver should synthesize the AAAA record, in the DNS
recursize query chain? Is the synthesis mandatory for every DNS
server implementation?
o What should we do if the A6 reassembly takes too much time?
o What should we do about DNSSEC signatures?
o What if the resolver wants no synthesis? Do we want to have a flag
bit in DNS packet, to enable/disable AAAA synthesis?
o Relationships between A6 TTL, AAAA TTL, A6 query timeouts, AAAA query
timeouts, and other timeout parameters?
The approach seems to be vulnerable against DoS attacks, because the
nameserver reassembles A6 fragments on behalf of the AAAA querier. See
security consideration section for more details.
3.5. Issues in keeping both AAAA and A6
If we are to keep both AAAA and A6 records onto the worldwide DNS
database, it would impose more query delays to the client resolvers.
Suppose we have a dual-stack host implementation. If they need to
resolve a name into addresses, the node would need to query in the
following order (in the order which RFC2874 suggests):
o Query A6 records, and get full IPv6 addresses by chasing and
reassembling A6 fragment chain.
o Query AAAA records.
o Query A records.
o Sort the result based on destination address ordering rule. An
example of the ordering rule is presented as a draft [Draves, 2001] .
HAGINO Expires: January 19, 2002 [Page 8]
DRAFT Comparison of AAAA and A6 July 2001
o Contact the destination addresses in sequence.
The ordering imposes additional delays to the resolvers. The above
ordering would be necessary for all approaches that use A6, as there are
existing AAAA records in the world.
4. Network renumbering
Some says that there will be more frequent renumbers in IPv6 network
operation, and A6 is necessary to reduce the zone modification cost as
well as zone signing costs on renumber operation.
It is not clear if we really want to renumber that frequently. With
IPv6, it should be easier for ISPs to assign addresses statically to the
downstream customers, rather than dynamically like we do in IPv4 dialup
connectivity today. If ISPs do assign static IPv6 address block to the
customers, there is no need to renumber customer network that frequently
(unless the customer decides to switch the upstream ISPs that often).
NOTE: Roaming dialup users, like those who carry laptop computers
worldwide, seems to have a different issue from stationary dialup users.
See [Hagino, 2000] for more discussions.
It is questionable if it is possible to renumber IPv6 networks more
frequently than with IPv4. Router renumbering protocol [Crawford, 2000]
, IPv6 host autoconfiguration and IPv6 address lifetime [Thomson, 1998]
can help us renumber the IPv6 network, however, network renumbering
itself is not an easy task. If you would like to maintain reachability
from the outside world, a site administrator needs to carefully
coordinate site renumber. The minimal interval between renumber is
restricted by DNS record timeouts, as DNS records will be cached around
the world. If the TTL of DNS records are X, the interval between
renumber must be longer than 2 * X. If we consider clients/servers that
tries to validate addresses using reverse lookups, we also need to care
about the relationship between IPv6 address lifetime [Thomson, 1998] and
the interval between renumber. At IETF50 ipngwg session, there was a
presentation by JINMEI Tatsuya regarding to site renumbering experiment.
It is recommend to read through the IETF49 minutes and slides. [XXX
Fred Baker had a draft on this - where?] For the network renumbering to
be successful, no configuration files should have hardcoded (numeric) IP
addresses. It is a very hard requirement to meet. We fail to satisfy
this in many of the network renumbering events, and the failure causes a
lot of troubles.
At this moment there is no mechanism defined for ISPs to renumber
downstream customers at will. Even though it may sound interesting for
ISPs, it would cause a lot of (social and political) issues in doing so,
so the author would say it is rather unrealistic to pursue this route.
The only possible candidate, router renumbering protocol [Crawford,
2000] does not really fit into the situation. The protocol is defined
using IPsec authentication over site-local multicast packets. It would
be cumbersome to run router renumbering protocol across multiple
HAGINO Expires: January 19, 2002 [Page 9]
DRAFT Comparison of AAAA and A6 July 2001
administrative domains, as (1) customers will not want to share IPsec
authentication key for routers with the upstream ISP, and (2) customer
network will be administered as a separate site from the upstream ISP
(Even though router renumbering protocol could be used with unicast
addresess, it is not realistic to assume that we can maintain the list
of IPv6 addresses for all the routers in both customers' and ISPs'
networks).
A6 was designed to help administators update zone files during network
renumbering events. Even with AAAA, zone file modification itself is
easy; you can just query-replace the addresses in the zone files. The
difficulty of network renumber comes from elsewhere.
With AAAA, we need to sign the whole zone again with DNSSEC keys, after
renumbering the network. With A6, we need to sign upper bits only with
DNSSEC keys. Therefore, A6 will impose less zone signing cost on the
event of network renumbering. As seen above, it is questionable if we
renumber network that often, so it is questionable if A6 brings us an
overall benefit. Note, however, even if we use A6 to facilitate more
frequent renumbering and lower signing cost, all glue records has to be
installed as non-fragmented A6 records (``A6 0''), and required to be
signed again on renumbering events.
5. Security consideration
There are a couple of security worries mentioned in the above. To give
a brief summary:
o There will be a higher delay imposed by query/reply roundtrips for
fragmented A6 records. This could affect every services that relies
upon DNS records.
o There is no upper limit defined for the number of A6 fragments for
defining an IPv6 address. Malicious parties may try to put a very
complex A6 chains and confuse nameservers worldwide.
o A6 resolver/nameserver is much harder to implement correctly than AAAA
resolver/nameserver. A6 fragment reassembly code needs to take care
of bitwise data reassembly, bitwise overwrap checks, and others. From
our implementatation experiences, we expect to see a lot of security-
issue bugs in the future.
o Interaction between DNS record TTL and the DNS query delays leads to
non-trivial timeout problem.
We would like to go into more details for some of these.
5.1. DoS attacks against AAAA synthesis
When a DNS server is configured for AAAA synthesis, malicious parties
can impose DoS attacks using the interaction between DNS TTL and query
HAGINO Expires: January 19, 2002 [Page 10]
DRAFT Comparison of AAAA and A6 July 2001
delays. The attack can chew CPU time and/or memory, as well as some
network bandwidth on a victim nameserver, by the following steps:
o A bad guy configures a record with very complex A6 chain, onto some
nameservers. (the bad guy has to have controls over the servers).
The nameservers can be located anywhere in the world. The A6 chain
should have a very low TTL (like 1 or 0 seconds). The attack works
better if we have higher delays between the victim nameservers and the
nameservers that serve A6 fragments.
o The bad guy queries the record using AAAA request, to the victim
nameserver.
o The victim nameserver will try to reassemble A6 fragments. During the
reassembly process, the victim nameserver puts A6 fragments into the
local cache. The cached records will expire during the reassembly
process. The nameserver will need to query a lot of A6 fragments
(more traffic). The server can go into an infinite loop, if it tries
to query the expired A6 fragments again.
Note, however, this problem could be considered as a problem in
recursize resolvers in general (like CNAME and NS chasing); A6 and AAAA
synthesis makes the problem more apparent, and more complex to diagnose.
To remedy this problem, we have a couple of solutions:
(1) Deprecate A6 and deploy AAAA worldwide. If we do not have A6, the
problem goes away.
(2) Even if we use A6, do not configure nameservers for AAAA synthesis.
Deployment issues with existing IPv6 hosts get much harder.
(3) Impose a protocol limitation to the number of A6 fragments.
(4) Do not query the expired records in A6 chain again. In other words,
implement resolvers that ignore TTL on DNS records. Not sure if it
is the right thing to do.
6. Conclusion
NOTE: the section expresses the impressions of the author.
A6/AAAA discussion has been an obstacle for IPv6 deployment, as the
deployment of IPv6 NS recodrs have been deferred because of the
discussion. The author do not see benefit in keeping both AAAA and A6
records, as it imposes more query delays to the clients. So the author
believes that we need to pick one of them.
Given the unlikeliness of frequent network renumbering, the author
believes that the A6's benefit in lower zone signing cost is not
significant. The benefit of A6 (in zone signing cost) is much less than
HAGINO Expires: January 19, 2002 [Page 11]
DRAFT Comparison of AAAA and A6 July 2001
the expected complication that will be imposed by A6 operations.
>From the above discussions, the author suggests to keep AAAA and
deprecate A6 (move A6 document to historic state). The author believes
that A6 can cause a lot of problem than the benefits it may have. A6
will make IPv6 DNS operation more complicated and vulnerable to attacks.
AAAA is proven to work right in our IPv6 network operation since 1996.
AAAA has been working just fine in existing IPv6 networks, and the
author believes that it will in the coming days.
References
Thomson, 1995.
S. Thomson and C. Huitema, "DNS Extensions to support IP version 6" in
RFC1886 (December 1995). ftp://ftp.isi.edu/in-notes/rfc1886.txt.
Crawford, 2000.
M. Crawford, C. Huitema, and S. Thomson, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering" in RFC2874 (July 2000).
ftp://ftp.isi.edu/in-notes/rfc2874.txt.
Austein, 2001.
R. Austein, "Tradeoffs in DNS support for IPv6" in draft-ietf-dnsext-
ipv6-dns-tradeoffs-00.txt (July 2001). work in progress material.
Draves, 2001.
Richard Draves, "Default Address Selection for IPv6" in draft-ietf-
ipngwg-default-addr-select-04.txt (May 2001). work in progress material.
Hagino, 2000.
Jun-ichiro Hagino and Kazu Yamamoto, "Requirements for IPv6 dialup PPP
operation" in draft-itojun-ipv6-dialup-requirement-00.txt (July 2000).
work in progress material.
Crawford, 2000.
Matt Crawford, "Router Renumbering for IPv6" in RFC2894 (August 2000).
ftp://ftp.isi.edu/in-notes/rfc2894.txt.
Thomson, 1998.
S. Thomson and T. Narten, "IPv6 Stateless Address Autoconfiguration" in
RFC2462 (December 1998). ftp://ftp.isi.edu/in-notes/rfc2462.txt.
Change history
none.
HAGINO Expires: January 19, 2002 [Page 12]
DRAFT Comparison of AAAA and A6 July 2001
Acknowledgements
The draft was written based on discussions in IETF IPv6 and dnsext
working groups, and help from WIDE research group.
Author's address
Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho,
Chiyoda-ku,Tokyo 101-0054, JAPAN
Tel: +81-3-5259-6350
Fax: +81-3-5259-6351
Email: itojun@iijlab.net
HAGINO Expires: January 19, 2002 [Page 13]