[arin-ppml] 2016-3 Revisited
scottleibrand at gmail.com
Tue Jan 31 16:16:04 EST 2017
I support this proposal, either as amended thus far by David and the AC, or
(preferentially) as suggested by Jason.
I believe Jason's suggestion (restoring the "at least 50% utilization of
each allocation and assignment" condition to the 8.5.7 conditions) would
adequately address the "transfer /16s as fast as you can until total
utilization is below 80%" abuse concern, while still leaving the option
open for someone who has a legitimate need for another /16 in less than 6
months (without requiring the burden of documenting forward-looking plans
and getting ARIN to agree that they're "good enough").
Is there anyone who feels that the every-6-month restriction is sufficient
but the 50%-usage-of-each-block restriction is not? If so, can you outline
the scenario that you think the former would protect against and the latter
On Tue, Jan 31, 2017 at 8:04 AM, Jason Schiller <jschiller at google.com>
> As one of the originators of this policy change I welcome the rewrite,
> with the exception the mechanism to avoid abuse.
> Can someone explain the "abuse" concerns if I have not correctly captured
> Abuse concern:
> As far as I can tell, the combination of 2016-5 and this proposal (2016-3)
> is where the issue comes from.
> One of the goals of 2016-5 was to separate section 4 from transfers.
> As a result, NRPM 220.127.116.11 & 18.104.22.168 which specifies that organizations
> must show efficient utilization of 80% in aggregate, and 50% for each
> allocation/assignment is no longer a restriction to transfers.
> Without applying 22.214.171.124 & 126.96.36.199 an organization that is holding a /8
> that is 90% utilized, could then use 8.5.7 to justify a specified transfer
> of a /16.
> Once completed, the total holding of a /16 and a /8 would be 89.65%
> utilized and could immediately use 8.5.7 to justify another specified
> transfer of a /16.
> This process could be used 33 times and could result in drawing down a /11
> and a /16 without putting a single new address into service.
> Basic idea of 2016-3 and 2016-4:
> 1. Make an easy to use process with an easily predictable outcome for
> "simplified" transfers
> 2. Modify slow start and make it applicable to transfers for end-sites and
> 3. Give blanket approval for a "first", "small" starter block
> 4. Show that you have used what you got and then double what you have
> 5. Can always get more than double following the non-simplified process
> Intended Cap implementation:
> Doubling more than a /16 could provide way too much IP space
> (consider an efficiently used org than is not growing)
> Instead the doubling policy is limited at a /16.
> However if an organization is growing and has legitimate need for more
> than a /16, then it can get a /16 put it into service and then come back
> and get another dip.
> Suggested Anti-abuse text:
> To this, 2016-3 now adds a new paragraph:
> 8.5.7 Alternative Additional IPv4 Address Block Criteria
> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
> address blocks by demonstrating both
> - 80% utilization of their currently allocated space
> - at least 50% utilization of each allocation and assignment
> If they do so, they qualify to receive one or more transfers up to the
> total size of their current ARIN IPv4 address holdings, with a maximum size
> of /16.
> Taking the abuse example above of an organization with a /8 that is is 90%
> the organization would need to transfer in a /16.
> Then the organization would need to put 32,768 of the new IPs into
> or renumber the use of 32,768 of IPs from the older IP space to the new
> I argue that need to show growth or the renumbering of usage into the new
> IP space
> is of sufficient pain to avoid abuse by organizations that don't actually
> need the IP space.
> On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <daveid at panix.com>
>> TL;DR: We updated 2016-3 to fit into the upcoming NRPM, and closed an
>> abuse vector. We kept the original text and just incorporated it in the
>> new section 8.5 so it works, and time limited it to once every 6 months.
>> At the ARIN meeting in Dallas, there was a discussion about 2016-3, a
>> policy which seeks to remove Needs Testing for smaller 8.3 and 8.4
>> transfers (with a cap of /16). Some more work needed to be done on it, and
>> a vote at the Dallas meeting had 27 people ask the AC to continue working
>> on it, with 1 person against.
>> We've done some work, and the new text is ready for your review and
>> New NRPM Coming Out Affects 2016-3:
>> Policy 2016-5 was ratified by the board, and will be entering the NRPM
>> shortly. 2016-5 adds a new section to section 8 -- it adds 8.5, which are
>> the qualifying criteria for transfers. It looks like this:
>> 8.5. Specified Transfer Recipient Requirements
>> 8.5.1. Registration Services Agreement
>> The receiving entity must sign an RSA covering all resources to be
>> transferred unless that entity has a current (within the last two versions)
>> RSA on file.
>> 8.5.2. Operational Use
>> ARIN allocates or assigns number resources to organizations via transfer
>> solely for the purpose of use on an operational network.
>> 8.5.3. Minimum transfer size
>> ARINs minimum IPv4 transfer size is a /24.
>> 8.5.4. Initial block
>> Organizations without direct assignments or allocations from ARIN qualify
>> for transfer of an initial IPv4 block of ARINs minimum transfer size.
>> 8.5.5. Block size
>> Organizations may qualify for the transfer of a larger initial block, or
>> an additional block, by providing documentation to ARIN which details the
>> use of at least 50% of the requested IPv4 block size within 24 months. An
>> officer of the organization shall attest to the documentation provided to
>> 8.5.6. Efficient utilization of previous blocks
>> Organizations with direct assignments or allocations from ARIN must have
>> efficiently utilized at least 50% of their cumulative IPv4 address blocks
>> in order to receive additional space. This includes all space reassigned to
>> their customers.
>> To this, 2016-3 now adds a new paragraph:
>> 8.5.7 Alternative Additional IPv4 Address Block Criteria
>> In lieu of 8.5.5 and 8.5.6, organizations may qualify for additional IPv4
>> address blocks by demonstrating 80% utilization of their currently
>> allocated space. If they do so, they qualify to receive one or more
>> transfers up to the total size of their current ARIN IPv4 address holdings,
>> with a maximum size of /16.
>> An organization may only qualify under 8.5.7 once every 6 months.
>> This text is pretty much the same text that was originally proposed in
>> 2016-3, simply incorporated into the new NRPM language that's coming out.
>> It also puts in a mechanism to avoid abuse -- people trying to get around
>> the /16 cap -- by limiting it to once every 6 months.
>> The AC welcomes your feedback.
>> Thank you,
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> Please contact info at arin.net if you experience any issues.
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006>
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> Please contact info at arin.net if you experience any issues.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ARIN-PPML