In message <4d4d5ffc.6020...@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: ma...@isc.org