> this part i don't really understand. if we advocate "A6 0
<128bit>"
> there will be resolver implementation that does not chase A6
chains
> at all (like for cellphones or whatever). if there's no need,
> there'll be no code. then, there will be no possibility for "A6
> <non-zero> <less-than-128bit> <chain>". so I don't really see
> benefit
> of "A6 0 <128bit>" than "AAAA".
I think we have to delineate the various motivation and arguments: we
want A6 to facilitate site renumbering and site multi-homing, while
reducing the rate of DNS update; we also want to avoid harmful effects
on the DNS resolution.
The motivation for A6 is still valid; no new argument there, I believe
it will be a great tool for network managers. There have been two
questions on its use, the linkage with the address allocation and the
depth of the hierarchy. The short answer to address allocation is router
advertisement; the short answer to the depth of the hierarchy is that a
depth of 1 is probably adequate to show significant benefits.
The motivation for using "A6 0 <128bit>" is the use of A6 during the
name resolution process, especially at the top level. We don't want root
servers spending their time chasing A6 chains, and we also don't want
the extra-load on root servers that could be caused by clients chasing
A6 chains. This means that the address records of name servers will have
to be explicitly updated when a site is renumbered. I believe that this
is a reasonable compromise; without A6 one would have to update all the
records; with the initial design we aimed at updating exactly one record
per site; with the compromise one would update a few records only.
We definitely need to gather operational experience. For example, an
assumption in the design of A6 is that the higher level of the hierarchy
will be very likely to be cached; whether this is true or false is easy
to measure after a modicum of deployment. Another assumption is that the
nodes can automatically update their addresses, and that the update
process can be synchronized with the DNS updates; this can indeed also
be tested. And, once we are done testing, we should document the
results.
Note that RFC 2874 packs together the use of A6 for name to IPv6 address
resolution, and the use of binary labels and DNAME for the IPv6 address
to name translation. When we conduct the evaluation, it may be useful to
separate the three points: A6, discussed above, DNAME, which has its own
set of benefits and issues, and binary labels, which is clearly an
extension to the core DNS name resolution mechanism.
-- Christian Huitema
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
