[ppml] 2005-1 status

[Scott Leibrand]

Tony,

So what do you think our IPv6 PI policy should be?  Similar to our IPv4 PI
policy?  Or to allow PI allocations, but be more restrictive than the
current IPv4 policy?  Or to not allow any IPv6 PI allocations at all?
And if the latter, how should enterprises multihome currently (before a
good multi-IP multihoming technology like shim6 gets developed and
deployed)?

-Scott

On 01/25/06 at 6:14pm -0800, Tony Li <tony.li at tony.li> wrote:

>
> > OK, Tony...it's an architecture problem... what's the solution then.  What
> > architectural change can eliminate the scaling problem posed by an expanding
> > PI endsite population.... or is there an alternative to PI that allows
> > flexibility of endsites to benignly exchange service providers?
>
>
> Well, the basic problem that we have to confront is that to keep the
> routing subsystem scalable, we can only relay a relatively small amount
> of information, regardless of the size of the network.  Yes, I grant you
>  that this amount can and will grow slightly over time and that Moore's
> law may (or may not) help us out, but any way we look at it routing must
> scale about logarithmically or so.
>
> For that to happen, we need to be able to create topological
> abstractions on the network.  We need to be able to take a map of the
> network, draw a big circle around various parts of it and give
> everything in that circle a 'handle' for us to route on.
>
> Obviously, PI space flies right in the face of this.  Every single PI
> allocation that is ever made comes at a constant cost to the network and
>  covers a fixed portion of the network.  Unless PI allocations
> effectively never happen, any reasonable PI allocation allotment will
> quickly cause a routing information explosion.
>
> Example 1: Suppose that a PI allocation gets a /48.  Then the routing
> infrastructure needs to support 2^128 / 2^80 = 2^48 (~ 3e14) information
> entries.  Further, that allocation is already enough to support 2^80 (~
> 1e24) hosts.  The current Internet is something like 3e8 hosts, so this
> is already a very large allocation.
>
> Example 2: We could make PI allocations much larger, such as a /32, but
> then we limit either the size of the network or the number of
> enterprises that are allowed to participate.  Even then the routing
> issue is intractable using today's technology (~ 4e9 entries).
>
> The basic conclusion here is pretty much straightforward: we cannot
> responsibly make PI allocations without either blowing up the routing
> subsystem or squandering our hard-fought extra address space.
>
> Given this, it follows that we need an architecture that allows us to
> renumber or multi-home easily.  There have been many that have been
> discussed and I won't re-hash them all here, as this mail is long enough
> already.
>
> Regards,
> Tony
>
>