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

Sun Feb 6 05:57:38 UTC 2011

In message <4D4E1C5D.20407 at 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 at isc.org