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
