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