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.

������r��zǧu���Ơz�'jg���iz����z�������_����+a������{.n�+����v��x%zX�y�-�鞲Ơzױ��

---

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

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

	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

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

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'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: 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: "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: 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: 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: 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: Nathan Jones <[email-masked]>
Date: Mon, 13 Aug 2001 14:02:29 +1000

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.

---

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

--
nathanj

Bernard Aboba wrote:
>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
>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: 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"?

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

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: 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: Jun-ichiro itojun Hagino <[email-masked]>
Date: Tue, 14 Aug 2001 22:37:49 +0900

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

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

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: 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: Randy Bush <[email-masked]>
Date: Tue, 14 Aug 2001 07:57:00 -0700

> 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: 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: Jun-ichiro itojun Hagino <[email-masked]>
Date: Wed, 15 Aug 2001 17:57:32 +0900

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

	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.

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

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

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: 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: 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: 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 21:34:11 +0900

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

	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:34:11 +0900

itojun@tired.

---

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

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

Why?

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

itojun

---

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: 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: Nathan Jones <[email-masked]>
Date: Wed, 15 Aug 2001 23:13:37 +1000

>itojun@tired.

:-)

--
nathanj

---

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: 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: 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)