Mikael Abrahamsson wrote:
On Tue, 5 May 2009, Ricky Beam wrote:
That's exactly how IPv4 was seen long ago, and we've been and will be
living with that mistake for decades.
It was fixed 15 years ago, but not before more than half the space was
"wasted". With IPv6 we can use current policy and only "waste" a /3 and
then we can change policy and do something smarter if needed. This /3
will last us a long time and we have plenty of time to create something
better than SLAAC.
Fixing ipv4 didnt erase the pain of the brokeness.
Odds are it will be much much worse if that happens with ipv6.
Doing potentially stupid things now because we can fix it later isnt
intelligent.
One potential problem scenario is larger proliferation of DFZ routes
than would have otherwise been necessary - simultaneous with large scale
ipv4 de-aggregation.
About 13% of ipv6 is assigned for addressing purposes.
According to IANA, the /3 is about 0.8% allocated and we already have
1700 ipv6 routes, which according to statistics is about 0.014% of the /3.
And we arent even using it for anything important yet, meaning something
that could not be done over ipv4 internet or ipv4 vpn.
At this rate, the /3 will be full with about 12 million routes. That
isnt far fetched assuming most corporations and other tech savvy users
go with PI over the next 15-30 years.
Even if we can stick to roughly one prefix per AS, my best guesstimate
is anywhere between 50-250k ipv6 routes until ipv4 routes start
declining, depending on how long that takes.
Expecting organizations to renumber into larger assignments in order to
keep overall prefixes low is an unrealistic hardship.
If the goal is to keep each organization to a single prefix, /48 per
customer suggest a minimum allocation on the order of either /24 (16m
customers, 2m per /3) or a /28 (1m customers, 34m in the /3) instead of
a /32 (65k customers, 530m in the /3).
Are there any better numbers out there other than these hastily
scribbled back of envelope ones?
I suppose the question is, are we building a system that can stand for
decades or centuries?
Right now it seems to be optimizing for both.
Joe