draft-ietf-dnsext-aaaa-a6-01.txt

bind-3.2.

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.