Re: (ngtrans) Joint DNSEXT & NGTRANS summary

[Johan Ihren <johani@autonomica.se>]

Bill Manning <bmanning@ISI.EDU> writes:

> % 
> % On Tue, Aug 14, 2001 at 03:24:30AM -0700, Bill Manning wrote:
> % >% I think that such evolution will quickly move from the realm of clear
> % >% possibilities to "things that simply will not happen" as the base of
> % >% resolvers that serve AAAA clients but doesn't do AAAA synthesis grows.
> % >
> % >	Lets see, pretty much every resolver "shipped" since 1996
> % >	has AAAA support but does not do A4synth. One could infer
> % >	that this is a fairly large base.
> % 
> % A large base of software that handles AAAA, but not necessarily a
> % large base of DNS administrators using AAAA records.
> 
> 	Note that Joahn mentioned resolvers and I followed up 
> 	on that idea. You introduce Humans in the form of sysadmins.

Oops. Let's be careful with our terminology. 

"Resolver", to me, denotes a full-service DNS client, like the part of
a recursive server that does lookups, and possibly follows A6 chains
and such strange things.

"Stub resolver" denotes a bare-bones subset of the resolver that is
present as part of an application.

I've been exclusively discussing full-service resolvers, since I
believe that AAAA synthesis (in the local caching resolver aka name
server) is the right solution to (among other things) the problem of
*not* having to upgrade all the deployed and implemented *stub
resolvers*.

> % Probably the majority of sysadmins have not yet dealt with IPv6. When
> % they start, they will look to standards for guidance.  If we leave A6
> % on the standards track now, it will become natural to use A6. This can
> % drive deployment of resolvers which do AAAA synthesis.
> 
> 	Or they can use AAAA, also on the standards track.
> 	(this is the nub of the issue at hand, at least from here)
> 	Itojan (sp?) has an excellent draft on the experience
> 	of sysadmins who have used both AAAA and A6. The results
> 	are instructive.

...but it should be mentioned that many of the issues Itojun discusses
are relative to implementing A6 in *stub resolvers*, which is not what
I am arguing for.

Another part of the document decribes various (fully valid) worries
about timeouts and delays etc due to following long A6 chains that
extend beyond the organizational border into the unknown territory of
the ISP and beyond (above?).

I think that this is perhaps not the only perspective since a clueful
leaf node is not the main problem here.

A possibly more interesting perspective would be that of a clueful
central organisation with lots of delegated prefixes in various
directions. I also think that perspective is posibly more valid, since
statistically the amount of clue goes down as you move down the
delegation chain. 

The problem then becomes one of "how do I propagate this need to
change the prefix" recursively down all these delegations and into
whatever tools and scripts they have decided to use for zone
management and no longer even know how they work.

With A6 this particular sub-part of the renumbering problem becomes a
non-issue. Not so with AAAA. Not even close.

Johan