Subject: AAAA/A6 thing

From: [email-masked]
Date: Fri, 27 Apr 2001 13:12:24 +0900

it seems that there's no activity regarding to AAAA/A6 thing.  since
	it was mentioned that "if there's no strong case for A6, AAAA wins"
	during IETF50 meeting, i guess "no activity" means "AAAA wins" :-)

	seriously, if it seems to be a good starting point, I can compile
	my question I've sent to the list, and the arguments I've seen, into
	a draft.  note that the draft does not seem to make "a case for
	doing A6" - rather, the draft will mainly list problems in A6, and
	will compile existing arguments/observations.  if i were to work on
	it, i plan to make it ready before ipngwg interim meeting.

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: Fri, 27 Apr 2001 22:54:05 +0700

Date:        Fri, 27 Apr 2001 13:12:24 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	it seems that there's no activity regarding to AAAA/A6 thing.

I plan on doing some actual A6 testing, sometime in the near(ish)
future.

Until someone does, there's no data upon which to base a decision,
other than guesswork.

A draft listing the imagined possible problems with A6 can't hurt, but
by itself nor will it achieve a lot.

kre

---

From: [email-masked]
Date: Sat, 28 Apr 2001 01:03:52 +0900

>I plan on doing some actual A6 testing, sometime in the near(ish)

	just a datapoint - kame.net has been having A6 records for a while.
	and we have been testing resolvers and nameservers with these
	records for a while.  i'm not sure what is the best quantitative way
	to understand the problems though (# of queries, delays, complexity in
	resolver code?).

>Until someone does, there's no data upon which to base a decision,

	yup.  most of the past discussions were guessings and future tellings,
	basically ("in the future we would need to renumber every day...").
	we must admit that we cannot really test everything, though.

itojun

---

From: Robert Elz <[email-masked]>
Date: Sat, 28 Apr 2001 01:05:01 +0700

Date:        Sat, 28 Apr 2001 01:03:52 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	just a datapoint - kame.net has been having A6 records for a while.

Yes, there are a few A6 RR's out in the wild - but aside from demonstrating
that the world hasn't ended because of that, those don't prove much,
either way.

  | 	and we have been testing resolvers and nameservers with these
  | 	records for a while.

But that is more interesting, if you have some results from that to
put in the draft, then it will be much more interesting.

  |     i'm not sure what is the best quantitative way
  | 	to understand the problems though (# of queries, delays, complexity in
  | 	resolver code?).

I suspect that there is no best way.   What we need (I think) is for
several people to have tried using the things (really using them, including
attempting some of the wilder configurations possible), and then for their
experiences to be made known to the group(s) as a whole (A6 is really an
ipngwg work item, not dnsext though - but it is certainly good for both
groups to be involved).

With that data, the group(s) might be able to get a better feel for whether
the costs (of which there will certainly be some) of using them outweigh
the undisputed extra flexibility that they provide.   And whether that
flexibility is useful or not.

  | 	yup.  most of the past discussions were guessings and future tellings,
  | 	basically ("in the future we would need to renumber every day...").
  | 	we must admit that we cannot really test everything, though.

No, we cannot test everything, other than letting it out in the wild, and
then observing the effects.   But we can see if we can gather some evidence
on whether this is too dangerous to release or not, rather than just relying
upon first impressions.    (Eg: in Aus we have some wicked looking goannas
and snakes, and stuff, which are really pretty harmless to anyone.  On the
other hand, catch one of those cuddly looking koalas at a bad time, and you're
in for a nasty shock.)

kre

---

From: Paul Vixie <[email-masked]>
Date: 28 Apr 2001 10:57:35 -0700

> that the world hasn't ended because of that, those don't prove much,

Nor will proof of that kind be available without a lot more operational
deployment.  

It sounds like you're not planning to wait for proof of that kind, but
rather, get in a room with some like minded others and simply decide
whether A6 is worth deploying or whether it really does suffer from all
the woes which have been attributed to it and if so whether they add up
to something fatal or not.

Which means IPv6's "quick renumbering" requirement is back on the table.
And since quick renumbering was used to sell the fast path IPv6 is on, I
assume that we can now listen to Tony Li's "too little, too soon" complaint
and just pull back from IPv6-as-specified and try to come up with something
that's going to solve more of the problems we DO and WILL have, and fewer
of the problems we MIGHT or COULD have?

No?  You mean that stuff isn't back on the table, and we're going ahead with
IPv6 regardless of whether or not it has quick renumbering capabilities?  If
so, I will accuse the various directorates of "bait and switch" tactics used
to ram their limited vision through various debates with no actual intent to
follow through on any of their "campaign promises."

Which would make this whole thing a lot like the RSA/DSA problem DNSSEC has.

Are we still considering rearranging the IPv6 packet format to put destination
address first?  After all if the whole thing's still so experimental that we
don't know what features it has or how we will deliver them, let's see the
WHOLE laundry list.  (I don't think IPv6 could stand that kind of scrutiny,
but then, neither could IPv4 if it were proposed today.)

Hint to whoever is in charge: the time to debate A6's merits at this level
was: before it got put on the standards track, before a lot of code got
written, and before a lot of operational deployment was put into various
long and expensive pipelines.
-- 
Paul Vixie <[email-masked]>
President, PAIX.Net Inc. (MFNX.O)

---

From: Robert Elz <[email-masked]>
Date: Sun, 29 Apr 2001 17:58:19 +0700

Date:        28 Apr 2001 10:57:35 -0700
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | Nor will proof of that kind be available without a lot more operational
  | deployment.

Yes, that was my point.

  | It sounds like you're not planning to wait for proof of that kind,

I don't know how I sounded like that, as that's the exact opposite of
what I am proposing.  What I'm proposing is to do some real testing of
A6, and gather the evidence.

I would hope that many others would as well.

  | Hint to whoever is in charge: the time to debate A6's merits at this level
  | was: before it got put on the standards track,

No, that's not right.  The whole point of standards at PS, and then
implementations, and then implementation reports before DS, is to see
whether the standard proposed can actually be implemented properly,
and then between DS and full std there's supposed to be widespread
deployment, so see if the thing actually works, and is accepted, in the
field.  At either of those stages the entire thing (any proposal) can be
found wanting and killed.

Now I'm in general a believer of A6, I suspect that as defined, it will
work in practice.  But I don't yet know that, which is why I'm planning
on doing some real testing (though I doubt I will have much in the way of
meaningful results before the ipngwg interim meeting, which I won't be at
anyway - I should have before the next IETF though, which I hope I will
manage to get to).

kre

---

From: Greg Hudson <[email-masked]>
Date: Sat, 28 Apr 2001 17:00:40 -0400

I understand Paul's frustration that this issue is being debated at
such a late date and after other decisions have been made on top of
it.  But since I'm not in charge, and I have a question, I'll ask it.

> Which means IPv6's "quick renumbering" requirement is back on the

Does DNS "quick renumbering" have to be done in a way visible to DNS
clients?

Which is to say: if what we need is a way to change a whole bunch of
host -> address mappings in a single operation, is there a compelling
reason to make that mechanism visible to the client, instead of just
handling it in server implementations?

One reason for doing it the A6 way is that it allows a prefix to be
renumbered when the hostnames using that prefix live in different
zones, without creating new communication channels between servers.
Another reason to do it the A6 way probably has to do with TTLs.  Are
either of these reasons compelling?  Are there other reasons?

(I also have a comment which goes beyond the question I'm asking:)

If I'm not mistaken, IPV6 has already given up on the kind of "quick
renumbering" which wouldn't cause a catastrophic loss of everyone's
open TCP connections; my particular organization would probably be
taken out back and shot if we subjected users to that every day or
every few weeks.  How much pain is it worth to enable a DNS
renumbering mechanism which sucks too much to use?

---

From: "D. J. Bernstein" <[email-masked]>
Date: 29 Apr 2001 05:37:52 -0000

I'm cc'ing this to IPNG. It's up to IPNG to deprecate A6. Furthermore,
standardization activities should not be carried out on namedroppers,
for reasons discussed in http://cr.yp.to/djbdns/namedroppers.html.

Robert Elz writes:
> undisputed extra flexibility

We all agree that A6 is an extension to the DNS protocol. This does not
mean that it adds flexibility to DNS. Server-side indirection provides
the same functions with no protocol changes.

Paul Vixie writes:
> was: before it got put on the standards track,

That would have been a good time, but now is a good time too.

There is no guarantee that a protocol put on the standards track will
move along that track, or that it will stay on the track. In fact, under
IETF rules, protocols that want to advance are subject to more scrutiny,
not less.

The proponents of A6-everywhere think that they have the right to
deprecate AAAA. So why don't the proponents of AAAA-everywhere have the
right to deprecate A6?

> before a lot of code got written, and before a lot of operational
> deployment was put into various long and expensive pipelines.

So, because you and Microsoft have wasted time on a bad extension, every
other DNS implementor is required to waste time too? Including all
future DNS implementors?

---Dan

---

From: [email-masked]
Date: Sun, 29 Apr 2001 13:15:01 +0900

>long and expensive pipelines.

	for the last portion ("lot of operational deployment...") is yet to
	be done for A6, and i believe it very important to re-evaluate
	merits and demerits of AAAA/A6 before we really try to deply A6.
	i would like to thank for every efforts put for A6 codebase (BIND9),
	however, i see a lot of issues in deploying A6, and i personally have
	problem seeing merits of A6.
	we ran some experiments for renumbering, and the result made me
	believe that there's no such thing as "rapid renumbering".  network
	renubmer is a very very difficult thing.

	there are a lot of other protocols which (1) tries to upgrade other
	existing protocol and (2) has trouble in deployment because of some
	issues (like the previous protocol was too popular, previous protocol
	was enough, previous protocol was more suitable for the real world
	goals).  i won't give examples here, but i guess you can name a lot of
	examples.

itojun

---

From: Paul A Vixie <[email-masked]>
Date: Sat, 28 Apr 2001 22:14:16 -0700

> >... before a lot of operational deployment was put into various
> 	be done for A6,

i agree.  it's not "done".  it is however, by this time, "in various long
and expensive pipelines."  the commitment to A6 has been made in a number
of places.  this commitment would have been withheld in at least several
places i know of, had A6's optionality been publically known a year ago.

that makes the declaration of its optionality "feel like" a bait & switch.

operational deployment isn't done in a day.  there's a multi-year planning
cycle for something like IPv6.  and it's becoming apparent to me that some
folks inside IETF whose success with IPv6 depends on the good will, trust
and confidence of these planners, are just not aware of that dependence at
all.  again, i refer you all to the DSA-RSA-DSA-RSA "standards" in DNSSEC.

>	                   and i believe it very important to re-evaluate

sra, sob and i debated the merits of the A6-like approach in toronto, some
years ago.  ultimately we decided not to propose it because of its drawbacks.
matt crawford eventually came forward with a similar proposal, and its
drawbacks were pointed out and debated extensively.

the community decided to go forward with it.

anyone who didn't like the way the debate ended is welcome to add something
new to it and try to get a different result.  i have not, yet, heard anything
new against A6 in this round of the debate.

> 	renubmer is a very very difficult thing.

sure it's difficult.  nobody who eventually hummed in the affirmative about
A6 thought it was a magic bullet.  bill manning wrote some very good text
some years ago about the difficulties of rapid renumbering, all still valid.

but the thing that propped up the rapid adoption of IPv6 -- in spite of the
fact that it solves absolutely none of the known problems in the routing
system -- was rapid renumbering.  A6 was then set forth as the means by
which this would be achieved, and moreover, the means by which the routing
system's pain would be eased since multihoming would be a first order effect
and it would cease to matter who owned the address space you used day-to-day.

if we're going to abandon A6 then i for one am ready to listen to tony li's
"too little, too soon" comment, through IPv6 itself into the waste bin, and
go back to the whiteboard and solve more of the problems we actually have.
there is NO justification for the rapid and early adoption of IPv6 in its
present form unless A6 or something very much like A6 is made a part of it.

that your experiments showed that rapid renumbering isn't ready for prime
time does not surprise me even a little bit.  this stuff is all very raw.

but if the technical community plans to tell the business community and the
world at large that we want them to upgrade every router and every IP stack
in the universe and _still_have_ address ownership concerns whereby providers
can hold their customers hostage due to renumbering penalties, then we ought
to declare failure, pack up and go home, and hope the next generation can do
better.

---

From: Rob Austein <[email-masked]>
Date: Sun, 29 Apr 2001 14:23:22 -0400

Itojun,

Feel free to write the draft you mentioned.  I'd ask, though, that if
you do so, you please also consider how many of the perceived problems
with A6 become non-issues if we restrict use of A6 to the zero-prefix
case until and unless there is a demonstrable need to use non-zero
prefixes.  As you know, my concern with the "let's just retreat to
AAAA" proposal all along has been worry about deployment time if we
discover down the road that we do need the extra features of A6.

Sorry if you were expecting to hear more about the "case for A6" draft
by now.  I never expected to have anything done on it this early
(known day-job schedule issues in April and early May), but I failed
to communicate that to you when we discussed this in Minneapolis.

--Rob

---

From: [email-masked]
Date: Mon, 30 Apr 2001 11:05:14 +0900

>present form unless A6 or something very much like A6 is made a part of it.

	sorry, i cannot follow your logic here.  as far as i understand rapid
	renumbering was not the sole reason to pursue IPv6.  for me, bigger
	address space is the most important concern.  i have checked all
	IPng requirement documents (rfc17xx and 16xx) and i found no text
	that says "renumbering is the biggest concern".  is there really a
	large consensus on this?

	on the contrary, there are wording for routing table size.
	as far as i understand IPv6 addressing plan as well as 6bone routing
	guideline solves this portion of the problem.

itojun

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Apr 2001 06:07:10 -0000

Paul A Vixie writes:
> i have not, yet, heard anything new against A6 in this round of the debate.

http://cr.yp.to/djbdns/killa6.html

In January, Elz claimed that these issues were already covered in the
``IPNG, and perhaps DNSIND'' archives. I commented that I didn't see
server-side indirection discussed anywhere in the IPNG archives; I asked
when the discussion happened, and what benefits were attributed to
client-side indirection. Elz dodged both questions. Now we have Vixie
trying to pull a similar stunt.

Legitimate standards organizations never have any trouble showing people
the justifications for their decisions.

---Dan

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 30 Apr 2001 18:16:21 +0859 ()

Dan;

It's your problem.

> http://cr.yp.to/djbdns/killa6.html

How about:

	aol.com.	NS	ns0.aol.net.
	aol.com.	NS	ns1.aol.net.

	aol.net.	NS	ns0.aol.com.
	aol.net.	NS	ns1.aol.com.

?

> the justifications for their decisions.

As we already discussed with AXFR, you must put glue information in
a separate cache local to a zone (or, better, a referral). RFC 1034
does not prohibit to do so.

I thought you had already fixed your broken implementation.

							Masataka Ohta

---

From: Ian Jackson <[email-masked]>
Date: Mon, 30 Apr 2001 11:39:35 +0100 (BST)

[ could we please restrict the namedroppers discussion to the dns aspects,
  and not the v6 wars?  let's assume v6, whether we like it or not.  if
  you do, use the ipngwg list.  if not, use v6haters.  thanks.  -- rb ]

> the community decided to go forward with it.

Can you please give us references into the relevant list archives ?

> new against A6 in this round of the debate.

Asking A6 opponents to `add something new to the debate' is not
reasonable unless you can point us to where we can read what was said
already.

The namedroppers archives have practically nothing about RFC2874 that
I could find.  Surely the designs of A6, DNAME and bitstrings should
have been done here ?

> present form unless A6 or something very much like A6 is made a part of it.

I strongly disagree.  IPv6 is needed because we are running out of
IPv4 address space.  NAT has prolonged its life, but comes with a
whole pile of other problems - and it's nowadays mandatory to use NAT
because it's so hard to get globally routeable address space for all
hosts at a site.  But, if we want to argue these issues, the ipng
lists is probably the right place.

Ian.

---

From: David Terrell <[email-masked]>
Date: Mon, 30 Apr 2001 09:25:12 -0700

> > http://cr.yp.to/djbdns/killa6.html

In this case, ns[01].aol.{net,com} will be in the {net,com} zones as 
glue.

I think the question that I have yet to see answered that Dan is
not articulating well is "how the hell is DNS glue supposed to work
sanely with A6?"  I can't find an answer to that myself.  Everybody's
talking about no full IP addresses written anywhere, and DNS
delegation is one place where that just doesn't work.  You need the
full 128 bit address in there, and glue registry is the one place
that these addresses can't change frequently, because of the bulk
of TLD zones and complicated, time consuming procedures registrars
use to update those records... 

-- 
David Terrell            | "I went into Barnes and Noble to look for a 
Prime Minister, Nebcorp  | book on A.D.D., but I got bored and left." 
[email-masked]             | - Benjy Feen
http://wwn.nebcorp.com/  |

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 30 Apr 2001 09:45:10 -0700

> reasonable unless you can point us to where we can read what was said

alas, the ietf meeting minutes don't do this debate full justice.

> I could find.  Surely the designs of A6, DNAME and bitstrings should

A6/DNAME was an architecture proposed by matt crawford who is a member of
both DNSEXT (though it wasn't call that when this work was done) and IPNGWG.
it's not clear which working group's mailing list the discussion was held on.
however, the parts that were discussed in DNSEXT (called DNSIND at that time)
were just the DNS-relevant stuff -- would A6 and DNAME _work_as_specified_ --
whether they were necessary for IPv6 or would address IPv6's needs was outside
the scope of DNS.

to really deeply understand where A6/DNAME came from, read the archives and
meeting minutes of CIDRD, as well as BIGZ, as well as COM-PRIV, as well as
various "@sunroof" lists where IPNG was discussed, as long ago as 1990.

> IPv4 address space.

pfaa.  prove that.  that we do not have enough IPv4 address space for new
prospective uses of Internet-like technology, i agree.  but that these new
prospective uses are barrelling down the pike at us so quickly that we can
afford to ignore the problems of address ownership and portability just to
standardize on technology that expands the address space pool, i DISagree.

> NAT has prolonged its life, but comes with a whole pile of other problems
> - and it's nowadays mandatory to use NAT because it's so hard to get
> globally routeable address space for all hosts at a site.  But, if we
> want to argue these issues, the ipng lists is probably the right place.

and that argument has raged for most of a decade without clear resolution.
i only wish "global routeable address space" were SIMPLY a problem of how
many bits we had available in the datagram source and destination addresses.

don't anybody mistake me for an IPv6 naysayer.  but for IPv6 to be worth
deploying, somebody is going to have to come up with a system whereby routers
in the defaultless core of the internet can have fewer than 1*10^6 routes --
we're at 1*10^5 now and an order of magnitude is within reach of the CAMs we
see on various drawing boards.  2^64 > 1*10^5, however.  this means address
space will continue to be owned.  this in turn means that transit customers
must have an easy way to add or drop "address space owners".  this in turn
takes us all the way back (sherman, set the wayback machine for 1991) to the
endless raging debate about endpoint identifiers.  ick.  on second thought,
DON'T set the wayback machine for 1991.

---

From: "Matt Crawford" <[email-masked]>
Date: Mon, 30 Apr 2001 11:49:51 -0500

> talking about no full IP addresses written anywhere, 

Whoa!  Who is this "everybody"?

> and DNS delegation is one place where that just doesn't work.  You
> need the full 128 bit address in there, and glue registry is the
> one place that these addresses can't change frequently, because of
> the bulk of TLD zones and complicated, time consuming procedures
> registrars use to update those records...

I think you aren't intending to make a case in favor of well-
segemented A6 chains, but your ellipsis could be completed in exactly
that way.  Then if you the end site choose to renumber, you're
responsible for coordinating the TLD's glue.  If renumbering is
thrust upon you because your ISP is renumbering, they are responsible
for it.  And if the glue record of concern is the very same one they
use for their own DNS infrastructure, the right sort of motivations
are in place.

But never mind that, because the world isn't ready to play that way
and it isn't what RFC 2874, section 5.1.2 suggests:

5.1.2.  Glue

   When, as is common, some or all DNS servers for X.EXAMPLE are within
   the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
   enough "glue" information to enable DNS clients to reach those
   nameservers.  This is true in IPv6 just as in IPv4.  However, the A6
   record affords the DNS administrator some choices.  The glue could be
   any of

   o  a minimal set of A6 records duplicated from the X.EXAMPLE zone,

   o  a (possibly smaller) set of records which collapse the structure
      of that minimal set,

   o  or a set of A6 records with prefix length zero, giving the entire
      global addresses of the servers.

   The trade-off is ease of maintenance against robustness.  The best
   and worst of both may be had together by implementing either the
   first or second option together with the third.  To illustrate the
   ...

   If the EXAMPLE zone includes redundant glue, for instance the union
   of the A6 records of the first and third options, then under normal
   circumstances duplicate IPv6 addresses will be derived by DNS
   clients.  But if provider DNS fails, addresses will still be obtained
   from the zero-prefix-length records, while if the EXAMPLE zone lags
   behind a renumbering of X.EXAMPLE, half of the addresses obtained by
   DNS clients will still be up-to-date.

   The zero-prefix-length glue records can of course be automatically
   generated and/or checked in practice.