why A6 might be harder to deploy

[Bill Manning <bmanning@ISI.EDU>]

cc list trimed:

	A couple of other considerations:

	After IETF49, we held a ws that ran DNS on v6 transport.  We tried
	A6 & AAAA records in the context of the DNS root. Dales notes reflect
	that FreeBSD's resolver was unable to recognise an A6 record when it
	was "glue" for a root server.  It was able to recognise a AAAA record.
	This has not been rechecked to my knowledge.

	This is also applicable between the servers for a zone.  In a mixed
	environment, it is possible to have servers running a variety of
	code, from Bind4, Bind8, Bind9 and even some of the other genetic
	varients (Microsoft, Lucent, PowerDNS, Akami, et.al.)  Indeed, this
	is one of the strengths of the DNS.  And in such clusters, RR 28 
	is well known and is passed around. If an NS records "glue" is type
	28, zone transfers will occur.  

	However nearly none of these versions/varients knows or supports
	type 38.  And given the strict checking, for coherancy, in most
	of the recent code, if the glue for an NS is type 38, the zone
	transfer will -fail-

	That seems to indicate that if type 38 is to be used, all the servers
	for the zone in which they reside must be running code from a single
	branch. (the unknown RR type problem) 

	And there are indications that that particular branch is not all
	that speedy.  Some numbers I have seen indicate the QPS rate is
	about 50% less than the previous branch.  Are we really ready to
	take that performance hit to gain A6 support?

Random idea...

	Presume 10,000 v6 users today. If we give them AAAA now, and 
	agressively explore/test A6, on the experimental track for 12-18
	months, we might presume there would be 1,000,000 v6 users by 
	then.  That is still statistically "small" as an installed base
	and we would have a much stronger case that A6 performance issues
	are addressed, A4synth could be better understood, and operational
	tools are available.  If we put forth the effort, it should be 
	a no brainer to push it back on stds track and consider moving
	AAAA to historic (sort of like RIPv1 is historic... people still
	build it and use it. :)
	
	The installed base is still small enough that we can make the 
	change... I think.

--bill