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

[Garry Dolley]

On Sun, May 31, 2009 at 12:19:38AM -0500, James Hess wrote:
> Why allocate  /32s  from a pool reserved for  /32s?
> It would perhaps make more sense, as a matter of policy, that a
> special allocation strategy be utilized,  that the  /48s,  /32s, and
> /24s  are allocated from just one pool.
> 
> And that they be allocated in a manner  that maximizes the duration
> during which the 2nd/3rd allocation request would be contiguous with
> the earlier allocation.
> 
> 
> e.g.  A  /48  may be allocated,  but the  entire  /24 could be left
> "internally" reserved for as long as possible.
> 
> So if/when a  recipient of  a  /48 allocation requests their next
> allocation, it would be preferred that the /32  will be a block that
> begins with, and contains the same address space as their /48,  in
> addition to the added space.
> 
> And if a third allocation is requested, the /24 also,  would be chosen
> so as to overlap with and contain the /32.
> 
> 
> This has the benefit that they don't need a second advertisement, and
> never have a need to return addresses.
> 
> 
> 
> If/when ARIN's  allocations of V6 space ever becomes so dense  that
> reserving the entire  /24  in advance  for recipients of /48s is no
> longer feasible,    it  should be the oldest-assigned  /48   that are
> first "blocked" from expanding contiguously to a /24,  followed by the
> oldest  /32 allocations.
> 
> With preference of the "blocking"  assignments preventing contiguous
> expansions to /24 over contiguous expansions to  /32.

James makes a good point. 

Since the v6 space is so large, ARIN can, for example, allocate an
org a /32, but leave the neighboring /32 unallocated for as long as
possible, so if/when you need another /32, they just change your
subnet mask to a /31.  No renumbering required.

I once was lucky to have this happen w/ v4.  I had a /20 from ARIN,
then at some point requested another.  The neighboring /20 was
available, so they just made it a /19.

Any org in the position to allocate IP space can do this [1].  For
example, if I give a /56 to a customer, I'll pretend as if it were a
/48, so if that customer ever needed more subnets than a /56 has to
offer, I'll just change their subnet mask to a /48.  They don't need
to renumber or deal with two discontiguous /56's.

Therefore, having ARIN use separate "pools" for different allocation
sizes would not be a good idea.


1. RFC 3531, "A Flexible Method for Managing the Assignment of Bits of 
   an IPv6 Address Block"
   http://tools.ietf.org/html/rfc3531

-- 
Garry Dolley
ARP Networks, Inc. | http://www.arpnetworks.com | (818) 206-0181
Data center, VPS, and IP Transit solutions
Member Los Angeles County REACT, Unit 336 | WQGK336
Blog http://scie.nti.st