<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Garry Dolley wrote:
<blockquote
cite="mid:20090601015431.GC13710@garry-thinkpad.arpnetworks.com"
type="cite">
<pre wrap="">On Sun, May 31, 2009 at 02:42:14PM -0400, Kevin Loch wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
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"?
</pre>
</blockquote>
<br>
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:<br>
<br>
<tt>
G #<br>
| </tt><tt>
| 0 0</tt><br>
<tt>|X </tt><tt>
| 1 1</tt><br>
<tt>|X </tt><tt>X
| 2 2</tt><br>
<tt>|X X </tt><tt>X </tt><tt>X
| 3 4</tt><br>
<tt></tt><tt>|X X X X </tt><tt>X X
</tt><tt>X X | 4 8<br>
</tt><tt>|X X X X X X X X </tt><tt>X X X X </tt><tt>X
X X X | 5 16<br>
</tt><tt>|X X X X X X X X X X X X X X X X </tt><tt>X X X X X X X X </tt><tt>X
X X X X X X X | 6 32<br>
|XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX| 7 64<br>
</tt><tt><br>
</tt>... 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.<br>
<br>
(* IIRC, folks requesting an initial allocation shorter than /32 get
them from a different block with different reservation rules.)<br>
<br>
S<br>
<tt><br>
</tt>
<pre class="moz-signature" cols="72">--
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
</pre>
</body>
</html>