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.
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).
Jack
