Subject: Re: AAAA/A6 thing

From: Dan Lanciani <[email-masked]>
Date: Wed, 2 May 2001 02:55:05 -0400 (EDT)

Robert Elz <[email-masked]> wrote:

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

I understand what you mean, but it implies that there are no alternatives
to non-portable, unstable address space.  If this is true then indeed
renumbering has to work transparently, but it isn't clear that there aren't
other solutions to the core problem.

|(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 wouldn't count on much gain from the one-time event.  Anyone who currently
owns portable IPv4 address space isn't going to give it up without a fight.
Everybody else is already using "sane" addresses from an aggregation point
of view.

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

You've just identified exactly "what is going on with renumbering."  Transparent
renumbering (i.e., renumbering that works for rather than against the end user)
has to remain forever just around the corner.  It has to be on its way to make
unstable IPv6 address space palatable.  But it can never arrive because that
would upset the delicate economics of stable addresses.  This has been going on
for years.

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

This is not progress.  Router renumbering gives ISPs a tool to conveniently
change your addresses out from under you if you haven't paid a premium for
stable address space.  It does little to help the end user.  Real progress
would mean solving the much harder end-node renumbering problem with all
that entails at the protocol and application level.

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

This is the model that ISPs are promoting.  If you want to do anything
interesting you need static address space, and you are going to pay for it.
(Of course, you have to beg for the privilege of paying for it and it still
isn't portable.)

|Hence we're still occasionally seeing calls for portable IPv6 addresses.

People recognize that at some level you need an identifier that you can
call your own.  At the moment, the DNS doesn't quite do it.  A few years
ago I proposed a portable identifier mechanism that would have solved the
renumbering problem, the multi-homed problem, and the mobility problem.
Nobody seemed interested.  Now that a few large companies have patented
the idea, perhaps it will take off.  (Unfortunately, they seem to have tweaked
the protocol a bit to insure that you need an identifier in a small fixed
number space, and I assume you will be paying them for that...)

|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

We've needed that for a long time...

|(for which "buy more RAM" is not even half a solution of course).

This is true but misleading.  It is misleading because of the unstated
implication that the problem can't be solved by throwing bigger hardware
at it, and this is still open to debate.  It is true mainly because a router
vendor (who shall remain nameless) made a practice of providing extremely
limited RAM expansion capability in its products.  It is also true because
we still use routing protocols that consume copious resources yet provide
minimal functionality.  The latter is exacerbated by attempts to compensate
for the protocols' shortcomings with filters and flapping penalties.  In
many cases this reduces routing to a highly-damped unreachability computation
that still seems to cost too much to run.  So while you may not be able to
simply buy more RAM, you can likely buy a new router for much less than you
would pay for the RAM expansion if it existed.  And we could improve the
routing protocols.

Back when address aggregation was introduced for IPv4 it was billed as
temporary hack to slow the growth of the routing tables until hardware
had caught up.  CIDR block addresses were _not_ supposed to be non-portable.
When you switched providers you were supposed to be able to take your address
block with you.  The reasoning was that this would happen slowly enough that
there would not be significant fragmentation before the hardware caught up.
Well, the hardware has caught up but aggregation--like a "temporary" tax
increase--has remained.  And you can't take your address block with you
because it "defeats the purpose" (whatever the purpose is now).  Rather
than attempt to solve the routing problem, IPv6 as currently envisioned
simply redefines the temporary hack as a feature of the routing architecture.
It expands the address space bit-wise, but preserves the economics of address
allocation.

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

Oh, I'm sure we'll keep working on little pieces, virtually guaranteeing
that there will never be a comprehensive solution.  As long as it looks
like we are making progress...

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

A6 is just one more minor hand-wave implying that things might all work at
some point in the future when we solve the real problems.

Tim Chown <[email-masked]> wrote:

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

Why shouldn't you?

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

Certainly they know that.  That and the sale of address space are the
two main benefits of aggregation.

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

Of course NAT will be used with IPv6.  Why pay a per-address fee and then
an additional fee to keep the address stable (at least in the short term)
when you can maintain your own internal addresses with NAT?  NAT is the
thorn in the side of the ISPs' accountants.  Many people like to talk about
NAT's architectural impurity, but the bottom line is that it works fine for
most applications.  NAT is the market's reaction to the (artificially) high
price of address space.  Apparently there was some expectation that addresses
were a hard resource that people would pay anything for since they couldn't
live without them.  It didn't work out that way.  Now there seems to be some
expectation that people will trade in their NATs for shiny new public per-host
IPv6 addresses (that the ISP can charge for and renumber of a whim) just because
there are more address bits.  This isn't going to happen either.  Those who
take offense at NAT's impurity can make it go away quite simply: just give
people stable, portable address space...

				Dan Lanciani
				[email-masked]

--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Fri, 04 May 2001 14:55:17 +0700

Date:        Wed, 2 May 2001 02:55:05 -0400 (EDT)
    From:        Dan Lanciani <[email-masked]>
    Message-ID:  <[email-masked]>

  | I understand what you mean, but it implies that there are no alternatives
  | to non-portable, unstable address space.  If this is true then indeed
  | renumbering has to work transparently, but it isn't clear that there aren't
  | other solutions to the core problem.

No, there might very well be some.  It would be real nice if there were.

But right now, I don't see one on the horizon, and I know that I don't
have the background or ability to find another solution - whereas I do
(immodestly) think I have the ability to identify at least some of the
issues that make renumbering harder than it should be, and at least
agitate to have them corrected.

  | I wouldn't count on much gain from the one-time event.

Nor would I really, and certainly not in the grand scheme of things.

  | Anyone who currently
  | owns portable IPv4 address space isn't going to give it up without a fight.

No, but that isn't v6 address space, so it isn't really relevant to the
immediate issue.   It may be that in the distant future there are still
people clinging to their v4 address space, and tunnelling it over whatever
the internet is built out of at the time.

Currently there's no way to get portable IPv6 address space, so people
attempting to own that is a non-issue (now anyway).

  | This is not progress.  Router renumbering gives ISPs a tool to conveniently
  | change your addresses out from under you if you haven't paid a premium for
  | stable address space.

I don't think I'd quite go that far - it gives me a tool to help me
renumber my site a little easier if that is forced upon me (for whatever
reason).   I don't think it quite allows an ISP to do that without my
consent.   But maybe I missed something in the RFC?

  | Real progress
  | would mean solving the much harder end-node renumbering problem with all
  | that entails at the protocol and application level.

Certainly.   But this may be an issue where real progress is built of
a very large number of very tiny steps, rather any any single quantum leap
forward.

  | This is the model that ISPs are promoting.  If you want to do anything
  | interesting you need static address space, and you are going to pay for it.
  | (Of course, you have to beg for the privilege of paying for it and it still
  | isn't portable.)

Yes, I can see that as an attractive model for some people.   Personally, if
we can make renumbering work well enough, then I don't think I'll care if
my address changes every now and again.

But I suspect you're also thinking of the "I am going to stop you running
a server" mentality of some ISPs - the dhcp lists get questions from them
along the lines of "how to I force (dhcp) clients to give up their old address
and get a new (different) one every few hours?"   That's for exactly that
purpose.   Of course, this is because they're designing a service, and
supplying bandwidth, and then charging the customers, based upon the
assumption that they're a (current) "typical home user" - ie: someone who
sends and gets a bit of e-mail, and browses the web a bit.  The e-mail is
insignificant and irrelevant in the grand scheme of things, and the web
browsing all just bangs on the local proxy cache.  Hence cheap rates
are possible.

Have a few users start running servers (or for that matter, participating
much in any other protocols - but for now, what matters is people running
their own web servers) and all the planning is out the door, that traffic
is real traffic over the ISP's WAN links.   So, the ISP has to stop that,
and the (technical) way they latch onto is frequent renumbering of the
client's address space (it is a bit difficult to run a server when you
never know what your address will be from hour to hour).

But none of that really has much to do with renumbering ease, or IPv6.
That kind of ISP meets a need in society, and I expect will continue to
exist.   There are other ISPs around (often charging more, as you'd
expect) who don't do this kind of thing.  And as you point out, often
ISPs run both kinds of service - you pay more you can have a stable address
(ie: you can run a server), you pay less, and you can't.

I don't think we should dwell on those issues - you're not going to get
a stable address for the cheap (no server) service if the ISP can find any
way to cause it to vary, no matter how easy or hard renumbering is, as it
isn't address stability that is the issue/problem there - it is traffic.

  | People recognize that at some level you need an identifier that you can
  | call your own.  At the moment, the DNS doesn't quite do it.

Then let's make it, as much as is reasonable.   Personally I don't think
it will work well as a connection identifier (though people have proposed
using DNS names for that), but it ought to at least be able ti function
everywhere anyone needs a long term stable record of an identifier.

  | A few years ago I proposed a portable identifier mechanism

There have been many of those over the years - look in the big-internet
archives for all the discussions on EIDs.   It would certainly be an
attractive thing to do, but there are undoubtably also problems that need
to be solved to make them practical.

  | This is true but misleading.  It is misleading because of the unstated
  | implication that the problem can't be solved by throwing bigger hardware
  | at it, and this is still open to debate.

Yes.   And while it is true that hardware has been keeping up with the
current growth, it is also true that current growth has been constrained
heavily - I'm not sure that even the best we could do with hardware now
would manage to cope with what the tables would look like if everyone with
an internet connection owned their own stable address (the way we used to).

  | And we could improve the routing protocols.

Yes.   But to date we haven't.

  | Back when address aggregation was introduced for IPv4 it was billed as
  | temporary hack to slow the growth of the routing tables until hardware
  | had caught up.  CIDR block addresses were _not_ supposed to be non-portable.

yes.   I know.   I recall the promises that that would never happen.

  | Rather than attempt to solve the routing problem, IPv6 as currently
  | envisioned simply redefines the temporary hack as a feature of the
  | routing architecture.

Yes.   That's absolutely true.   But it isn't a design aim of IPv6
to do that, it is just that no-one has yet proposed any other good
solution to the routing problem.    The closest I think we came was
with PIP, which moved it all out of the routers and into the hosts.
Needless to say, while that had some support, there wasn't a lot of
it - quite apart from any possible economic or self-interest motives,
that would have been a huge change - and most people simply dread
even a little change, let alone a huge one moving in a direction that
no-one has gone before.  FUD works.

  | It expands the address space bit-wise, but preserves the economics
  | of address allocation.

I know what you mean (given the context) - but that isn't quite true.
There's another issue here that does change, radically.   With IPv4
you not only pay for stable addresses if you want them (really for the
ability to run a server) and even more for portable addresses - but you
also pay for the number of addresses you want allocated.   The last of
those will vanish with v6 - there's simply no rational way for an address
block smaller than 2^64 (other than perhaps 1) to be allocated.  Even
if ISPs were to allocate in 2^64 chunks (rather than the 2^80 they're
supposed to) and you have to engage in some trickery to map your systems
onto subnets in the /64 space you get, you still have enough address
space to number every system you're ever going to want to connect (and
never re-use a number).

  | Oh, I'm sure we'll keep working on little pieces, virtually guaranteeing
  | that there will never be a comprehensive solution.  As long as it looks
  | like we are making progress...

If we keep solving the little pieces, we are making progress.  They won't
get unsolved once they're done.    But that doesn't mean that someone can't
go and make all of this work redundant by figuring out some smart way to
route to billions (of billions) (like 2^48 at least, 2^64 potentially)
individual addresses with no topological significance at all.   If there's
someone out there with the solution all ready just waiting, then please,
let us know (even patent it, and then let us know).

  | A6 is just one more minor hand-wave implying that things might all work at
  | some point in the future when we solve the real problems.

You can put it that way - it just makes one of the (minor) parts of the
problem that little bit easier to handle.

  | Of course NAT will be used with IPv6.  Why pay a per-address fee and then
  | an additional fee to keep the address stable (at least in the short term)
  | when you can maintain your own internal addresses with NAT?

The "keep the address stable" part isn't helped at all by NAT.   The
only advantage to stable addresses (aside from the problem of renumbering
your site) is where it is known to others.   That is, so connections can
remain open, or people can contact you by the address they know.

For most sites renumbering internally is already cheap - they simply don't
have enough systems for the small cost per system (say average 10 minutes
of human time) multiplied by the number of systems to be large enough to
really matter.  With IPv6 that will be even easier (without question), as
most nodes won't even need to be touched, or reboot, nor need internal
communications be affected (if they're using site local addresses for that
purpose).

Now I have no doubt but that when the bean counters in many ISPs were told
that they had to start allocating addresses now, they immediately asked
"how much can we change for that?  Can we make a profit doing it?  A big
profit??" - and that many operate that way today.  They probably even use
that to subsidise their other activities.   But address selling has never
been a core activity of an ISP, that's not what they exist for.  Further,
since addresses are just numbers, any ISP charging "too much" for numbers
can easily be undercut by another charging just that little bit less.
With IPv6 that will be much more true, as there are so many numbers
available.   As well as not being any kind of routing expert, I'm also
certainly no economist, but it is hard to see how charges higher than
"trivial" for address space can survive any kind of competitive market
given that there's plenty of address space to go around.   Of course,
when it is scarce (really scarce - and IPv4 address space is in much of
the world) that's another matter.   Of course, nor will that prevent
ISPs (and others) making huge profits out of it - even a trivial sum
collected enough times can get very large - the sum is trivial to the
customer (small enough not to bother shopping around much), but that
doesn't mean that it necessarily only just covers the costs.

kre