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

bind-3.2.

>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: [phone]
     Fax: [phone]
     Email: [e-mail]






































HAGINO                  Expires: January 19, 2002              [Page 13]