[arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs

[Owen DeLong]

On Apr 2, 2013, at 16:24 , David Farmer <farmer at umn.edu> wrote:

> On 3/30/13 18:06 , Brandon Ross wrote:
>> On Fri, 29 Mar 2013, David Farmer wrote:
>> 
>>> After thinking about it for a while, if we even need any policy at
>>> all, we should just have a general policy describing how IPv6 block
>>> can be reduced by returning only part of a block, it should probably
>>> be very generic and apply to allocations and end user assignments.  It
>>> might even be better if it we a separate proposal all together.
>> 
>> Agreed, which is why the language in this proposal allows for that, and
>> that was done on purpose.
>> 
>> I don't want to see that separated to a separate policy proposal because
>> it is critical to making this one function as intended.
> 
> Well, yes and no, John has already fix the operational issue, the only effect your proposed text would have at the moment would be to restrict it to the first or last blocks of the larger original block.
> 
> This raise a question for me do we really need to restrict it to the first or last blocks?  Personal, I'm ok with allowing the person making the return to have the flexibility to make choice of any contiguous and alined /40 out of the /32 they want.j

Since we're holding (at least) the /32 in reserve for them anyway and ideally the /28, I really don't think it matters which /40 they're using.

> 
> Next, I'm thinking about a new subsection;
> 
>    6.12 Reduction or Return
> 
>    Organizations may return all or part of their allocations or
>    assignments, that are not in use, to ARIN at any time with the
>    following considerations;
> 
>    a. Such a return or reduction must not result in a larger number of
>       blocks being held by an organization, if possible fewer blocks
>       are preferred.
> 
>    b. If a whole block is not in use, the whole block should be
>       returned to ARIN.
> 
>    c. If part of a block is returned; A single contiguous nibble
>       alined block, no smaller than the applicable minimum block size
>       allowed by policy, should be selected and retained by the
>       organization.  The remainder of the original block must not be
>       in use and must be returned to ARIN.  It is possible for
>       multiple separate blocks to be retained from a single original
>       block as long as clause (a) above is also meet.

I think this vastly overcomplicates what should be relatively simple...

How about this:

6.12 Reduction or Return

	ARIN will accept any return which allows an LIR to reduce their
	holdings to fit a lower tier in the fee schedule so long as:

	1.	The end result is not an increase in the number of
		non-contiguous blocks held by the LIR.

	2.	Whole blocks are returned to the extent practicable.

	3.	Retained block(s) are within the largest reserved space
		set aside for the LIR in the ARIN database to the extent
		practicable.

I think it is better to express directly what it is that we want to happen
in general terms and trust that ARIN and the LIRs will generally find
a way to do the right thing so long as we do not prevent them from
doing so.

> Also, related to this I'd like to delete section 6.5.8.4 "Consolidation and return of separate assignments", delete the last sentence of 6.5.3 clause (c), and add a new subsection in 6.3 "Goals of IPv6 address space management";
> 
>    6.3.9 Consolidation and return
> 
>    Some organization will have multiple IPv6 blocks, obtained through
>    subsequent allocations or assignments where an existing block could
>    not be sufficiently expanded, or through transfers (mergers and
>    acquisitions).  Such organizations should consider consolidating to
>    a single block, or at least minimizing the number of blocks used
>    for new sub-assignments.  This should not be considered a
>    recommendation for large-scale active renumbering out of blocks at
>    are in use.  To the contrary, such consolidation is merely a goal
>    and would likely occur over several years.  Further, it should
>    primarily be achieved through attrition and other normal
>    operational change.  Finally, return of a block is expected once it
>    is no longer in active use.

I think this is unnecessary and that the concerns driving this can be better addressed through improved operational practice.

Owen