Choices seem to be:
(A) Continue with PA addressing, and accept that enterprises
    will use IPv6 NAT to get provider-independence.
(B) Allocate PI addresses, and trust that we can determine a
    scalable PI routing scheme before we hit route scaling
    issues in the IPv6 backbone.
So, I would make an informed decision to pursue choice (B),
in full knowledge that it might create a route scaling issue
further down the road.
I will point out that you will never be able to clean out PI addresses
after they have been allocated. Furthermore, giving PI addresses will
inevitably trigger a land rush as they will always be more convenient
that any ID/LOC scheme we might come up with; anyone will want one.
Contrary to IPv4 size will not matter for most. If we go the (B) road
we'll end up with a large number of /48s in the global routing table,
which is definitely *NOT* what the design of IPv6 is.
Well, let's look at this from another perspective. We today only have one option for inter-domain routing. To use BGP. That might change in the future, but even if we in San Fransisco would agree on a new routing model, it would still take us at least 3-5 years to implement. See the migration to BGP4 as example.

Let us instead do some numbers,

today we have around 20k allocated ASes of which around 15k is visible. If we assume that all of these where allocated a IPv6 PI block and they all had three upstreams for multihoming, we would end up with 45k routes - which is nothing (I was running a 2514 with 16Mbps of memory and 30k routes as my first BGP router. Works just fine). If the current worst case scenario comes true we will have 64k routes x three upstreams which would give us 192k routes, still not bad. If we extended the AS space four times, the number of routes is still doable.

What we need to watch our for is a growth of several orders of magnitude. But this also comes with a monetary cost on the end-users, which most likely will dampen the growth.

I say go for /48 PI space. Take a /16 (or something suitable) and divide it per RIR, and use it as PI space.

I am still more worried about the lack of IPv6 routes, than the growth of IPv6 routes....we are ten years down and have ~350 routes...

So, I would make an informed decision to pursue choice (B)
This is not the time for a post-mortem choice yet. We still have some
time. Not much, but some.

The current course of action of the IETF is:
(C) Put my head in the sand and pretend that the problem is not urgent.

I would like to see a more positive attitude here. The battle is not
lost yet and there are things that can be done before we relunctantly go
the (B) way. If we go the (B) way now, there is no more way back than
there is with NAT.

==> (C) Finally do something about IPv6 multihoming.

I would rather see (C) Come up with a new "routing" paradigm.

- kurtis -

--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------

Reply via email to