[ppml] Get you IPv6 Today, lets update the policy

[Phil Howard]

On Wed, Jan 08, 2003 at 02:50:30PM -0500, Thomas Narten wrote:

| Phil Howard <phil-arin-ppml at ipal.net> writes:
| 
| > | > So the first barrier is that you must be a ARIN customer
| > | 
| > | This is not the case.  In the ARIN region you do not first have to be a
| > | customer of the RIR to request Internet addressing resources.
| 
| > What's not clear is whether the address space I might be able to get
| > will be the permanent space.
| 
| What space is permanent? No IPv6 space is "permanent" in the sense
| that you will be guaranteed to always have it and that it will always
| be routable. If you are an endsite, your ISP might fold and the
| addresses might stop working.

That can happen.  That's why I want permanent addresses, to avoid that.

| You might change ISPs and renumber (over
| a period of months), etc. Even if you are an ISP, at some point other
| ISPs might decide that the routing tables have become too large and
| unmanagable and that your prefix is too small to be worth
| carrying. One hopes these things don't happen, but some of them no
| doubt will at some time.

I thought that IPv6 was supposed to be large enough that everyone could
have the same size prefix, and it still be large enough that one single
entity would have all they would ever need.

I *can* do everything I need to do on a handful of addresses, probably
even just 2.  The problem is, they aren't portable and they aren't
permanent.  What's in IPv6 for me?  If it doesn't solve those things,
then it doesn't solve anything for me.

And this is what a lot of people I know see IPv6 as being.  Sure, it
got rolling from a shortage of IPv4 address space.  But that problem
was "solved" (the technology exists, if deployed, to make IPv4 last
probably another 20 years).

The problem paradigm shifted.  Quantity of address space isn't nearly
the problem it once appeared to be.  Quality of address space is where
I see the issue being now.  Permanency (as long as I keep using it or
keep up payments on it, much like a domain name) and portability (I
can switch ISP and I don't have to go back to my registrar and tell
them what the new IPs are for my name servers).


| > I'm really not interested in that level of "experimentation".  I'd
| > rather be doing in in "learning mode" instead of "research mode".
| > I want to make the commitment to move forward, and do what I can to
| > make it happen.  But that won't happen for me with 6bone.
| 
| Actually, if you read the 6bone is all about, "learning" is one of the
| things it is supposed to foster. www.6bone.net.

I'll go back and read it again.  I did so a few years ago and it was a
big turnoff to me.


| > The kind of services I focus on now don't justify it.  But I still need
| > portable space.  The problem is there is still discontinuity in what
| > much of IPv6 is supposed to be about (at least as I saw it) and what
| > ARIN policy is.
| 
| You say something key above. You want portable space. There is no such
| thing in IPv6 (and arguably, not even in IPv4). What you can get is
| space that is routable, today. Whether it will continue to be routable
| forever, depends on a lot of things, like  growth of the routing
| tables. We simply do not have a technology  that allows  everyone to
| get a "portable" address that will work forever.

IMHO, maybe IPv6 needs to go back to the drawing board.  Right now it
comes across as "tomorrow's solution for yesterday's problems".


| What the current allocation policies are set up to do today is:
| 
|  - allow real ISPs to get address space, but in such a way that as
|    they grow (i.e, allocate more addresses to end sites and
|    downstreams), the size of the allocation they have from the RIR
|    also grows, i.e., from a /29 to /27 to /26, etc. This is to
|    minimize fragmentation of the address space as IPv6 usage grows,
|    and maximize the potential for continued aggregation.

Certainly IPv4 suffers because you can't make a single allocation without
running into one of:

1.  The allocated space is exhausted.
2.  The allocations exhaust the address space.

That problem might have even existed with 64 bit addresses.  But with
128 bit addresses, I don't see it being a problem this century, if ever.


|  - not make it possible for a non-ISP and typical end sites to get
|    addresses directly from RIRs; they should get addresses from their
|    ISPs. This is to scale the system over time, as we know that having
|    end sites go directly to RIRs for address is unscalable and will
|    result in a routing mess.

I can understand these measures with IPv4.

It appears the real problems were not addressed.  Address space quantity
was the "fear factor" a few years ago.  Those fears remain, but they have
calmed down (we're not in panic mode).

The real problem is routing.  Who is supposed to be working on that?  And
when will they start?

What I think needs to be done is to solve the routing problem, and then
go fit that in with IPv6.  And since it *might* need some changes to IPv6,
it could be costly if we don't expedite solving the routing problem before
the full deployment of IPv6.  I would have brought this up in the 1990's
because I certainly had ideas to solve it, but not being in the circle
of researchers working on it, and having read that routing was being
addresses, I didn't worry and just assumed IPv6 would solve these problems.

I should have worried.

-- 
Phil Howard
phil at ipal.net