In message <4D4E1C5D.20407@brightok.net>, Jack Bates writes:
On 2/5/2011 8:40 PM, Mark Andrews wrote:
A IPv4 /16 supports 64000 potential customers. A IPv6 /32 supports 64000 potential customers. Either you have changed the customer estimates or changed the growth space allowances or were using NAT or ....
You don't suddenly need 256 times the amount of space overnight all other things being equal. About the only thing I can think of is you need to advertise 256 routes and you are asking for extra blocks to get around poorly thought out filtering policies.
What filtering policies? My allocation was based on customers per terminating router, 1 route per terminating router. A /32 was nowhere near enough. The reason a /16 works today is because I have a routing table that looks like swiss cheese and a 95%+ utilization rate. 9 /40 (equiv of 9 /24 IPv4 DHCP pools for residential DSL) networks don't fall on a bit boundary. Nibble would make things even easier, but to say I have to run multiple routes to a pop and squeeze things in as tight as possible is insane. Justifications DO allow for some amount of aggregation in numbering plans.
Rationalising to power of 2 allocations shouldn't result in requiring 256 times the space you were claiming with the 8 bits of shift on average. A couple of bits will allow that.
If ISPs were being honest and matching IPv4 to IPv6 filtering the filters would be set a /40 not /32. By setting the filters to /32 you force the small ISP to ask for up to 256 times as much address space as they need with absolutely no benefits to anyone just to get a routing slot that won't be filtered.
Actually, many router policies, as discussed previously on the list, support /48. Routing policies don't force the /32, and a current proposal to ARIN even supports a small ISP getting a /36, hopefully at a lower cost.
What's really needed is seperate the routing slot market from the address allocation market.
I agree that inter-AS routing needs to change, though that still has nothing to do with address allocation itself. Sizes of allocations were chosen to allow for growth. The ISPs don't get near the wiggle room that corporations and end users get in address assignment currently.
When analyzing exhaustion rate of IPv6, like IPv4, you have to view it at the RIR allocation level. In this case, across the board, we will see a minimum of an 8 bit shift in allocations, and often 12-16 bits (what's to the right of the allocation bits doesn't matter when we consider exhaustion rates, so long as what's to the right is appropriately utilized and justified by community standards before another request is handled by the RIR).
You need to look very closely at any ISP that only shifts 8 bits going from IPv4 to IPv6, something dodgy is probably going on. This is not to say it is deliberately dodgy. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org