In message <4D4D5FFC.6020905@brightok.net>, Jack Bates writes:
On 2/5/2011 6:47 AM, Mark Andrews wrote:
So why the ~!#! are you insisting on comparing IPv4 allocations with IPv6 alocations.
Because that is where the comparison must be made, at the RIR allocation size/rate level.
There are two sizes. Those that fit into a /32 and those that don't. The latter ones have to justify their allocations.
Yeah, tell that to the fee schedules.
No. You need to compare it to the number of customer sites. If you have 1 customer with wires going to two locations thats two /48's.
That's definitely the wrong way to look at it. Sure that's related to justification to an RIR to get an allocation, but ISPs will end up with much more flexible address space.
Residential ISPs shift 16 bits (48-32=16). You shift less if you have less than 64000 customers sites and don't get address space from a larger ISP. Commercial ISPs shift more as what was multiple address at one sites becomes 1 /48.
64,000 customer sites isn't required to receive more than a /32 (unless a single router makes up your entire network).
No, but you still need to have reserved growth space sensibly. /32 for a town of 3000 is overkill. Last assume you are serving a home customers so you were at 1 address per customer. You still size your pops based on expected customers and having some growth room without having to renumber. n customers requires f(n) sized block of space. The only difference with IPv6 is f(n) << 80 bits to support /48's instead of single addresses. Expected growth rates in customers don't change because you are suddenly dealing with IPv6.
Well, I currently have a /30, which is a 14 bit shift right from my /16. (30-16=14).
And did you change the amount of growth space you allowed for each pop? Were you already constrained in your IPv4 growth space and just restored your desired growth margins?
In the near future I expect to be somewhere between a /24 and a /28, which is an 8 to 12 bit shift right from my IPv4 /16 allocation.
Only if you can serve all those customers from that /16. You are then not comparing apples to apples. You are comparing a net with no growth space (IPv4) to one with growth space (IPv6).
Still, that is a considerable number of bits we'll have left when the dust settles and the RIR allocation rate drastically slows.
Jack -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org