Subject: Re: AAAA/A6 thing

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

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

	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
--------------------------------------------------------------------
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: Randy Bush <[email-masked]>
Date: Mon, 30 Apr 2001 05:53:42 +0200

[ namedroppers removed from cc: ]

> guideline solves this portion of the problem.

unfortunately, operators seem unable to realize this.  if there is the same
amount and trend of multi-homing, and the same routing protocols, and the
same mass of multiply-connected providers, their lack of perception would
seem to be understandable.

randy

---

From: "JIM FLEMING" <[email-masked]>
Date: Mon, 30 Apr 2001 01:12:47 -0500

I thought the main reason for IPv6 was so that people could write RFCs
and get paid to travel all around the world, imposing their complexity on
others...

Jim Fleming
http://www.unir.com
Mars 128n 128e
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp

---

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: Robert Elz <[email-masked]>
Date: Mon, 30 Apr 2001 18:02:02 +0700

Date:        Mon, 30 Apr 2001 05:53:42 +0200
    From:        Randy Bush <[email-masked]>
    Message-ID:  <[email-masked]>

  | > 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.
  | 
  | unfortunately, operators seem unable to realize this.  if there is the same
  | amount and trend of multi-homing, and the same routing protocols, and the
  | same mass of multiply-connected providers, their lack of perception would
  | seem to be understandable.

Yes - we also need renumbering to work under IPv6 for the (current only)
routing table growth size problem to be helped by IPv6.

(That is, aside from the one time transitional help caused by everyone
doing an initial renumber into a topologically sane address when they
first start running IPv6).

I have been trying to fathom what is going on with renumbering - there seems
recently to have been some kind of "well, it turns out that we can't
renumber an IPv6 network every day, and if we think about it, we'll never
actually need to anyway, so we can stop worrying about renumbering".

That's nonsense.

Renumbering is still important, and still needs to become one of the main
features of v6 - that we haven't actually achieved a lot yet just makes
it even more urgent.

We started real well, with autoconfiguration, so we don't have to go sticking
a host's IPv6 addresses in a config file on every host (or DHCP server).
That's all implemented everywhere I know of, works fine, ...

Then we went a bit further with router renumbering, to provide a mechanism
to get a renumbering event distributed to the routers of an organisation
more seamlessly - that's newer, but is still not a lot implemented that I'm
aware of (though unless we're all unlucky, it should be coming).

Then we have giant setbacks, like the "embedding IPv6 literals in URLs"
nonsense, that is 100% the wrong thing to be doing if we want to be able
to change the addresses in any kind of reasonable way.

It seems that some people have looked at the renumbering problem, decided
that it is still real hard (it is), and thought "if I just get a stable
IPv6 address and keep it forever, I'll never have to worry about that".
Hence we're still occasionally seeing calls for portable IPv6 addresses.

If that was to be the result, then we need (very very quickly) some entirely
new routing methodology which will solve the routing table growth problems
(for which "buy more RAM" is not even half a solution of course).

Or, we need to keep working on the renumbering problem - keep finding little
pieces of what makes it difficult, and fixing them, until it is no longer
so difficult.  One step at a time...   Intrinsically it can't be difficult
after all, we can take a network with no number, and give it one, and start
using the thing very easily.  So the problems that exist cannot be
intractable, provided we're willing to take a pragmatic approach, and be
willing to change some of our current behaviour (like embedding literal
addresses all over the place - including in URLs).

Of course, whatever solutions we find for this for IPv6 would also be
applicable to IPv4 in most cases - except that IPv4 still has the address
size limitations.

Finally, everyone please recall to pieces of ancient history.   First,
rfc1900 (from 1996, which remains as true today as it did then).
And second, that before IPngwg, before the SIP PIP and TUBA wg's, was the
ROAD wg - that which set all of this in motion.  ROAD was "Routing and
Addressing" - the two problems that needed solving.   We haven't finished
until both of those have been ticked off.

kre

ps: A6 is just one more minor step in making renumbering just that little
bit easier - or will be, once we demonstrate that it really does work, and
start deploying it in some form or other.

---

From: Tim Chown <[email-masked]>
Date: Mon, 30 Apr 2001 13:20:54 +0100 (BST)

> to change the addresses in any kind of reasonable way.

In some cases, a site's IP numbering is likely to remain quite static for
significant periods of time.  My University has been on the same 16-bit
network (152.78.0.0) for at least ten years, and I don't see that that
will change in the foreseeable future.

That's a site with ~10K IP-connected devices, using pretty much every
host OS you could imagine.  The biggest problem with renumbering comes
with the subtle, yet large, number of places that IP addresses are hard
coded in various config files on Unix/NT systems.  That's a significant
problem to overcome.  But luckily it's not a problem we're likely to face.
Aside from the little issue of IPv6 migration :-)

As a side-line I run a small ISP, and that's where the renumbering problem
kicks in, because I want to get the best leased line deal that I can on
an annual basis, but I don't have the leverage to demand to take my
Class C with me to a new provider (nor should I) as I probably could with
a Class B size address.  The providers know that the cost of moving to a
new provider is high, because of renumbering.   

As a result, I get quite tempted to run 1:1 NAT, simply to make moving to a 
new provider easier.  I haven't done that, but I expect many small ISPs do.  
If application (and firewall) developers don't reduce the dependency on
hard-coded IP addresses, then it's probable that some form of IPv6 NAT will 
be used to map site-locals when IPv6 comes into common usage, as horrific 
as that may sound to some.

And if a University-scale site did renumber, I shudder to think of the
number of places that IPs would be embedded, and the manpower cost of
renumbering, even with A6, autoconfiguration and secure router renumbering.

Tim

---

From: Robert Elz <[email-masked]>
Date: Mon, 30 Apr 2001 19:55:27 +0700

Date:        Mon, 30 Apr 2001 13:20:54 +0100 (BST)
    From:        Tim Chown <[email-masked]>
    Message-ID:  <[email-masked]>

  | In some cases, a site's IP numbering is likely to remain quite static for
  | significant periods of time.

Yes, it is.

  | My University has been on the same 16-bit network (152.78.0.0) for
  | at least ten years,

My (home) university has been using its class B for longer than that
(it is a 128.x number ...) and it will never change while IPv4 remains.

Yet we have altered providers several times through history, and will
do so again for sure.

That means that the whole rest of the Internet universe (except those who
use default routes for most routing) have to carry around a route to
our network (and yours), and then go and recompute the routing table every
time some glitch drops one of us off the network for a few minutes (or just
changes the path by which we're reached).

I'm not sure that it is reasonable for even a large university to impose
that kind of burden on the rest of the world.   With IPv4 it is never
going to change of course, but IPv4 simply has to die sometime (it doesn't
have enough addresses even if everyone was using NAT for their networks,
2^32 isn't sufficient just to number all the NAT boxes that the world will
need sometime in the future).

  | The biggest problem with renumbering comes
  | with the subtle, yet large, number of places that IP addresses are hard
  | coded in various config files on Unix/NT systems.

No, that's the small problem.   It is a nuisance, and a lot of work,
but is comparatively easy to fix ... you just renumber each box, one at
a time, and keep working at it until it works - then go on to the next.
Costly, but possible.

The big problem is that it is entirely possible that I have either your
old, or your new, IP address in my router filter lists, or e-mail anti-spam
lists, or ...

When you renumber your network, I have to adjust the configuration at my
end - and you know nothing about that at all (so you can't tell me it is
time to update my config) and I of course have no rational way to find out
that you have renumbered (there are plenty of numbers in my router config
lists that I never knew who they belonged to, so I can't just look and
see if they have changed owners).

I have already seen an experience from one user who found their IP address
was one one of (the more incompetent of) the anti-spam lists.   They had
no idea why, having only just recently connected to the net, and never
having run an open relay or anything like that.   Never thought that perhaps
the number had been used by someone else in the past.   (This case turned
out to be worse than that - turned out the ISP was doing NAT without
telling anyone, so the number that was being blocked wasn't the actual number
the user thought he was using (which wasn't a 1918 number), but the public
side of the NAT box - which was also doing port remapping, so the IP address
being blocked was being shared by who knows how many users).

  | As a side-line I run a small ISP, and that's where the renumbering problem
  | kicks in, because I want to get the best leased line deal that I can on
  | an annual basis, but I don't have the leverage to demand to take my
  | Class C with me to a new provider (nor should I) as I probably could with
  | a Class B size address.  The providers know that the cost of moving to a
  | new provider is high, because of renumbering.

Yes.

  | As a result, I get quite tempted to run 1:1 NAT, simply to make moving to a 
  | new provider easier.

A lot of people do exactly that.   Of course they can also justify it on
the grounds of insufficient available address space.  It is truly unfortunate
that (I suspect) perhaps a majority of the current internet users have never
used a NAT free connection.

  | If application (and firewall) developers don't reduce the dependency on
  | hard-coded IP addresses, then it's probable that some form of IPv6 NAT will 
  | be used to map site-locals when IPv6 comes into common usage, as horrific 
  | as that may sound to some.

Yes, it is a frightening but real prospect - though I doubt site-locals
would turn out to be useful for that (nodes will only use them when
sending to other site locals).  More likely that sites would simply
invent a private global address for themselves, then remap it into their
provider supplied address.  Horrible thought.  Unfortunately, it is
likely to happen (probably has already happened) - people have become
so used to NAT that it is often seen as a feature, rather than the crude
hack that breaks things which it is.

Of course, none of this NAT renumbering solves the difficult problem
I mentioned above - even if all you have to renumber is your NAT box,
my config files still contain addresses that should be changed, that
you don't know about.  So your cost might decrease a bit (or a lot),
but the renumbering isn't really finished.

  | And if a University-scale site did renumber, I shudder to think of the
  | number of places that IPs would be embedded, and the manpower cost of
  | renumbering, even with A6, autoconfiguration and secure router renumbering.

Yes - we really need string pressure on implementors at all levels of the
stack to avoid using literal addresses anyplace they can possibly be avoided,
and instead use a dynamic translation mechanism - for everything, with perhaps
the sole exception of an address that a human has actually typed immediately
before it is used, and of course, the assignment of TLAs.

kre

---

From: Randy Bush <[email-masked]>
Date: Mon, 30 Apr 2001 16:51:27 +0200

> routing table growth size problem to be helped by IPv6.

renumbering?  did i say renumbering?  i sure did not mean to.

as far as i can tell, ipv6 gives us more address bits, and not a lot else,
in fact some regressive limits.  but we could need more address bits very
badly.  and we don't have a better plan.

randy

---

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/  |
--------------------------------------------------------------------
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: "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.
--------------------------------------------------------------------
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: "David R. Conrad" <[email-masked]>
Date: Mon, 30 Apr 2001 11:51:45 -0700

Itojun,

>         on the contrary, there are wording for routing table size.

Renumbering is a means to address the routing table size problem (of 
course, renumbering doesn't help the multi-homing problem).

>         guideline solves this portion of the problem.

My understanding is that IPv6 uses the same routing technology as IPv4 and 
is only marginally easier to renumber than IPv4, hence the routing table 
problem is not addressed.

Rgds,
-drc

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Apr 2001 19:09:48 -0000

Ohta is wrong. This is a bug in the protocol, not in any particular
implementation. All of my comments apply to BIND's A6 implementation;
BIND discards out-of-bailiwick records for security, just as djbdns
does. Ohta's ``fix'' comments are nonsense.

As for non-A6 examples: http://cr.yp.to/djbdns/killa6.html already
covers this, and explains why A6 and DNAME make the problem much worse.
See the ``DNS reliability problems'' section.

---Dan

---

From: "JIM FLEMING" <[email-masked]>
Date: Mon, 30 Apr 2001 16:16:19 -0500

----- Original Message ----- 
From: "David R. Conrad" <[email-masked]>
> 
> My understanding is that IPv6 uses the same routing technology as IPv4 

IPv4 and IPv6 do not do "routing" they do "forwarding"...
...some people know the difference...

Jim Fleming
http://www.unir.com
Mars 128n 128e

---

From: Jim Bound <[email-masked]>
Date: Mon, 30 Apr 2001 22:08:47 -0400 (EDT)

Randy,

You may be right you may be wrong.  But IPv6 is going to start being
deployed so we will find all this out real soon.  Should be fun.  I think
we will be fine.  You should come to one of the IPv6 summits and hear the
Advantage discussion of IPv6 sometime.

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 30 Apr 2001 22:14:39 -0400 (EDT)

Folks,

Right or wrong.  Paul's comment is valid.  A6 will be deployed at least on
BIND (well it is now actually) and on Microsofts DNS is my read.  

As one of the people to fund BIND future development and with others we
believe it should not be implemented for greater than 3 levels of
hierarchy till more testing and experimentation is done. But A6 will be
shipped on the street and its a done deal.

Do I like A6 no.
Do I think a better solution exists yes.
But do I advocate deployment of A6 yes.
Why because its time to move forward.

I also thought continuing private address space was a bad idea in v6. I
still do.  KNow what I hope to help build that feature in our products.

The Internet is crumbling under to many NAT and VPN peek-a-boo packets and
we need to get IPv6 on the street.  It is happening now.  Will happen a
lot by the end of this year.  U.S. may be last to do it but thats ok they
will do it too eventually.

The real work we can do is elsewhere now like Multihoming and MIPv6.

regards,

/jim

---

From: Matthew Darwin <[email-masked]>
Date: Mon, 30 Apr 2001 22:19:18 -0400 (EDT)

On Mon, 30 Apr 2001, Jim Bound wrote:

> What will not get done here is to get users to not embed addresses in
> configs and there is no incentive for vendors to prevent them from doing
> it.

Does anyone know that the network management platforms are planning to do
with this renumbering concept?  I would expect that most of them key
devices by IP address, or am I wrong?

---

From: Jim Bound <[email-masked]>
Date: Mon, 30 Apr 2001 22:06:27 -0400 (EDT)

Tim,

Good points. We have renumbering for the LAN.  We have a way to renumber
from the border routers within a domain.  This will get us started for
deployment.  Baby steps are all we can take.  If the IETF can extend these
to grown-up steps great.  But we will start deployment now with what we
got and its already better than IPv4.

I would think someone should put out a draft on all this and state whats
missing and what needs to be done.

regards,

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 30 Apr 2001 22:22:44 -0400 (EDT)

Dave,

With all due respect IPv6 is far superior to IPv4 for renumbering.
Have you looked in depth at Neighbor Discovery, Stateless
Autoconfiguration, and Router Renumbering RFCs.  Then put them all
together.  Nothing I mean Nothing exists like this in IPv4. 

We have never said we solved all the renumbering problems.  Nor did we say
we would.  Steve Deering has sent a few mails to this list and to the IPv6
Forum on this and it appears no one listens.

We are far better off than IPv4 though.

Also Itojun is 100% correct.  The reason IPv6 will be and has begun
deployment is because of "address space".  Its the primary motivator. Then
all the other stuff we have some don't seem to see is icing on the cake.

/jim

---

From: [email-masked]
Date: Tue, 01 May 2001 11:26:38 +0900

>missing and what needs to be done.

	regarding to renumbering, there was a draft by Fred Baker (was it on
	i-d repository?), as well as a presentation by jinmei (IETF49?).
	the draft/presentation describes timing constraints and steps
	necessary for renumbering a leaf site.
	yes, it is far better than IPv4 case, but...

>configs and there is no incentive for vendors to prevent them from doing

	it is very hard to ensure it, and there are wacky timing constraints
	(specifically interactions with DNS cache TTL).

itojun

---

From: Jim Bound <[email-masked]>
Date: Mon, 30 Apr 2001 22:37:43 -0400 (EDT)

Itojun,

Good point.  I saw Fred's draft and reviewed it before it came out. It is
very good.  I did not know if it actually got sent out?  Hmm. I could not
find it.  It is very good and also gives very good technical and scientfic
analysis of the problem?

Fred if your still with us on IPng is the ID still available?

/jim

---

From: [email-masked]
Date: Tue, 01 May 2001 11:48:52 +0900

>to change the addresses in any kind of reasonable way.

	my understanding is that there are needs only when we debug web servers.
	maybe we should put some wording into RFC2732+, that says "it is
	not recommended for daily use, use FQDN".

itojun

---

From: "D. J. Bernstein" <[email-masked]>
Date: 1 May 2001 03:11:12 -0000

Jim Bound writes:
> But A6 will be shipped on the street and its a done deal.

No, it is not. IPNG can terminate the A6/DNAME proposals right now.
Users will continue to rely on AAAA, not on A6 and DNAME.

> we believe it should not be implemented for greater than 3 levels of
> hierarchy

Even a single level of A6 indirection is dangerous. See my example of
AOL committing suicide at the top of http://cr.yp.to/djbdns/killa6.html.
I can't imagine what you think a 3-level limit would accomplish.

> As one of the people to fund BIND future development

Thank you for disclosing your financial interests. Did you know that
United States antitrust law prohibits packing standards committees?

---Dan

---

From: Jim Bound <[email-masked]>
Date: Mon, 30 Apr 2001 23:25:52 -0400 (EDT)

bind is not a standard.  its a public domain implementation funded by
public money.  

/jim

---

From: Jim Bound <[email-masked]>
Date: Mon, 30 Apr 2001 23:30:05 -0400 (EDT)

dan,

I will not argue against you or for you.  Last I will say your correct.
But they are not going to listen to you here.  I am out of it. Everyones
using AAAA anyway.  If you can change the minds of these here best of luck
to you.  But I bet I hear this debate again a year from now with no
resolution.  Its too bad but that is the way it is and why I try to reduce
the work I have to do here.

I am not pro bind or pro bernstein or pro microsoft DNS I am pro IPv6
deployment thats all. bind is just what most have deployed.  Its just good
enough but can be made better I think.

/jim