IPv6 PI allocation

[Colm MacCarthaigh]

On Thu, May 17, 2007 at 02:27:25PM -0400, Kevin Loch wrote:
> >Right now, the use of /127's and /126's for link address by some
> >networks are a bigger part of future problems than anything represented
> >by PI.
> 
> Are you suggesting that routers should not route all 128 bits?  

Yep. 

> If we are going to use 128 bit addresses then we need to be able
> to route all 128 bits in silicon. 

I don't see why. My definition of "routing" is anything which results in
a ttl being decremented. Don't see why L2 switching can't pick up the
last 64 bits. 

> I'm sure you have a few /32 IPv4
> static routes in your tables from time to time...

Sure, but there's no shortage of /64's, no particular reason I can see
that it couldn't be done.

> - It is an ideal boundary for record keeping and visual identification
>   of subnets (unlike /126 or /127)

but what makes it "ideal" compared to /64 in this regard?

> - It's large enough to support multiple devices for varying applications
>   and/or reconfiguration/migration on ethernet type links

but what makes it "enough" compared to /64 in this regard?

> - /64 is just an insane waste of addresses (or subnets if you look at it
>   that way).

Address-conservation is a non-goal, it doesn't matter, there really is
plenty. There are 2^64 /64's. Even if we assigned only /32's to AS's,
another policy which would reduce the routing table size in sillicon,
there are still 2^21 of those publically assignable, probably enough to
see is through the entire lifetime of IPv6 (though it's not a bet I'd be
willing to take, overprovisioning by insane ammounts is a good idea).

-- 
Colm MacCárthaigh                        Public Key: colm+pgp at stdlib.net