[arin-ppml] Draft Policy 2010-12: IPv6 Subsequent Allocation - Last Call (text revised)

[Scott Leibrand]

On Wed, Oct 13, 2010 at 4:10 PM, William Herrin <bill at herrin.us> wrote:

> On Wed, Oct 13, 2010 at 2:10 PM, ARIN <info at arin.net> wrote:
> > Draft Policy 2010-12
> > IPv6 Subsequent Allocation
> >
> > Policy statement:
> >
> > Modify 6.5.2.1 Subsequent allocation criteria. Add the following:
> >
> > Subsequent allocations will also be considered for deployments that
> > cannot be accommodated by, nor were accounted for, under the initial
> > allocation. Justification for the subsequent subnet size will be based
> > on the plan and technology provided with a /24 being the maximum allowed
> > for a transition technology. Justification for these allocations will be
> > reviewed every 3 years and reclaimed if it is not in use. All such
> > allocations for transitional technology will be made from a block
> > designated for this purpose.
>
> This is much better but I think it could still benefit from a little
> tweaking.
>
> I suggest replacing "Justification...transition technology" with:
>
> "Justification for the subsequent subnet size will be based on the
> plan and technology provided. No organization may hold more than a /24
> under this subsection."
>
> I'm being a little pedantic here, but the language doesn't specify
> transition technologies for allowing an additional allocation yet does
> specify transition technologies for the limit. I think it's smart not
> to limit the application to "transition technologies" but the safety
> limit should apply across the board.
>

Keep in mind that the way this is worded is to take into account the
sentiment expressed at the meeting that we shouldn't just be limiting
subsequent allocations to those needing it for transitional technologies.
For example, this would make it possible for someone to get a new v6 block
for wireless deployments if they have deployed their first block across all
of their wireline infrastructure, but aren't using enough of it to meet the
HD ratio.


> The text also specifies /24 as the limit per allocation. It doesn't
> clearly stop folks from coming back for additional /24 allocations.
>

My assumption was that additional subsequent allocations would be fine, but
additional large subsequent allocations for something like 6rd would be
denied on the basis that the only reason for getting a block that big is to
be able to number an arbitrarily large network out of the same subnet.


> I realize this is a last call, but given the time constraints for this
> policy to be helpful, I offer these suggestions here in lieu of
> objecting to the major changes from draft to last call that would
> ordinarily recommend returning the document to discussion for the next
> meeting.
>

Agreed.  I think we need to come to a consensus on language during the last
call period, so that the AC can make any necessary changes and send it to
the board ASAP.  I fully expect to see additional policy proposals to
further clean up the language, but that is much less urgent than removing
the v6 deployment roadblock that we have today.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101013/819c4d47/attachment.htm>