Subject: RE: (ngtrans) Joint DNSEXT & NGTRANS summary

From: "Christian Huitema" <[email-masked]>
Date: Thu, 9 Aug 2001 01:31:28 -0700

Paul,
 
Just for the record -- Microsoft as a corporation did not try to sway this issue one way or the other; individual IETF contributors who happen to work for Microsoft have various opinions in this debate. OTOH, we are shipping software, and we would really want the debate to be resolved very soon.
 
-- Christian Huitema 

	-----Original Message----- 
	From: Paul A Vixie [mailto:[email-masked]] 
	Sent: Tue 8/7/2001 9:00 AM 
	To: Alexis Yushin 
	Cc: James Aldridge; Jim Bound; Matt Crawford; [email-masked]; [email-masked]; [email-masked]; [email-masked] 
	Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary 

	> I see a big difference between deprecating/moving to historic and changing
	> status to experimental. Experemental implies further development.
	
	I don't see that difference here.  Just as "let's let the market decide"
	really just means "let's do whatever Microsoft wants", so it is that "let's
	make it experimental" really just means "let's move on."  (I find it amusing
	that SRV was experimental but that Microsoft's use of it pulled it forward.)
	
	I was not able to be in London, but had I been there my comments would've been:
	
	        Let's not expect stub resolvers to do the caching necessary to
	        understand either A6 or SIG/KEY -- those are things which servers
	        ought to use to talk to other servers.  Stub resolvers making
	        recursive requests of their name servers should be using AAAA and
	        TSIG.  AAAA synthesis of underlying A6, and TSIG to protect
	        verified KEY/SIG data for the last mile, is all a client needs.
	        Every argument against SIG/KEY or against A6 comes down to either
	        the caching problem or the complexity problem, and if we insulate
	        the end-stations from those problems, the arguments are reduced to
	        things which authority-side tools can be made to cope with.
	
	Hopefully this point was made by somebody.

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Aug 2001 16:16:12 +0700

Date:        Thu, 9 Aug 2001 01:31:28 -0700
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Just for the record -- Microsoft as a corporation did not try to sway
  | this issue one way or the other;

That wasn't the way I read Paul's comment - I read it more as suggesting
that if the IETF doesn't pick one way or the other, and completely
stamp out the other (ie: if one gets marked as experimental, or if both
get left as PS), then you (Microsoft) will just pick whichever one that
appeals to you most, and that will effectively set the standard,
regardless of what any of the rest of us think later.

I suspect that's half right - what microsoft put in their clients would
only matter if they start doing A6 lookups - if they just do AAAA, then
AAAA synthesis can allow A6 deployment to work just fine.

I'm less convinced about the power of microsoft to sway the world via
the server behaviour.

The one thing that is pretty clear, is that if microsoft clients start
doing A6 queries to find IPv6 addresses, then it is A6 that the world will
deploy (we won't be synthesising A6 records out of AAAA, while possible,
that makes no sense at all).

kre

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 09 Aug 2001 18:22:52 +0900

>AAAA synthesis can allow A6 deployment to work just fine.

	as I repeatedly commented, AAAA synthesis does not really work in the
	wild due to the deployment hurdles and ambiguity as to who is going
	to synthesize.

itojun

---

From: Robert Elz <[email-masked]>
Date: Thu, 09 Aug 2001 16:41:41 +0700

Date:        Thu, 09 Aug 2001 18:22:52 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	as I repeatedly commented, AAAA synthesis does not really work in the
  | 	wild due to the deployment hurdles and ambiguity as to who is going
  | 	to synthesize.

There's no ambiguity.   It gets done at your local resolver/cache.

For deployment, yes, to make use of A6 lookups code is going to need to
be deployed - if that means just that it is required that you deploy a
back end resolver that understands A6 and AAAA synthesis, then that seems
like a fairly easy upgrade path (much easier than if all the clients had
to be upgraded).

And yes, as you have pointed out, if the local back end resolver doesn't
understand A6, and AAAA synthesis, then AAAA queries will still get
transmitted to the rest of the net.  In the short term, the existing AAAA
records can just be returned, that's the first step of transition.
But it also does no great harm if some other server does AAAA synthesis
on your behalf (you'll have no good way to verify the data, but the chances
are that you wouldn't be bothering even if you had).

kre

---

From: Dancer Vesperman <[email-masked]>
Date: Fri, 10 Aug 2001 04:05:17 +1000

> 	really just means "let's do whatever Microsoft wants", so it is that "let's

I think what Paul meant was an invocation of the Golden Rule of Arts and 
Sciences ("He who has the gold, makes the rules" for those not versed in 
the classics). There's probably no need to wave loaded disclaimers 
around where they might go off, and injure a bystander :)

Microsoft's name (rightly or wrongly) is commonly substituted by those 
in the halls of Information Technology for any amoral, monopolising 
concern or manufacturer of low-quality merchandise. It is not at all 
unusual (in my personal experience) to hear a shoddy telecommunications 
provider, or a Harmful Products Manufacturer(tm) referred to as 'A 
Microsoft' or 'A Microsoft Subsidiary'. Oh, well. I guess any publicity 
is good publicity...Or at least that's what I've heard Marketing say. :)

D

---

From: "D. J. Bernstein" <[email-masked]>
Date: 9 Aug 2001 19:50:55 -0000

Robert Elz writes:
> if microsoft clients start doing A6 queries to find IPv6 addresses,
> then it is A6 that the world will deploy

Do you mean that they'll look for A6 and _not_ AAAA? If so, they'll cut
themselves off from practically the entire IPv6 network: administrators
provide addresses as AAAA, not A6.

Or do you mean that they'll look for A6 _and_ AAAA? If so, how does that
motivate administrators to switch to A6? Administrators who switch will
cut themselves off from all the other clients that look only for AAAA.

Or are you talking about an imaginary world in which AAAA and A6 are
both starting from scratch?

---Dan

---

From: Robert Elz <[email-masked]>
Date: Fri, 10 Aug 2001 13:23:30 +0700

Date:        9 Aug 2001 19:50:55 -0000
    From:        "D. J. Bernstein" <[email-masked]>
    Message-ID:  <[email-masked]>

This is a pointless exercise, but anyway...

  | Do you mean that they'll look for A6 and _not_ AAAA?

I meant if they did that - I'm not expecting it to be very likely.

  | If so, they'll cut themselves off from practically the entire IPv6
  | network: administrators provide addresses as AAAA, not A6.

Some now do both..   but they wouldn't, the point of the original
comment was that whatever the dominant market share does, everyone
else is forced to follow.   If 90% of the clients happened to be
doing A6 lookups, then administrators would be providing A6 records.

kre

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 9 Aug 2001 20:14:18 -0700 (PDT)

> regardless of what any of the rest of us think later.

I believe that it was Pogo that said:

              "We have met the enemy... and it is us."

Rather than worrying so much about what this or that company might do, the
IETF might better spend its time and energy making clear decisions within
a reasonable timeframe.

Most IPv6 implementors will need to make a decision on how to handle
AAAA/A6 in the next 6 months.  Without guidance from the IETF, history
suggests that they will each make the decision based on their own
analysis, and then once having shipped, less flexibility will be
available in order to accomodate the installed base. 

We've already gone down this road with IKE -- where the most  basic
VPN scenarios do not interoperate. 

In many cases "no decision" is actually the worst possible decision.

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 13 Aug 2001 18:45:26 -0700

Well I told the other chairs to let the discussion on this 
thread continue through today as a mechanism to allow 
consensus to emerge, and then I would step up and try to 
summarize. As Matt noted in originating the thread there was 
no absolutely overwhelming position by those in the room in 
London, but to a degree that really doesn't matter. What 
matters is the position of those participating in the mail 
lists. What the question in London did was allow the chairs 
and IESG observers to gauge the distinction between a few 
very loud voices vs. a broad based level of support, and 
gauge how many had a willingness to express an opinion on 
the subject (which from what I could tell was everyone). 

Nathan and Bernard have a good start to the summary, in 
terms of boiling down the essential viewpoints. The things 
I would add from the discussion include:

- It is clear that we know how to make A6 resolvers deal with 
  AAAA clients.
- It appears that with current tools A6 reduces the burden of 
  renumbering on the zone administrator.
- It is not clear that renumbering will occur faster than a 
  AAAA zone file could be resigned.
- It is clear that we could evolve from AAAA to A6 later if 
  it became necessary.

Additionally:
- It is clear that on either path we need better tools for
  DNS management. 
- It is also clear that address renumbering can't be solved 
  simply through DNS magic.

Shortly, an Internet-Draft will be sent to the lists that 
describes the rough consensus (possibly very rough) of the 
joint group and recommends a course of action to the IESG. 
For this reason it would be inappropriate for the IESG to be 
asked to arbitrate the creation of a recommendation to 
themselves. While the WG chairs are listed as authors, it is 
still an I-D subject to comment and editing like any other. 
If you feel the positions presented in the draft do not 
represent the collective working group opinion, speak up. 

Tony 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Nathan Jones
Sent: Sunday, August 12, 2001 9:02 PM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

A6 supporters have spent a lot of time promoting flexibility, arguing
that we shouldn't limit our options because of fear of what might
happen.

AAAA supporters have spent a lot of time telling us that such
flexibility is not required and that possible A6 implementation
problems can't be fixed just by making recommendations for DNS
administrators.

The debate has gone on and on, but no consensus has been reached.
(I don't consider hums at London's meeting to be consensus.)
Is there merit in asking the Area Directors (or possibly the IESG)
for arbitration?

--
nathanj

Matt Crawford wrote:
>Here's the problem.  There was no attempt at consenus *building* after
>the discussion, only a quick measurement of opinions at that point.

>In many cases "no decision" is actually the worst possible decision.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "D. J. Bernstein" <[email-masked]>
Date: 14 Aug 2001 02:38:06 -0000

I have a DNS server, a DNS cache, and a DNS client library. Current
situation:

   (1) The server talks to caches only through IPv4. It can provide AAAA
       and ip6.int records, as per RFC 1123 section 6.1.3.5, but the
       input format is not as streamlined as the input format for A and
       in-addr.arpa.

   (2) The cache talks to servers and clients only through IPv4. It can
       forward AAAA records, as per RFC 1123 section 6.1.3.5, but it
       does not use them to locate servers.

   (3) The client library talks to caches only through IPv4. It doesn't
       include any functions related to IPv6 addresses.

Plans:

   (1) Server: Talk to caches through IPv6. Include streamlined syntax
       to generate AAAA/ip6.int.

   (2) Cache: Talk to servers and clients through IPv6. Use AAAA records
       to locate servers.

   (3) Client library: Talk to caches through IPv6. Incorporate AAAA
       lookups, falling back to A. Incorporate ip6.int lookups.

Things that I do _not_ plan to do:

   (1) A6, DNAME, bit labels, and ip6.arpa in the server.

   (2) A6, DNAME, bit labels, and ip6.arpa in the cache.

   (3) A6, DNAME, bit labels, and ip6.arpa in the client library.

I want it to be crystal clear to the users that they have to set up AAAA
records and ip6.int. They can't expect to be reachable if they use A6 or
DNAME or ip6.arpa.

---Dan

---

From: Johan Ihren <[email-masked]>
Date: 14 Aug 2001 11:34:12 +0200

> - It is clear that we could evolve from AAAA to A6 later if 

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.

Today it would be easy, since the resolver base is small and mostly
based upon various versions of bind9 that will (all?) be upgraded to a
version with AAAA synthesis built in.

Tomorrow, with a large base of resolvers without that functionality,
anyone who attempts to move from AAAA to A6 will literaly saw off the
branch of the tree he is sitting on (from the perspective of AAAA
on-lookers on the ground).

On the other hand, I fully realize the issues with keeping a (mostly
unused) code-path of AAAA synthesis around in the resolvers with A6
not on the standards track. 

All I am saying is that I think any attempt att consensus through the
"we can always upgrade later" argument is bound to misfire.

Johan

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 14 Aug 2001 18:37:05 +0900

>version with AAAA synthesis built in.

	the observation seems misleading to me.  BIND4/8 happily serves AAAA
	client (over IPv4 UDP/TCP), therefore, the resolver base is already
	quite big for AAAA.

itojun

---

From: Bill Manning <[email-masked]>
Date: Tue, 14 Aug 2001 03:24:30 -0700 (PDT)

% > - It is clear that we could evolve from AAAA to A6 later if 
% >   it became necessary.
% 
% 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.

% Today it would be easy, since the resolver base is small and mostly
% based upon various versions of bind9 that will (all?) be upgraded to a
% version with AAAA synthesis built in.

	This is a much smaller base but might be growing... at least
	on the server side.  Of course, with the "genetic diversity"
	that is now present, we have a number of suppliers to consider.
	DJB has stated that he has no intention of supporting either
	A4synth or A6.  

% Tomorrow, with a large base of resolvers without that functionality,
% anyone who attempts to move from AAAA to A6 will literaly saw off the
% branch of the tree he is sitting on (from the perspective of AAAA
% on-lookers on the ground).

	True of the adoption of any new feature.

% All I am saying is that I think any attempt att consensus through the
% "we can always upgrade later" argument is bound to misfire.

	Hum... while using this arguement to try and reach consensus
	may be fraught with danger, the basic premise, that the Internet
	is evolutionary, e.g. "we can always upgrade later" is a 
	core concept in many peoples minds.  Revolutionary techniques,
	e.g. flag days, non-backward compatability, etc. are much harder
	to float past the "powers that be".  These days, such techniques
	tend to come from outside, and blindside the PTB, then we all 
	have to scramble to adapt/adopt. e.g. Netscape, RealNetworks,
	etc. come to mind.
% 
% Johan
% 

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Tue, 14 Aug 2001 06:10:33 -0700 (PDT)

% 
% 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.
	
% 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.
	
% By contrast, if we remove A6 from the standards track now, then there
% is no incentive to implement support for AAAA synthesis. If we then
% turn around and say "we do need A6 after all", there is little
% momentum to implement and deploy A6.

	Until it gets put back on the Standards track, like SRV.

% A6 is already on the standards track and people want to deprecate it before
% it has been given a chance. If the specification is not worthy, perhaps
% the "market" will decide to ignore it, but at least it is available. 

	Not depricate, move to a responsible track, for now.

% 
% --
% nathanj
% --------------------------------------------------------------------
% 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-masked]
% --------------------------------------------------------------------
% 

-- 
--bill

---

From: Johan Ihren <[email-masked]>
Date: 14 Aug 2001 15:27:04 +0200

> 	client (over IPv4 UDP/TCP), therefore, the resolver base is already

Ahem. Let me put it this way:

If we look at DNS configuration for the v6 part of the world it is at
present based upon various kinds of ugliness to get around the fact
that there is almost no hierarchy deployed over v6 transport (starting
with the lack of roots accessible over v6 transport). 

The most common is to use a forwarding configuration to escape over to
the v4 transport universe with full DNS connectivity.

*All* this will have to change over the coming years if or when or
wherever we decide to start deploying roots accessible over v6
transport.

So, regardless of whether the present numbers of deployed resolvers is
large or small (I think it is small compared to what we hope to have
in three years, you think it is large compared to what we had three
years ago, both positions are fine) it is still not a problem since
their configurations will all change when v6 roots appear.

However, the point of v6 root deployment is the *only* time in IPv6
history that we will be able to make such a change (push a
configuration change like AAAA synthesis into all corners) which is
one of several reasons why we should be (and are) so very careful
before introducing v6 glue for the roots.

When I talked about experimental deployment of v6 roots during dnsop
in Minneapolis I was clearly overly optimistic about the
timeframe. And while the A6 vs AAAA issue has been one reason for
delay it is not the only concern.

Johan

PS. On the other hand, I do understand your argument about old bind4/8
serving AAAA over v4 transport. And, yes, the consequence is that
clients on the IPv4 Internet will not find the AAAAddresses of
whatever they are trying to lookup. No one said this was easy. DS.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 14 Aug 2001 22:37:49 +0900

>wherever we decide to start deploying roots accessible over v6

	I don't get your argument at all.

	Because first part of the IPv6 transition will be toward IPv4/v6
	dual stack, AAAA over IPv4 transport works just fine for us.
	The history proves that it works fine for us - due to the lack of
	IPv6 accessible root, IPv6 accessible ccTLD/gTLD, and lack of IPv6
	NS record registration support by many of the registries, we IPv6
	users are forced to rely upon IPv4 DNS infrastructure.  Luckily,
	it works quite well.

	total transition to AAAA (or A6) over IPv6 transport is of course
	better, however, it needs a major upgrades, including:
	- IPv6-ready root
	- IPv6-ready ccTLD and gTLD
	- IPv6-ready random .com servers
	all of them needs to be done before the total transition, so it is
	unrealistic to talk about total transition this time.

	So, what I'm saying is, AAAA deployment is already so wide enough
	(all BIND4/8/9 do support them okay), and for me it is way too late
	already to transition to anything else (including A6).  If we are
	to transition to something other than AAAA, the transition needs to
	be coordinated very delicately, like transition from IPv4 to IPv6
	and it will take multiple years to do so.  We cannot wait any more.

	Think DNS transport issue (DNS over IPv6, or IPv4) and DNS payload
	issue (AAAA, A or A6) separately.  What we are talking about is
	mainly the payload issue, though, it affects the deployment of
	the IPv6 DNS transport (as NS records need to point to AAAA, or A6).
	I guess you are mixing up these two.

itojun

---

From: Robert Elz <[email-masked]>
Date: Tue, 14 Aug 2001 20:47:19 +0700

Date:        Tue, 14 Aug 2001 03:24:30 -0700 (PDT)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Hum... while using this arguement to try and reach consensus
  | 	may be fraught with danger, the basic premise, that the Internet
  | 	is evolutionary, e.g. "we can always upgrade later" is a 
  | 	core concept in many peoples minds.

It may be, but they're deluding themselves.

The only plausible argument now for ignoring A6, and persisting with
AAAA, is the current deployed base, and the difficulty of getting all
of it upgraded, and the desire to make IPv6 "real" as soon as possible.

If that's an argument to be listened to now, it can only possibly have
greater and greater force as time passes and AAAA is deployed more, and
used more, than the comparatively trivial amount it is now.

The comment in Tony Hain's message:

is not only not clear, it is simply wrong.   There's no way to change
such a basic part of the infrastructure once it is widely deployed.
No way at all.   (That is, unless "later" means next month, of course,
if it is soon enough, it would still be possible - that is, it needs
to happen while the 6bone is still the major long haul IPv6 net, once
we have enough real v6 users that we start getting v6 real v6 infrastructure,
then the time will have passed).

kre

---

From: Bill Manning <[email-masked]>
Date: Tue, 14 Aug 2001 07:16:37 -0700 (PDT)

%   | 	Hum... while using this arguement to try and reach consensus
%   | 	may be fraught with danger, the basic premise, that the Internet
%   | 	is evolutionary, e.g. "we can always upgrade later" is a 
%   | 	core concept in many peoples minds.
% 
% It may be, but they're deluding themselves.
% 
% kre

	Hogwash.  EGP -> BGP
		  RIP -> ISIS/OSPF
		  MB/MG -> MX

	All upgrades. Works a treat.  

	From this little corner of the world, things look like this:

	AAAA = stds track 
	A6   = stds track

	we can do the following:

	a) move one proposal somewhere else on the standards track
	b) Leave them where they are.

	For a), that would mean giving a nodding preference to one,
	based on some criteria. Certain people seem to be leaning 
	toward one selection based on operational experience, deployed
	code, and legitimate paranoia that the alternative is operationally
	problematic.
	For b) that leave the "market" to decide, leading to operationally
	problematic state on questionable interoperability.

	Because I beleive that A6 has enough potential, I'm willing 
	to have it move to experimental, giving developers and
	operators more time to understand its impact.  I think that
	long term, its benefits will overshadow AAAA and that a
	migration plan can be deployed.  But for now, it needs more
	work and AAAA meets todays limited requirements.
		
--bill

---

From: Johan Ihren <[email-masked]>
Date: 14 Aug 2001 16:17:41 +0200

> 	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*.

> 	of sysadmins who have used both AAAA and A6. The results

...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

---

From: Robert Elz <[email-masked]>
Date: Tue, 14 Aug 2001 21:48:55 +0700

Date:        Tue, 14 Aug 2001 07:16:37 -0700 (PDT)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Hogwash.  EGP -> BGP
  | 		  RIP -> ISIS/OSPF
  | 		  MB/MG -> MX
  | 
  | 	All upgrades. Works a treat.  

Hogwash.

I'm not exterior routing expert, but aren't EGP/BGP etc, essentially
bilateral relationships?   That is, as long as two peers agree on
what they use, no-one else really cares.   I'm sure the conversion
(so long ago I bet many people here don't recall EGP) wasn't quite
this easy, but it still doesn't involve unrelated paries all deciding
that it is time to start doing something different.

Interior routing protocols are something within the confines of one
organisation, and aren't even vaguelly similar.

The last one is the closest, except that MB/MG were never deployed,
and even now, mailers still fall back to using A records when there
is no MX record (that is, we have no way of indicating "no mail for
that domain" which is what we would have had had MX been deployed
from the start).  This is the closest example, and it is one that
illustrates that upgrades don't really work (even after the 12 years
since MX was defined, or whatever it is (longer I think)).

The only contemporary upgrade that is anything like what changing AAAA
to A6 would be, after serious AAAA deployment and use is the conversion
to IPv6 from IPv4.   Even with all the support it has, that one is not
yet certain to actually complete (things are looking good, but it isn't
certain by any means).   And that's with the motivation behind it that
IPv4 simply cannot cope with the net of the future, no matter what frills
are added around the edges (2^32 isn't enough to give one address to
everyone who needs one).

  | 	we can do the following:
  | 
  | 	a) move one proposal somewhere else on the standards track

You actually mean off the standards track.

  | 	Because I beleive that A6 has enough potential, I'm willing 
  | 	to have it move to experimental, giving developers and
  | 	operators more time to understand its impact.  I think that
  | 	long term, its benefits will overshadow AAAA and that a
  | 	migration plan can be deployed.

No, assuming you're right, long term what will happen is that people
will lament that the wrong decision was made in 2001, but regret that
there's no way to transition any more, the combination of resolvers
doing only AAAA lookups, and servers providing only AAAA records, means
there's no clean way to get out from under (sure, servers could provide
A6 records as well, but they'll have to keep providing AAAA records
forever to keep the old resolvers happy, and resolvers could do A6 lookups
but they'd have to fall back on doing AAAA so they can find names that
are only available that way - given that AAAA would have to remain, and
resolvers would have to do lookups of it, just for practical reasons,
there's no way to actually transition to A6).

kre

---

From: Randy Bush <[email-masked]>
Date: Tue, 14 Aug 2001 07:57:00 -0700

> Standards are sometimes created but not used. But at least the
> standard is available if a need arises.

that is one of the major uses of the experimental class of rfcs, this is
not the way we do it today, but if you want to do it, do it this way.
then, when we need it, we pull it off experimental to standard track.
for example, we are doing this with 2770 now.

randy

---

From: Bill Manning <[email-masked]>
Date: Tue, 14 Aug 2001 13:42:30 -0700 (PDT)

% Hogwash.
	Actually, the correct response here is "Sheep Dip" :)

%   | 	we can do the following:
%   | 
%   | 	a) move one proposal somewhere else on the standards track
% 
% You actually mean off the standards track.

	Well, we could do that too.  ISIS/OSPF ended up spending
	-lots- of time at different places on the stds track.
	For the AAAA/A6 debate that is tabled, I'd rather see
	one moved off the stds track to experimental.

%   | 	Because I beleive that A6 has enough potential, I'm willing 
%   | 	to have it move to experimental, giving developers and
%   | 	operators more time to understand its impact.  I think that
%   | 	long term, its benefits will overshadow AAAA and that a
%   | 	migration plan can be deployed.
% 
% No, assuming you're right, long term what will happen is that people
% will lament that the wrong decision was made in 2001, but regret that
% there's no way to transition any more, the combination of resolvers
% doing only AAAA lookups, and servers providing only AAAA records, means
% there's no clean way to get out from under (sure, servers could provide
% A6 records as well, but they'll have to keep providing AAAA records
% forever to keep the old resolvers happy, and resolvers could do A6 lookups
% but they'd have to fall back on doing AAAA so they can find names that
% are only available that way - given that AAAA would have to remain, and
% resolvers would have to do lookups of it, just for practical reasons,
% there's no way to actually transition to A6).

	Cynic. (nee realist?)

% 
% kre
% 

-- 
--bill

---

From: Nathan Jones <[email-masked]>
Date: Mon, 13 Aug 2001 14:02:29 +1000

--
nathanj

---

From: Nathan Jones <[email-masked]>
Date: Tue, 14 Aug 2001 22:19:25 +1000

>	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.

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.

By contrast, if we remove A6 from the standards track now, then there
is no incentive to implement support for AAAA synthesis. If we then
turn around and say "we do need A6 after all", there is little
momentum to implement and deploy A6.

>	core concept in many peoples minds.  

While "we can always upgrade later", it seems to me to be odd that we
would plan it that way. If 128 bit IP addresses had been specified a
year or so after IPv4 came out, would a working group then have said
"we probably don't -really- need it - let's deprecate it and encourage
32 bit addresses instead"?

A6 is already on the standards track and people want to deprecate it before
it has been given a chance. If the specification is not worthy, perhaps
the "market" will decide to ignore it, but at least it is available. 

--
nathanj

---

From: Alain Durand <[email-masked]>
Date: Tue, 14 Aug 2001 22:55:37 -0700

>there's no way to actually transition to A6).

Doing AAAA synthesis at the resolver side helps a stub resolver that
knows only about AAAA to get data from servers that knows only about A6.
This transition scenario will work if we can upgrade the resolvers
at the same time we introduce A6 in the servers. (note that upgrading
the resolvers is a much simpler task than upgrading all the stub resolvers)

Still, it may not be possible to upgrade them all before we introduce A6
in some servers. So what you are highlighting is the need for servers
that are populated with A6 to answer resolvers (not stub-resolver)
that know only about AAAA.

Of course, as you mentioned, servers could be manually populated with AAAA
at well as A6, but there are other possibilities. In other words, we have
to explore AAAA synthesis done at the server side:

   - the server could automatically generate all the corresponding AAAA records
     when loading its A6 database. Of course, the missing pieces will have to
     be provided.
   - the server could generate AAAA on request.

Of course, there are drawbacks and issues with such mechanisms
and more study will have to be made to understand them, but they
are transition mechanism and as such, do not need to be perfect.

The point i'm trying to make is that by combining AAAA synthesis
at the server side with AAAA synthesis at the resolver side, we
may have a way to transition from an all AAAA world to a world
with a mix of AAAA and A6 if/when we need it.

Note also that such techniques would have to be used now if we decided
to move to A6 today.

         - Alain.

---

From: Johan Ihren <[email-masked]>
Date: 15 Aug 2001 09:34:23 +0200

> 	I guess you are mixing up these two.

No, I am not mixing them up. 

I'm pointing out that due to the configuration change that will follow
from deployment of v6 roots it will be comparatively easy to reach all
the caching resolvers (i.e. name servers) on v6 transport to ensure
that they all do AAAA synthesis.

I agree that this will not by itself help the deployed base of
AAAA-aware, A6-ignorant caching resolvers that are v4 single stack.

Furthermore there are obvious problems with doing AAAA synthesis in
response to non-recursive AAAA queries, so we cannot shield those
servers easily by doing the synthesis in the authoritative end.

However, while agreeing that the deployed base of AAAA-aware caching
resolvers on the IPv4-only Internet is large it is less clear to me
how many of those actually care about v6 address records at all. Nor
is it clear how many of those that will start to care before having
upgraded their name server software (which contrary to popular belief
actually happens, although certainly not to all of them).

It is certainly a non-trivial number, but as Bill touched upon,
somewhere there is a price to evolution, and I much rather have it
there (among v4-only servers not caring about v6) than tying the hands
of people that care very much about IPv6.

Johan

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Aug 2001 17:57:32 +0900

>that they all do AAAA synthesis.

	isn't it just a root.hint change, not a server replacement?

	as I have pointed out repeatedly, AAAA synthesis has its own problems
	and I don't feel like deploying it.
	(1) A6 chasing is traffic multiplication = DoS possibility (recursive
	    servers),
	(2) it is unclear as to how will be doing AAAA synthesis, and we cannot
	    ensure that it will happen at the leaf
	(3) by deploying AAAA synthesis you end up maintaining both A6 and AAAA:
	(3a) impose lookup delays to IPv6 clients.
	(3b) server admins need to maintain both A6 and AAAA in zoen file,
	     which is unhappy.

>actually happens, although certainly not to all of them).

	a lot of them do care about AAAA records, since IPv6 people are forced
	to use IPv4 infrastructure.

itojun

---

From: Johan Ihren <[email-masked]>
Date: 15 Aug 2001 11:57:01 +0200

Hi Itojun,

> 	isn't it just a root.hint change, not a server replacement?

Well, if you are running in a forwarding configuration *with your
present server* and replace the root.hint file with one that includes
v6 glue for one or several roots not much will happen. So there is no
point to it.

Because you are using a forwarding configuration.

However, what you want is a root accessible over v6 transport (and of
course all the TLDs, etc, etc) so that you can move away from your
forwarding configuration.

However, to avoid walking around in a barren wasteland of almost no
DNS hierarchy initially I strongly suspect that you would like some
sort of fallback mechanism so that you can still get to the data that
is presently only available over v4 transport. 

But to do that you *will* need a server replacement, since no server
deployed does that today.

There are various icky schemes for doing such transport bridging
(Alain Durand and I have spent some time in that mess and there is a
draft outlining some of the problems). All of these schemes are ugly,
but without something like that I see little point to the v6 roots
that you want.

So, I still claim that the time of deployment of v6 glue for the first
root is a "magic date" since that will initiate a configuration change
and in all likelihood a server replacement for all the v6 caching
resolvers that want to utilize this v6 root for anything useful.

Look at it as a synchronization barrier for IPv6 DNS functionality.

Johan Ihren

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Aug 2001 17:00:43 +0700

Date:        Tue, 14 Aug 2001 22:55:37 -0700
    From:        Alain Durand <[email-masked]>
    Message-ID:  <5.1.0.14.0.20010814140706.01aa6d98@jurassic>

  | Doing AAAA synthesis at the resolver side helps a stub resolver that
  | knows only about AAAA to get data from servers that knows only about A6.

yes, sure.

  | This transition scenario will work if we can upgrade the resolvers
  | at the same time we introduce A6 in the servers. (note that upgrading
  | the resolvers is a much simpler task than upgrading all the stub resolvers)

It would work if we did it now.   There's no way we can ever upgrade all
the resolvers (the real resolvers, the back ends) once IPv6 becomes mainstream.
Just imagine now that you wanted to upgrade all the IPv4 resolvers (back end
resolvers) - there's simply no way.  When IPv6 starts being deployed the
net will be able to grow faster than it has, it is going to be lots
bigger 5 years from now than it is now.   Upgrading anything that requires
everyone to upgrade anything at all will simply be impossible.

  | Still, it may not be possible to upgrade them all before we introduce A6
  | in some servers.

Actually, it would probably be easier the other way.   Adding anything in
zone files requires deliberate administrator effort.  People will only do
that if there's a benefit.   On the other hand, AAAA synthesis can be
slipped in along with other changes in back end resolvers, so that people
(some people) would have it without really even realising it.   Some people
have it now without realising it...

But there's no way to get everyone to have it - which means that administrators
will always have to add AAAA records so those people can find their web
server, mail server, ....   And if AAAA records have to exist, and resolvers
will be looking for them (because no way are all servers going to start
supplying A6 all at once, even with a fairly broad concept of the time quantum)
then there's no point adding A6 records at all - they'd be just one more
thing that has to be maintained (excess duplicate data).   Further, they
wouldn't help do anything, as the AAAA records are still all going to be
there.   If there's a problem that A6 would be useful to solve, then what
will happen is that people will find some hack that allows it to be solved
using AAAA instead, as AAAA will be what exists.

If you want examples of this, look at Mobile IP - which has a whole
mechanism all created, with packet forwarding via home agents, and stuff,
all because there's simply no way to upgrade TCP stacks to allow the
identifier of a connection to be changed (not even with enough security
added to make the change secure).   Not even given that only major servers
really would need that upgrade (and mobile nodes of course, which need
upgraded code anyway).   Rather than upgrading TCP, we invent a hack to
work around the fact that TCP simply cannot be upgraded.

Or, look at IDN, which is doing obscene things to the DNS, to work around
the fact that it is impossible to upgrade all the old mailers (etc) to handle
arbitrary (non-ascii) domain names.   Rather than fix the problem where
it ought to be fixed, hacks are done in other places - because there is
simply no practical way to get the upgrade done that people are willing
to live with (me: I'd just break all the old mailers, etc, and tell people
to upgrade if they'll ever receive/send mail to a domain with a non-ascii
name, but most people aren't willing to do that).

  | So what you are highlighting is the need for servers
  | that are populated with A6 to answer resolvers (not stub-resolver)
  | that know only about AAAA.

No.  What I was highlighting is that if AAAA is nominated now as the
way that we go, then AAAA is it for eternity.  Pretending that we might
sometime later upgrade to A6 if it seemed to be a better idea is no
more than an attempt to handle people who think "A6 probably is better,
but it isn't deployed yet - let's go with what we have now so we can
make it happen, then we'll upgrade later".   Pretend that the upgrade
can happen, and selecting AAAA now doesn't seem so bad.

It cannot happen - net wide infrastructure upgrades are close to impossible
(for them to be even worth considering, the rationale has to be more
than compelling, there must be no other choice - for A6, or mobile IP,
or IDN, or anything else like that, there's always going to be some other
way than the right way).

  | Of course, as you mentioned, servers could be manually populated with AAAA
  | at well as A6, but there are other possibilities. In other words, we have
  | to explore AAAA synthesis done at the server side:

If we were to make the change now, then yes, that's exactly what we should
be doing.   Now there isn't enough deployment to make it all that hard.
For the next 6 months or so (maybe even longer if IPv6 takeup remains
slow) we'll still have that option.   But not much further away.

  |    - the server could automatically generate all the corresponding AAAA records
  |      when loading its A6 database.

Yes.   I'd actually thought of making a hack to bind9 that would convert
all AAAA records into A6 0, and supplying only A6 whatever the admin
configured into the zone file...

  | The point i'm trying to make is that by combining AAAA synthesis
  | at the server side with AAAA synthesis at the resolver side, we
  | may have a way to transition from an all AAAA world to a world
  | with a mix of AAAA and A6 if/when we need it.

We have a way to do it now, or soon.   There's no way that it can ever
be made to happen once we get wide deployment.  Expecting it is just fantasy.

eg: now the DNS has SRV records, they do so everything that MX can do,
and more.   In a way they're the analog of A6 and AAAA (MX is a subset of
SRV).   There would be benefits to converting SMTP to use SRV instead of
MX.   Can you imagine anyone seriously suggesting that that happen however?
Can you really imagine that there'd ever be a day when we could deprecate
the MX record?

  | Note also that such techniques would have to be used now if we decided
  | to move to A6 today.

Yes, sure.   Though it is also possible that AAAA synthesis would never
be a transition technique, but rather a permanent part of the way things
work (even if we decided that we wanted to move away from it, and there
probably wouldn't be much reason, there'd be no way to ever upgrade all
the clients, so back end resolvers would always need to provide it, so
new clients may as well just use the service that they know will be there...)

kre

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Aug 2001 19:08:52 +0900

>Because you are using a forwarding configuration.

	I don't understand what you are saying, AT ALL.
	I'm not using forwarding configuration.  you must have some assumption
	in your head which is not presented here.

itojun

---

From: David Terrell <[email-masked]>
Date: Wed, 15 Aug 2001 03:21:35 -0700

> Actually, it would probably be easier the other way.   Adding
> anything in zone files requires deliberate administrator effort.
> People will only do that if there's a benefit.   On the other hand,
> AAAA synthesis can be slipped in along with other changes in back
> end resolvers, so that people (some people) would have it without
> really even realising it.   Some people have it now without realising
> it...

> But there's no way to get everyone to have it - which means that
> administrators will always have to add AAAA records so those people
> can find their web server, mail server, ....   And if AAAA records
> have to exist, and resolvers will be looking for them (because no
> way are all servers going to start supplying A6 all at once, even
> with a fairly broad concept of the time quantum) then there's no
> point adding A6 records at all - they'd be just one more thing that
> has to be maintained (excess duplicate data).

There's no reason why it can't be a gradual upgrade.  Authoritative
servers for zones with A6 can do AAAA synthesis at query time just
as easily as the local non-stub resolver can.  It becomes a server-side
indirection mechanism, which is available to A6-grokking caches.

Considering that like it or not A) BIND is still a majority of
nameservers, B) bind9 is the first version to support v6 transport
and C) I don't imagine Nominum/ISC/"The BIND Company" removing A6
support just because it's not "the thing", this feature is basically
already present today.  ISPs can provide A6 prefix records for their
customers, those customers can use A6 chains to point to their ISPs
and do authoritative server-side AAAA synthesis (well, ok, bind
needs to add this I guess), and most people can go on using AAAA
and be happy.

I'm squarely in the "Let's take AAAA because it works and let's get
IPv6 off the ground" camp.

-- 
David Terrell   | p = "you are nasty"          q = "my first name is Janet"
Nebcorp PM      | r = "my first name is baby"  s = "My name is Miss Jackson"
[email-masked]    | (!r -> q) & (p -> s)        - Braverman's Third Lemma
wwn.nebcorp.com | !r & (!p -> q) & (p -> s)   - Libor's Corollary

---

From: Johan Ihren <[email-masked]>
Date: 15 Aug 2001 12:30:37 +0200

> indirection mechanism, which is available to A6-grokking caches.

This is *wrong*.

An authoritative, non-recursive server with only A6 fragments around
can not synthesise the AAAA since that would require it to query for
missing fragments.

Johan Ihren

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Aug 2001 18:16:22 +0700

Date:        Wed, 15 Aug 2001 17:57:32 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	(1) A6 chasing is traffic multiplication = DoS possibility (recursive
  | 	    servers),

That has nothing at all to do with AAAA synthesis - it is an argument
against A6 in general, but a very weak one.   A site that wants to
avoid this with A6 can easily avoid it.  A site that wants to create
lots of traffic with lookups can easily create it with AAAA (just add
a few CNAMEs going into other domains...)   A6 adds one more opportunity
for people to configure things badly, but nothing at all new.

  | 	(2) it is unclear as to how will be doing AAAA synthesis, and we cannot
  | 	    ensure that it will happen at the leaf

Who cares?   If someone asks for an AAAA, and gets back an AAAA, then
they're happy right?  If the server provided an A6, was asked for an
A6, and answered with an A6, it is happy, right?  Something between
original (probably stub) resolver and server converted.   Who cares
what it was?

The operators of the resolver might care - for lots of reasons, in which
case they provide the back end resolver that does the synthesis.

  | 	(3) by deploying AAAA synthesis you end up maintaining both A6 and AAAA:

No, exactly the opposite, you end up maintaining A6 only.   The AAAA RR
type remains in use, but that's no work for anyone.

Actual AAAA records remain in zone files only long enough for the current
(small) infrastructure to be mostly upgraded (so that it has back end
resolvers in enough places).  Once a fair proportion has that installed, the
AAAA records simply get yanked from everywhere.  That provides the incentive
for everyone else to install a capable back end.

  | 	(3a) impose lookup delays to IPv6 clients.

No, no delays at all (other than what is involved in the A6 lookup).

  | 	(3b) server admins need to maintain both A6 and AAAA in zoen file,
  | 	     which is unhappy.

No, only A6 records, that's what AAAA synthesis is all about, remember...

kre

---

From: Johan Ihren <[email-masked]>
Date: 15 Aug 2001 13:27:07 +0200

Jun-ichiro itojun Hagino <[email-masked]> writes:

> 	I don't understand what you are saying, AT ALL.  I'm not using
> 	forwarding configuration.  you must have some assumption in
> 	your head which is not presented here.

Ok. Before I repeat the mistake of guessing at your configuration I
suggest you tell me about it.

Personally I use a forwarding config for v6-only nameservers and I
believe that this is by far the most common case. 

Johan

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Aug 2001 20:36:09 +0900

>believe that this is by far the most common case. 

	I have been talking about a nameserver, with root.hint, on IPv4/v6
	dual stack machine.  to be more precise, see below.

	I never have talked about nameservers on IPv6-only machine, they will
	never work without some help from IPv4/v6 dual stack nameserver.
	(and it is rather unrealistic to talk about nameeservers in IPv6-only
	network today...)

itojun

---
# $NetBSD: named.conf,v 1.5 2000/03/01 11:06:29 itojun Exp $

# boot file for secondary name server
# Note that there should be one primary entry for each SOA record.

options {
	directory "/etc/namedb";
	listen-on-v6 { any; };
};

zone "." {
	type hint;
	file "root.cache";
};

zone "localhost" {
	type master;
	file "localhost";
};

zone "127.IN-ADDR.ARPA" {
	type master;
	file "127";
};

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Aug 2001 20:40:10 +0900

>case they provide the back end resolver that does the synthesis.

	you should care about this.  there's no guarantee that AAAA synthesis
	happen between end client and master/slave nameservers.  AAAA will
	leak from leaf to the core.

>No, no delays at all (other than what is involved in the A6 lookup).

	if people query both AAAA and A6, there will be more delays.

>No, only A6 records, that's what AAAA synthesis is all about, remember...

	you seem to be assuming that there's some AAAA synthesis server
	between IPv6 end node and nameservers.  your assumption does not hold,
	especially during the transition period.  because the assumption
	does not hold, zone admins need to maintain AAAA records too.

itojun

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Aug 2001 19:30:28 +0700

Date:        Wed, 15 Aug 2001 20:40:10 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	you should care about this.

Why?

  |	there's no guarantee that AAAA synthesis
  | 	happen between end client and master/slave nameservers.  AAAA will
  | 	leak from leaf to the core.

Yes.   That doesn't tell me why I need to care.   People send queries
for all kinds of RR types that I don't have in my zone files, my
servers return NO DATA responses (no error, no answer).  Perfectly
normal.   That's what is likely to happen if they request an AAAA and
all I have is A6.   (Just maybe I'll do AAAA synthesis for random people
in the very early days).

Exactly why is this a problem to care about?

  | 	if people query both AAAA and A6, there will be more delays.

Yes, so they shouldn't.   End nodes can do AAAA to their back end.
The back end should do A6 only, and synthesise the AAAA.   No extra delays.

  | 	you seem to be assuming that there's some AAAA synthesis server
  | 	between IPv6 end node and nameservers.  your assumption does not hold,
  | 	especially during the transition period.

Right now it doesn't, no, it will take a little while to get them
installed everywhere if we decide on A6 now.

  |     because the assumption
  | 	does not hold, zone admins need to maintain AAAA records too.

No, I can use A records as backup.   They backup both the peers that
only know about AAAA, and the ones that don't know IPv6 at all.   We all
agree that IPv4 is still going to be needed for a while yet, so it is
just fine with me if peers who cannot handle A6 at all simply use IPv4.
That will work.

If the remote end wants to use IPv6, then it can install a synthesis
server for its AAAA only nodes, and the A6 records will work fine.

We can do this, because right now IPv4 works, and is a backup that we
need to have anyway - so it is just fine to simply toss out all the
AAAA records and replace them with A6.   Nothing is going to break
because of that.

We won't be able to do that when we start getting native IPv6 nets though,
which is why if this change is ever to be made, it needs to be made very
soon - otherwise never.

kre

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Aug 2001 21:34:11 +0900

>Exactly why is this a problem to care about?

	we (pick any community i'm involved with) are already operating AAAA
	in a lot of places.  we need to keep those configuration to work fine
	while we migrate to A6 + AAAA synthesis.  we have serious users of
	IPv6 using AAAA, and we cannot break their configuration, nor
	transition them into some other record type in one night.  you have
	been proposing a migration path with a hard "flag day", with:
	- all existing zone files must be rewritten to from AAAA to A6 in one
	  night (of which timezone?)
	- all AAAA queriers can stay as is, but there has to be AAAA synthesis
	  server at every leaf
	- no AAAA traffic in core DNS cloud, only A6 traffic.
	this is totally unacceptable to us.

	the story applies only if we are going to move to A6 + AAAA synthesis.
	if we don't migrate, we have no worry and everyone is happy.

itojun@tired.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Aug 2001 21:49:58 +0900

>It is only during the transition period that this assumption does not
>hold true. The result of the transition is that there is an AAAA synth
>server between the IPv6 end node and the nameserver. It is only during
>the transition that AAAA records will be maintained alongside A6 records.

	how long do you think it will take, and how many people do you think
	get bitten by this?

itojun

---

From: Bill Manning <[email-masked]>
Date: Wed, 15 Aug 2001 06:00:34 -0700 (PDT)

% It cannot happen - net wide infrastructure upgrades are close to impossible
% (for them to be even worth considering, the rationale has to be more
% than compelling, there must be no other choice - for A6, or mobile IP,
% or IDN, or anything else like that, there's always going to be some other
% way than the right way).

	Then the Internet is doomed.  Either evolution or revolution.
	Either the right way or an incremental hack, a goiter, that
	we can never get rid of.

	If there can never be any significant upgrade, then something
	else will come along and replace it.  Some interesting work
	is starting to appear in the HIP/MANET space that could
	give some level of transport independence (rehoming TCP
	sessions on the fly) which could make existing mobilip
	OBE. The right path for IDN was to change the on-wire/stored
	encoding, forcing application evolution. Some fools^H^H^Hlks
	are looking at how to make those changes to the DNS.

% We have a way to do it now, or soon.   There's no way that it can ever
% be made to happen once we get wide deployment.  Expecting it is just fantasy.
% 
% eg: now the DNS has SRV records, they do so everything that MX can do,
% and more.   In a way they're the analog of A6 and AAAA (MX is a subset of
% SRV).   There would be benefits to converting SMTP to use SRV instead of
% MX.   Can you imagine anyone seriously suggesting that that happen however?
% Can you really imagine that there'd ever be a day when we could deprecate
% the MX record?

	Yes I can see it.  We've done it before. VJC is yet another
	example. Heck, we might even replace SMTP.

% Yes, sure.   Though it is also possible that AAAA synthesis would never
% be a transition technique, but rather a permanent part of the way things
% work (even if we decided that we wanted to move away from it, and there
% probably wouldn't be much reason, there'd be no way to ever upgrade all
% the clients, so back end resolvers would always need to provide it, so
% new clients may as well just use the service that they know will be there...)

	Yet another hack, like mobilip & IDN. 

% kre

	As stated elsewhere, you seem to be taking the cynical
	path while I retain some semblence of pollyanna. You seem
	unwilling to do the right thing in favor of what looks
	like the expediant thing.  Or am I reading too much into
	your statements?

-- 
--bill

---

From: Johan Ihren <[email-masked]>
Date: 15 Aug 2001 15:16:12 +0200

Jun-ichiro itojun Hagino <[email-masked]> writes:

> 	I have been talking about a nameserver, with root.hint, on
> 	IPv4/v6 dual stack machine.  to be more precise, see below.
> 
> 	I never have talked about nameservers on IPv6-only machine,
> 	they will never work without some help from IPv4/v6 dual stack
> 	nameserver.  (and it is rather unrealistic to talk about
> 	nameeservers in IPv6-only network today...)

Ok, we were clearly talking about different things. And this further
clarifies the initial difference in opinion on the size of the
deployed base of full-service resolvers that are IPv6-aware and 
-caring.

The issue with roots available over v6 transport was mostly a side
track that was relevant only for the subset of full-service resolvers
that are v6-only.

As to whether it is unrealistic to talk about name servers on
IPv6-only networks or not, I still argue that although they are a
small base today (which we now agree upon) they will be the dominant
species at some point in the future. And now is the time we have to
decide how the world they will populate should work.

But the core issue is still whether it is too late to upgrade the
deployed full-service resolvers to do AAAA synthesis or not. And if
not too late then how long it will take.

I think that given a clear decision (which seems impossible) this
could be fairly rapid for the full-service resolvers that actually see
real traffic since they are almost certainly to a large degree waiting
for the outcome of this A6/AAAA commotion.

And given A6, that would not delay deployment [of IPv6], since new
deployment would have the benefit of doing it right [i.e. A6] from the
outset thereby rapidly creating even more incentive for the installed
base (i.e. the dual-stack or forwarding servers, all of them bind9) to
upgrade. 

It is important to weigh in the difficulties of pushing a deployed
base to upgrade. But in this particular case I worry that that problem
unnecessarily may be overshadowing the design issues.

Anyone that presently operate a dual-stack server or a forwarding
server with only v6 transport and isn't aware that there are unsolved
problems with DNS for IPv6 and that it will in all likelihood be
necessary to change configs/upgrade software/modify tools/etc is not
really on top of his or her responsibilities. 

Fortunately, since we are still in the early days, I really think they
constitute a small minority. The rest, regardless of their position on
the A6/AAAA issue, are at least fully aware that such issues *exist*
and hence aware that they will possibly have to change stuff somewhat
as those issues get resolved. The v4-only-dont-care-about-v6-although-
their-resolver-groks-aaaa is a different story, but I care less about
breaking lookups of v6 records for them.

So, to my mind, A6 would not necessarily delay deployment of IPv6
significantly. What is clearly delaying deployment is lack of consensus.

But I don't know. It has to be a judgement call.

Johan

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Aug 2001 22:22:51 +0900

>I don't recall anyone saying that this needs to be an instant change.
>
>I do recall people saying that A6 has merit and that it is worth the
>effort to migrate.
>
>The whole idea of transition mechanisms like AAAA synth is to allow
>gradual adoption of A6 as people start adopting A6.

	well, this is because you guys have been ignorant about transition
	issue from the current situation to "AAAA synthesis" situation.

>Obviously there will be a transition period during which members of
>the existing (comparatively small) IPv6 community will either provide
>both AAAA and A6, or run DNS software that can synthesise AAAA RRs to
>serve requests from other existing IPv6 users.

	what I have been arguing about is that, AAAA synthesis advocators
	never mention about transition period like the above four lines.
	it was very first time it was admitted by AAAA synthesis advocators.
	AAAA synthesis advocators never talk about this "issues during
	transition period to AAAA synthesis"
	wait, AAAA synthesis is a transition tool to A6, and we need a
	transition period to move to AAAA synthesis?  what is the merit of
	doing such a complex thing?  will the effort really buy us anything?

	there has to be more detailed analysis made, before AAAA synthesis
	be even taken into consideration.  I'm serious.  someone has to write
	up a whole analysis document.  I tried it in my draft, but you may
	say I'm biased :-P

>These claims seem to stem from either disbelieve that the transition
>can be made, or from desire to stop A6 regardless of its merits.

	you can't control what I believe, or disbelieve.  what I'm keep saying
	is AAAA synthesis advocators are too optimistic about the mess
	that happens during the transition period.

	and if we don't transition, there's no mess!

itojun

---

From: Johan Ihren <[email-masked]>
Date: 15 Aug 2001 15:49:26 +0200

> 	if we don't migrate, we have no worry and everyone is happy.

I'm not!

Johan

PS. Sorry about that, but I simply could not resist that response in
the grand tradition of the british Monty Python-comedians... now back
to our regular programme of intense disagreements ;-)

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Aug 2001 21:31:35 +0700

Date:        Wed, 15 Aug 2001 21:34:11 +0900
    From:        Jun-ichiro itojun Hagino <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	we (pick any community i'm involved with) are already operating AAAA
  | 	in a lot of places.

Fine.

  |	we need to keep those configuration to work fine
  | 	while we migrate to A6 + AAAA synthesis.

Of course.

  |	you have
  | 	been proposing a migration path with a hard "flag day",

No I haven't.   What I said was that I can change my AAAA records to
A6 records any time I like.   I can simply delete my AAAA records and
not replace them at all any time I like.   You will never notice, I'm
quite sure that you don't care in the least about my few AAAA records.

For any new systems I can install only A6 records - while you're only
doing AAAA lookups you won't find them.  You won't find them now while
they have no v6 records at all either...  Either way, you cope.

  |	- all existing zone files must be rewritten to from AAAA to A6 in one
  | 	  night (of which timezone?)

No, I didn't say anything like that.   I said that a server could convert
(or a human operating a server could), I didn't ever claim that it all
has to happen at once, there's no reason for that.

  | 	- all AAAA queriers can stay as is, but there has to be AAAA synthesis
  | 	  server at every leaf

Eventually, yes.   In the short term, one used as a forwarder anywhere
(one per ISP would do just fine).

  | 	- no AAAA traffic in core DNS cloud, only A6 traffic.

That's not a requirement, just a target.   It will probably never be
reached.   But who cares?   There are probably MB queries out there in
the net now, somewhere, no-one cares about those either.

In another message you asked (Nathan Jones I think, but I will answer anyway)

  | 	how long do you think it will take, and how many people do you think
  | 	get bitten by this? 

Time, depending upon how committed various people are, a month or two,
perhaps three.  It depends how urgent it is seen to be.

People, maybe 10K or so, perhaps realistically just a thousand.
Compared to the millions of internet users, almost no-one.

Of course, if you're one of the 10K (or 1K or whatever it is) then you're
going to suffer a bit - you'll have some extra work to do, and you might
want to maintain both AAAA and A6 for a while (you probably would,
I wouldn't).

That's extra work.   It is also a part of the price of being an early
adopter, which tends to hit everything new as it is being introduced.
You get the benefits of being among the first, you have to pay the costs
as well.

And in another message ...

  | 	what I have been arguing about is that, AAAA synthesis advocators
  | 	never mention about transition period like the above four lines. 

That's because it is kind of obvious.   Clearly the net that we have now
is going to have to transition (assuming A6 is selected).   You can read
my messages about how impossible that will be if left a few years as
implying that I don't think this is a trivial exercise, even now.  It isn't.
But it is manageable now.  It can be done.   We could even do it in stages,
ask everyone to put A6 records in their servers wherever AAAA records exist.
Then when we see (by querying the servers that we care about) that has been
done, we can install A6->AAAA synthesis resolvers.  Then when we see that
the number of AAAA queries hitting our servers has dropped to an acceptably
low level (which each of us can define individually), remove the AAAA
records from our servers.    Allow 3 weeks for the first step, and then
everything is self timimg (we each proceed at our own pace).

  | 	wait, AAAA synthesis is a transition tool to A6,

You can view it that way - but it is also possible to view it as
simply a part of the infrastructure, the same way that TSIG/AD is
a part of the DNSSEC infrastructure.   Allow end nodes to do just
simple things (if they want, they can always do A6, or full dnssec,
if they prefer - most won't) forever.  Nothing transition about it.

  |	and we need a transition period to move to AAAA synthesis?

Yes, but this isn't hard.

  |	what is the merit of doing such a complex thing?

It isn't complex.   It is simple.   It gets us to a much more
flexible DNS RR - one which incidentally (aside from all the other
benefits) means we need just N+M RR's in the DNS (and answers)
rather than N*M for every node (where N is the number of interfaces
a node has, and M is the number of prefixes).  That may very well
allow UDP queries to continue to work in situations (especially major
serves - which are what most people want to reach) that AAAA would
require TCP be used instead (ie: the 1280 (or 512 for basic v4 transport)
bytes of DNS packet will hold much bigger A6 RRsets - sanely designed -
then it will AAAA RRsets).

eg: for AAAA, in a 512 byte packet, you can fit (maybe, if you're
lucky and the name isn't too long) 27 RRs.   If you have 4 providers,
then the max addresses for a node before you get TC problems is 6.
That's pretty limiting...   With A6, you could probably fit 20 addresses
for the node (and the 4 providers).   This is one of the things the
tests I am about to start doing will measure...  If you're using many
addresses to get load balancing, this matters.

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Aug 2001 21:56:37 +0700

Date:        Wed, 15 Aug 2001 06:00:34 -0700 (PDT)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Then the Internet is doomed.  Either evolution or revolution.

In some places, revolution is all that is possible.   The evolutionary
step is just too big to every take.

  | 	If there can never be any significant upgrade, then something
  | 	else will come along and replace it.

There can be upgrades, we see upgrades all the time.  What will never
happen is an upgrade that is a basic change on the way things function,
that requires lots of what is out there to change to keep up.  All the
upgrades that succeed are either done as local transitions (I upgrade,
you upgrade, eventually perhaps everyone might have), or are backwards
compatible (I have upgraded, I keep talking to you, even if you haven't).

  |	Some interesting work
  | 	is starting to appear in the HIP/MANET space that could
  | 	give some level of transport independence (rehoming TCP
  | 	sessions on the fly) which could make existing mobilip
  | 	OBE.

Not anytime soon.   There might always be something new that works better,
but to use all the existing stuff, TCP is still going to be around, for
a very very long time.

  |	The right path for IDN was to change the on-wire/stored	encoding,

Actually, for the DNS, the right thing was almost nothing - it all works
already (maybe some servers might need bugs fixed, to allow names containing
nuls or something be stored in files, but that's not too hard).

  |	forcing application evolution.

Yes, that would be the right way.   But we know it isn't the way that
is being adopted, don't we.   Ever wonder why...

  |     Some fools^H^H^Hlks
  | 	are looking at how to make those changes to the DNS.

No DNS changes are needed.   Just a definition of what a non-ascii
label means (like "it is UTF-8"  or something), and perhaps something
to deal with ascii case equivalence (yet another feature it would be
nice to excise, but which is too deeply rooted now to ever go away).

  | 	Heck, we might even replace SMTP.

We just finished redefining SMTP - with the major objective of
documenting what is actually used (eliminating the dead wood).
Not much was deleted, really...

  | 	As stated elsewhere, you seem to be taking the cynical
  | 	path while I retain some semblence of pollyanna.

Perhaps.  The latter is an interesting nightmare...

  |	You seem unwilling to do the right thing in favor of what looks
  | 	like the expediant thing.

No, I'd very much like to do the right thing.  That includes fixing
TCP so it can handle connection renaming (which would be trivial to
do in a backwards compatible way - but impossible to get deployed at
a big enough fraction of sites to make it actually useful), sticking
idn labels directly in the DNS (and having the app protocols deal with
that), and using A6 rather than AAAA.

The last we can choose to do now, it is still possible.  The others we
could choose to do, but I doubt they'd ever actually work (idn just
maybe, with enough pressure - as comparatively little actually cares,
whatever the standards say).

  |     Or am I reading too much into your statements?

Perhaps.

kre

---

From: Alain Durand <[email-masked]>
Date: Wed, 15 Aug 2001 10:10:28 -0700

>can not synthesise the AAAA since that would require it to query for

Those fragments could be provided (or queried) when the server is started.

         - Alain.

---

From: Bill Manning <[email-masked]>
Date: Wed, 15 Aug 2001 10:40:32 -0700 (PDT)

% a big enough fraction of sites to make it actually useful), sticking
% idn labels directly in the DNS (and having the app protocols deal with
% that), and using A6 rather than AAAA.
% 
% The last we can choose to do now, it is still possible.  The others we
% could choose to do, but I doubt they'd ever actually work (idn just
% maybe, with enough pressure - as comparatively little actually cares,
% whatever the standards say).
% 
%   |     Or am I reading too much into your statements?
% 
% Perhaps.
% 
% kre

	Ah... the light (well a light) is illuminated.
	We are in agreement save on two points:

		- the viablity of transition
		- the timeframe of transition

	Transition viability is debatable, the key point seems
	to be the window in which the transition occurs.
	You are arguing for a fairly short schedule and I think
	this can be streched out some

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Wed, 15 Aug 2001 10:41:28 -0700 (PDT)

% 
% On Wed, Aug 15, 2001 at 09:56:37PM +0700, Robert Elz wrote:
% >     Date:        Wed, 15 Aug 2001 06:00:34 -0700 (PDT)
% >     From:        Bill Manning <[email-masked]>
% >     Message-ID:  <[email-masked]>
% > 
% >   | 	Then the Internet is doomed.  Either evolution or revolution.
% > 
% > In some places, revolution is all that is possible.   The evolutionary
% > step is just too big to every take.
% 
% I'm butting in here, but it may be interesting to know that quite a number
% of the top-100 resolving nameserver installations out there are still
% running Bind4! I'm doing some research on the big resolvers out there,
% especially the (non-)randomness of the id field.
% 
% Some of these people have gone through great lengths to remain at Bind4,
% even though they run late breaking operating system releases.
% 
% Regards,
% 
% bert hubert

	I'd like to compare numbers. 

-- 
--bill

---

From: Nathan Jones <[email-masked]>
Date: Wed, 15 Aug 2001 23:13:37 +1000

>itojun@tired.

:-)

--
nathanj

---

From: Nathan Jones <[email-masked]>
Date: Wed, 15 Aug 2001 22:54:28 +1000

>   leak from leaf to the core.

David Terrell's suggestion that AAAA synth be performed by
nameservers which are authoritative for zones with A6 data seems 
worth considering here.

DNS admins can then use A6 without fear that their hosts will not be found.
Over time, the authoritative nameserver will not have to synthesise AAAA
records as frequently, as it will receive more requests for A6 RRs. This
increase in A6 requests will come from the normal uptake of resolvers that
support A6 and perform AAAA synth for the remaining base of non-A6 stub
resolvers.

>   if people query both AAAA and A6, there will be more delays.

People won't always query both RR types. The idea of transition is to
move to A6; once there is wide spread use of A6 records and resolvers
that query for A6 records, there won't be frequent querying for both.

(And once again, if you run a nameserver that can do AAAA synth, then
you don't even need to maintain AAAA records too.)

Lastly, there seems to be a number of people here supporting A6 in
principle, but saying that we should shelve the idea now and consider
it later. Surely it is preferable to follow those principles now,
rather than putting the idea in the "too hard basket"...

--
njones

---

From: Nathan Jones <[email-masked]>
Date: Wed, 15 Aug 2001 23:33:55 +1000

>   Either the right way or an incremental hack, a goiter, that

I don't think kre is opposing evolution here; simply saying that we
should assist evolution by doing it now while it's easier.

>   example. 

I can see that it is possible to convert SMTP to use SRV records, but 
the required transition time would be tremendous. The same applies to
a transition from AAAA to A6 years down the track.

>   Heck, we might even replace SMTP.

Isn't that revolutionary rather than evolutionary?  :-)

>	Yet another hack, like mobilip & IDN. 

Why have a hack, when we can do it right the first time? You seem to
be implying...

>   You seem unwilling to do the right thing in favor of what
>   looks like the expediant thing.  Or am I reading too much
>   into your statements?

...that implementing A6 is the wrong thing to do. Wrong for what solid
reasons? (Leaving transition "woes" out of the debate for a moment.)
Wrong because AAAA has an advantage over A6? If so, what advantage?

If it is not wrong, then why move it off the standards track?

--
nathanj

---

From: bert hubert <[email-masked]>
Date: Wed, 15 Aug 2001 17:20:26 +0200

> step is just too big to every take.

I'm butting in here, but it may be interesting to know that quite a number
of the top-100 resolving nameserver installations out there are still
running Bind4! I'm doing some research on the big resolvers out there,
especially the (non-)randomness of the id field.

Some of these people have gone through great lengths to remain at Bind4,
even though they run late breaking operating system releases.

Regards,

bert hubert

---

From: Nathan Jones <[email-masked]>
Date: Thu, 16 Aug 2001 02:04:35 +1000

>can not synthesise the AAAA since that would require it to query for

True, but it could still be an option for DNS administrators happy
to run a recursive nameserver.

Also, I haven't thought this through fully, but is there any reason
a nameserver couldn't have an option to use recursion for AAAA
synthesis, but still deny to recurse when answering client queries?

--
nathanj

---

From: bert hubert <[email-masked]>
Date: Wed, 15 Aug 2001 21:11:05 +0200

> 	I'd like to compare numbers. 

I'm working out the data right now. I'm afraid that it will also lead to
several vendor's advisories, I've found some nameservers whose idea of
random packet ids consists of predictable large fixed positive increments.

I'll release the data 'soon'.

Regards,

bert

---

From: Johan Ihren <[email-masked]>
Date: 16 Aug 2001 15:34:22 +0200

> nameservers which are authoritative for zones with A6 data seems

I think that is a very dangerous idea that we shouldn't use anywhere
in an argument to ease a possible transistion to A6 + AAAA synthesis.

Many authoritative servers run in non-recursive mode for security
reasons, which is sound practice.

Doing synthesis in the authoritative end would

a) expose the servers doing it to possible cache pollution

b) remove incentive from leaf sites to enable synthesis in the local
   full-service resolver thereby prolonging and increasing the leakage
   of AAAA queries into the core ("hey, it already works, why should
   we upgrade").

Both are bad. 

If AAAA synthesis turns out to be the correct answer then it should be
done in the right place.

Johan

---

From: Dancer Vesperman <[email-masked]>
Date: Tue, 21 Aug 2001 10:49:24 +1000

> 	I'd like to compare numbers. 

I can't talk about the top-100, but I have a fair experience 'in the 
trenches'. Every geek I know who runs her own nameserver is running 
bind8 or bind9. Only four companies out of circa 70 that I've done work 
for since bind8 came out have bind8 (the rest have bind4, and I 
personally installed three out of those four bind8 setups).

<OPINION>Honestly, most DNS admins are barely willing to learn what they 
currently have, in a minimally effective fashion. Between lame 
delegations, CNAME abuse, and MX nightmares, it's often amazing that the 
  public internet runs at all.

IPv6 is being actively resisted by network admins and managers because 
it's not an incremental change. It's full of Big Scary Newness(tm). 
They'd rather extend v4 than step up to v6. It's all very "not on my 
watch", at the moment. I'd guess that maybe 30% of networks won't even 
start to take up ipv4 until perhaps more than 50% of the most popular 
bits of the net are no-longer reachable through it...And you know they 
will be, for some time. SMTP and WWW traffic will be gatewayed for 
almost ever, on the evolutionary path.

As far as the actual A6 vs AAAA debate goes, it all boils down to this: 
If we cock this up, then in a hundred years time, the odds are that 
sysadmins are going to be swearing at us for the mistakes we made. OTOH, 
if we just sit and talk it back and forth for a while, the status quo 
will become a fait accompli, and our names still become mud in the 
future. Hamlet or Othello? Or someone else?
</OPINION>

D

---

From: Bill Manning <[email-masked]>
Date: Mon, 20 Aug 2001 19:58:51 -0700 (PDT)

% As far as the actual A6 vs AAAA debate goes, it all boils down to this: 
% If we cock this up, then in a hundred years time, the odds are that 
% sysadmins are going to be swearing at us for the mistakes we made. OTOH, 
% if we just sit and talk it back and forth for a while, the status quo 
% will become a fait accompli, and our names still become mud in the 
% future. Hamlet or Othello? Or someone else?
% </OPINION>
% 
% D

	Titania or Puck.

--bill

---

From: Roy Arends <[email-masked]>
Date: Thu, 16 Aug 2001 01:47:01 +0200 (CEST)

On Wed, 15 Aug 2001, bert hubert wrote:

> running Bind4!

I'm interested in the algorithm to determine that list of top-100
resolving nameserver installations.

> I'm doing some research on the big resolvers out there,

That is indeed interesting. I am working on a thingy to identify specific
dns implementations by determining the response behaviour. (Non)randomness
of the ID field might help to identify.

Roy Arends
Nominum
-------------
0-14-023750-X dcrpt ths 43.0D.01 01.05.0C 84.18.03 8A.13.04 2D.0B.0A

---

From: bert hubert <[email-masked]>
Date: Thu, 16 Aug 2001 10:54:17 +0200

> resolving nameserver installations.

You just tcpdump a lot on nameservers hosting a lot of domains. I personally
use dns-us1.powerdns.com and dns-eu1.powerdns.com, as well as ns1.i.am and
ns2.i.am - these cover around 4000 domains, including the widely used
'i.am' one.

Regards,

bert

---

From: Roy Arends <[email-masked]>
Date: Thu, 16 Aug 2001 18:07:23 +0200 (CEST)

> ns2.i.am - these cover around 4000 domains, including the widely used

Ah, yeah, but it will be fairly difficult to do an assesment of ID
randomness in the received queries (unless incremental).

I am interested in the survey results, could you dump your results on the
lists ?

Thanks

Roy Arends
Nominum
-------------

---

From: bert hubert <[email-masked]>
Date: Thu, 16 Aug 2001 20:07:51 +0200

> I am interested in the survey results, could you dump your results on the

I'm still busy processing stuff, but some interesting plots are these:

A very special implementation of random:
	http://ds9a.nl/pub/notrandom.png 

This is bind4 I think:
	http://ds9a.nl/pub/minnie-random.png

W2K Nameserver I think:
	http://ds9a.nl/pub/210.244.182.61.53.png

The X axis plots seconds since midnight (I started measuring around half
past 10PM, ended around 11AM the next day). The Y axis is the DNS query id.
In the upper right hand side you can find the IP address of the recursing
nameserver.

The W2K nameserver might be smart enough to generate id's per remote IP
address, and therefore be deterministically safe, instead of 'just random'.

I really hope to publish something soon but my spare time is not that
copious..

Regards,

bert

---

From: Alan Barrett <[email-masked]>
Date: Fri, 17 Aug 2001 09:54:03 +0200 (SAST)

> reasons, which is sound practice.

The information that the authoritative servers would need to perform
AAAA synthesis could conceivably be provided as "glue".  There's no
absolute need for it to be obtained via any sort of recursive query.

--apb (Alan Barrett)