ARIN-prop-252: Clarification to ISP Initial Allocation and Permit Renumbering [Archived]

Date: 1 February 2018

Proposal Originator: Jason Schiller

Problem Statement:

Currently 2.2 and 8.5.4 are out of sync.

Furthermore, the recent changes to 2.2 created a loop hole where an ISP can get a /21 even if it is substantially more than a two year supply.

Fianlly, the recent changes to 2.2 removed the policy supporting the option to return currently held IP space and re-numbering into the intiial allocation.

Details of the history of changes to this section and related sections are below:

2016-5 was established to permit automatic approval of a /24 for specified transfers to orgs with no resources under sections 8.5.4, 8.5.3.

This policy was also intended to be part of the boot strapping for a (slightly more liberal) slow start for transfers. An Org with no resources could get a /24 and if they needed more use it and then double their holding under 2016-3 (section 8.5.7)

2016-4 was also part of this effort to enable “easy” justification for the first /24 with-out requiring a demonstration of prior utilization, and bring section 4 policy in line with the new boot strapping for slow start in section 8.5.4.

The origional ISP initial allowed for a /20 (or /22 for multi-homed ISPs), but required demonstration of efficent use of space in use by their transit provider, or in exceptionalcases under immediate need.

There was a push (2014-13) to allow smaller blocks, and ISP were permitted an inital of a /24 with the understaning that ISP would not be forced to take smaller than a /20 if it was within the allowed time horrizon (initially 1 year then changed to 90 days, now 2 years).

2016-4 moved a bunch of text around an specified the initial ISP allocation of between ARIN’s minimum and a /21. I beleive this was intended to capture the then common understanding that the initial allocation allowed for between /24 and /20, but some how that got changed to a /21 (don’t recall if thers was something intentional there, perhapse splitting the difference between /20 and /22 for mutli-homed ISP?)

I beleive the intent of this change was:

1. to allow automatic approval for a /24

• no requirement to show previous utilization
• no requirment to show the address will be used within a particular time window

2. allow ISP w/o IPv4 addressing to

• waive the requirement to show previous utlization and get up to a /21 so lopng as it is within the applicable time horizon

3. Continue to require ISPs with re-allocations and reassignments to

• demonstarte efficent use of currently held space to qualify for their initial
• allow initial allocation to include space to renumber into (if disered)
• allow current growth to justify approprate initial allocation size

2016-4 did not specify that the replacement text for section 4.2.2 also intended to remove all subsections, but it was concluded that was clearely intended and implemented as such.

Without the 4.2.2 sub sections, an ISP can qualify for a /21 with no justification, even if it is represents a 15 year supply of addressing. I do not beleive this is in the sprit of what the policy change intended.

This would have been the case if the sub-sections were not removed.

With the removal of the subsections there is now an incompatability between 8.5.4 (Initial Block for specifiedtransfers) and the new 4.2.2 sans 4.2.subsections)

With the removal of the subsections renumbering into the initial is now not part of current policy.

Removal of the subsections clearly was not moot.

Policy Statement:

Replace Section 4.2.2 with:

4.2.2. Initial allocation to ISPs

“All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN’s minimum allocation size. All ISP organizations without direct allocations, direct assignments, re-allocations or reassignments automatically qualify for a /24. These organizations are exempt from requirements of showing efficient utilization of previously held IPv4 space. These organizations may qualify for a larger than a /24 by documenting how the requested allocation will be utilized within the request size specified in 4.2.4.3

ISPs holding re-allocations and/or reassignments must show efficient utilization of their resources consistent with the requirements in sections 4.2.3 and 4.2.4” Add a new section under 4.2.4

“Renumber and return

ISPs receiving a new allocation may wish to renumber out of their previously allocated space. In this case, an ISP must use the new allocation to renumber out of that previously allocated block of address space and must return the space.”

Comments:

Timetable for Implementation: Immeddiate

Anything Else:

This is an attmept to clarify the changes that came about from 2016-4.

It also aligns section 4.2 with current transfer policy.

It also also re-established the undertsanding that ISP can renumber and retrun, but putting the last section 4.2.2.1.4 into the ISP additional requests section. This text is slightly modified to include returns to ARIN in addition to returns to the upstream.