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

[Jack Bates <jbates () brightok net>]

On 2/5/2011 11:57 PM, Mark Andrews wrote:
> 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.
I didn't claim 8 bit average (if I accidentally did, my apologies). I 
claimed a minimum of 8 bits. Somewhere between 12 and 16 is more likely. 
However, with new ARIN proposals, we will see shorter shifts (yet still 
over 8 bit shifts) as it does nibble allocations for everything (pop 
assignments nibble aligned, ISP allocations nibble aligned, ISP to ISP 
reallocation policies). It treats utilization as a 75% bar with nibble 
alignments to allow for proper growth at the ISP level.

So for me, my /30 will at least expand out to a /28, though I will have 
to reanalyze the pop allocations with the new rules, as it's possible I 
may bump to a /24 (if I end up expanding to a /27 of actual current usage).


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

Currently, I agree. It should be between 12 and 16 normally. However, 
new policy proposals are designed in such a way that the bit shift may 
only be 8. However, this also depends on the ISP. As ISPs do look 
towards dropping v4 in priority, they will also look at redesigning some 
of their pop layouts.

This is actually a case for me. Due to growth and utilization issues on 
IPv4, I've concentrated pops into supernodes to better utilize the v4 I 
have (95% utilization of pools which cover much larger customer sets, 
versus a bunch of smaller utilized pools which have less utilization 
rates as the pops don't grow at the same rate). However, I have areas 
this is reaching a critical point, and the IPv6 model is dividing up 
into smaller pop nodes. Since I don't have address space concerns for 
IPv6, structuring the network and customer termination into a better 
layout is more appropriate. What's more, in most cases, I can accomplish 
v4 supernodes and v6 separation at the same time; and I'll see the 
benefits as more customers shift to actual v6 connectivity.



Jack