> On Feb 1, 2017, at 13:57 , Jason Schiller <[email protected]> wrote: > > Owen, > > My experience suggests renumbering that much IP space that is actually in use > is non-trivial. > I think that depends tremendously on the type of network. Since MSOs seem to renumber some batch of customers on /20s and sometimes larger on an almost nightly basis, I don’t think it can be that difficult for them. > However, if renumbering as a justification sounds insufficient to many how > about demonstrated growth equal or greater than 50% of the transferred IP > space. > Wouldn’t that be equivalent to the current process which remains available to them outside of this simplified process? > Certainly an organization had to list the IP holdings and utilization at the > time they requested transfer approval. Certainly they would have to do the > same with their next request to demonstrate efficient utilization. Generating > a delta of the count of things vs a delta of half of new addresses seems > simple. > That raises the bar only slightly, but it might be sufficient. I won’t strongly oppose this, but I don’t see a major advantage of doing repeated transfers of /16s via this mechanism vs. transferring a larger block under more traditional policies in that case. So I still think that the 6 month hold-down on this procedure makes more sense. > Would that be sufficient? > > The nice thing about avoiding the traditional request path is avoiding future > looking projections, speculation about business plans, and unpredictable > outcomes. > Sure, but I think allowing this path to be rapidly repeated in order to overcome the /16 safety valve offers little benefit, so I think that a timed hold-down is a more direct application of the intent — Limiting this path to a /16 or smaller need and requiring more stringent evaluation of larger transfers. Additionally, allowing such a path creates an incentive for additional unnecessary fragmentation.
Owen > ___Jason > > > On Jan 31, 2017 9:38 PM, "Owen DeLong" <[email protected] > <mailto:[email protected]>> wrote: > I argue that it is insufficient and that a 6-month moratorium on a second > simplified transfer is easier for everyone to understand and implement. > > The reason I feel it is insufficient is that renumbering a DHCP server > handing out a /17 (or cobbling up a DHCP server handing out a /17) isn’t a > particularly difficult barrier. > > Given that the preponderance of addresses handed out by larger service > providers these days are dynamic in nature, renumbering large swaths of > address space to circumvent the intent of the /16 limit on this policy is > relatively trivial. > > Any organization that truly needs a larger transfer is free to get the > approval through the conventional process and this simplified process is > probably not a good fit as a result. > > I believe that is congruent with your original intent and that the six-month > recycle limit is a quite reasonable safeguard. > > Owen > >> On Jan 31, 2017, at 08:04 , Jason Schiller <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 it? >> >> >> 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 4.2.4.1 & 4.3.6.1 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 4.2.4.1 & 4.3.6.1 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 >> ISPs >> 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% >> utilized, >> the organization would need to transfer in a /16. >> Then the organization would need to put 32,768 of the new IPs into service, >> or renumber the use of 32,768 of IPs from the older IP space to the new >> space. >> >> 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. >> >> __Jason >> >> >> >> >> On Tue, Jan 31, 2017 at 8:18 AM, David R Huberman <[email protected] >> <mailto:[email protected]>> wrote: >> Hello, >> >> 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. >> >> Background: >> >> 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 comment. >> >> >> 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 >> ARIN. >> >> 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. >> >> >> Conclusion: >> >> 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, >> David >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected] >> <mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> <http://lists.arin.net/mailman/listinfo/arin-ppml> >> Please contact [email protected] <mailto:[email protected]> if you experience any >> issues. >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|[email protected] >> <mailto:[email protected]>|571-266-0006 <tel:(571)%20266-0006> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ([email protected] >> <mailto:[email protected]>). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> <http://lists.arin.net/mailman/listinfo/arin-ppml> >> Please contact [email protected] <mailto:[email protected]> if you experience any >> issues. >
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
