[arin-ppml] A modest proposal for IPv6 address allocations

[Stephen Sprunk]

Garry Dolley wrote:
> On Sun, May 31, 2009 at 02:42:14PM -0400, Kevin Loch wrote:
>   
>> This is called "sparse allocation" method and is what APNIC uses today.  It was one of the the justifications for giving each RIR blocks of /12 instead of /23.  I would like to know why ARIN is not using this method.
>>     
>
> I thought ARIN *was* using this method.  Or at least keeping surrounding upper blocks free when allocating /32's.  I believe this is the "leftmost" method per RFC 3531 [1], but I could be wrong on that, RFC 3531 goes over my head a lot.
>
> I did WHOIS lookups on some /32's surrounding my own and found the following:
>
> 2607:f2e0::/32 - allocated
> 2607:f2e1::/32
> 2607:f2e2::/32
> 2607:f2e3::/32
> 2607:f2e4::/32
> 2607:f2e5::/32
> 2607:f2e6::/32
> 2607:f2e7::/32
>
> 2607:f2e8::/32 - allocated
> ...
> Therefore, each /32 can potentially grow into a /29 (I *think* my math is right on that, 3 more bits gives 7 additional /32's beyond the initial allocation, for a total of 8 /32's).
>
> Is this what is meant by "sparse allocation"?
>   

That is somewhat sparse since it reserves space for limited future
growth, but the "bisection method" is what folks are usually referring
to.  If that's what ARIN were doing, allocations would have gone like this:

                                                                   G  #
|                                                                | 0  0
|X                                                               | 1  1
|X                               X                               | 2  2
|X               X               X               X               | 3  4
|X       X       X       X       X       X       X       X       | 4  8
|X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   X   | 5 16
|X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X | 6 32
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX| 7 64

... and so on through 21 generations (/12 -> /32).  Bisecting each
reservation, as above, allows the maximum potential for future growth
instead of reserving a fixed-size block.  The bisection method doesn't
reach a reservation of /29 until the 18th generation, which can
accommodate up to 131,072 /29 reservations in a /12 -- though some folks
in the earlier generations will have grown  past /29 and thus have
stolen slots from later generations.  Using ARIN's current method,
nobody getting a /32* can grow past /29 without getting a second block. 
Bisection allows anyone to grow their block up to the reservation size
of the current generation.  Effectively, ARIN is _starting_ in the 18th
generation.

(* IIRC, folks requesting an initial allocation shorter than /32 get
them from a different block with different reservation rules.)

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090531/fe5b58dd/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090531/fe5b58dd/attachment.bin>