Re: Using IPv6 with prefixes shorter than a /64 on a LAN

[Jack Bates <jbates () brightok net>]

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