Calling all Internet policy wonks; it’s time for another ARIN Public Policy Meeting (PPM)!
ARIN XXIX (the 29th ARIN PPM) will be held in Vancouver, British Columbia, 22-25 April 2012. Registration is still open and while it may be a little late to show up in person, ARIN’s remote participation is pretty fantastic (and totally free). So if you are interested in the future of Internet number policy at all, there really is no excuse for you not to take part. Like at all RIR meetings, important decisions which affect the way the Internet works will be made in Vancouver. If you’re not there (physically or remotely) to influence those decisions and have your voice heard, you have no one to blame but your self.
For those of you who will be there but have not been able to keep up with the discussion since my last ARIN update, I’ve put together a quick look at what’s what going into ARIN XXIX. Because it ended up being quite long winded, I have split this update into two parts. Part 1, here, is an update on policy changes that are no longer under discussion, because they have been adopted by the ARIN Board and implemented by ARIN staff. While these policies will not be discussed at ARIN XXIX, they are important to understand for two reasons. First, they have altered the ARIN Number Resource Policy Manual (NRPM) which may affect your next interaction with ARIN. Second, they provide some background and history on the current policy debates. You may be able to glean a sense of where the ARIN community’s focus is (or at least has most recently been) by understanding the policy changes which have made it through to adoption following the previous PPM.
Part 2 of this update covers the draft policies that will be discussed in Vancouver, as well as all miscellaneous information that may help you prepare for ARIN XXIX.
Enjoy!
Policies Implemented
There have been two new versions of the NRPM published this year (2012.1 in Jan and 2012.2 in Feb). Between the two updates, five policies have been fully implemented.
NRPM version 2012.1 (published 30 January 2012) contained the implementation of three new policies:
ARIN-2011-3: Better IPv6 Allocations for ISPs
This policy was previously “partially implemented” by ARIN staff and as such, I previously opined about it:
At it’s most basic; this policy allows for ISPs to follow the Best Current Operational Practices (BCOP) for IPv6 subnetting, namely to allow one-dip (or close to it), uniform subnetting. By “one-dip” I mean getting enough IPv6 space up front for long-term growth. This eliminates the need for ISPs to continually come back to ARIN for more addresses, which results in less required disaggregation of the address space. This is a new concept allowed by IPv6′s vastly larger address space. By uniform I mean a hierarchical addressing architecture in which each tier uses the same size subnets. This improves operational clarity (especially when used with nibble boundaries) and the ability to aggregate internal IPv6 routes. Here again this is a paradigm shift from IPv4 address planning – which is why this policy was needed; to bring ARIN policy in line with operational experiences.
According to ARIN; “2011-3 is now fully implemented to allow larger allocations in accordance with the policy.” That’s great news for all of us!
ARIN-2011-8: Combined M&A and Specified Transfers
This policy statement is fairly short, simple and straightforward – just the way we like ’em. It reads, in full:
To section 8.2 change “… ARIN will work with the resource holder(s) to return, aggregate, or reclaim resources as appropriate via the processes outlined in current ARIN policy (for example, sections 4.6, 4.7, or 12 of the NRPM).” to “…ARIN will work with the resource holder(s) to return, aggregate, transfer, or reclaim resources as needed to restore compliance via the processes outlined in current ARIN policy.”
This means that now, when there is a merger or acquisition and the resulting combined organization can no longer justify all of their number resources, they have the option to transfer those resources to another organization. This allows the merged organization to monetize their excess resource holdings, rather than return them to ARIN directly (and without compensation).
Regardless of people’s individual opinions on specified resource transfers, this was widely held as a good change primarily because it cleared up what was effectively a sequencing problem in the previous policy. The old policy language made it possible to transfer number resources to a specified recipient before an M&A transfer, but not after. This was seen as a fairly clear injustice (it would suck for an organization and ARIN to both end up with their hands tied on a technicality) and I think we’re better off having rectified it.
ARIN-2011-10: Remove Single Aggregate requirement from Specified Transfer
This is another short and sweet piece of policy intended to clean up the transfers section of the NRPM:
Modify Section 8.3 as follows: Change “can demonstrate the need for such resources, as a single aggregate, in the exact amount which they can justify under current ARIN policies” to “can demonstrate the need for such resources in the amount which they can justify under current ARIN policies”
The history here is that ARIN staff’s interpretation of the original policy language did not match many community members expectations regarding that same language. Those folks believed that the single aggregate statement should apply to the actual block transferred (that only transfers of a single prefix should be allowed) while ARIN staff took the original language to mean that the single aggregate applied to the justification, not to the block transferred (that one or more address blocks could be transferred, as long as the blocks transferred added up to the same or less addresses as contained in the largest single prefix the receiving organization could justify).
This policy change was therefore a no-op in that it did not change the implementation of the original policy. Instead, it brought the language of the NRPM into more clear alignment with the previous/current implementation.
NRPM version 2012.2 (effective 10 February 2012) is the current version of the NRPM and it contains the implementation of two new policies:
ARIN-2011-11: Clarify Justified Need for Transfers
This policy statement reads:
Add to Section 8.3:
“…they can justify under current ARIN policies
showing how the addresses will be utilized within 12 months.”Remove from 4.2.4.4:
“This reduction does not apply to resources
received via section 8.3. An organization receiving a transfer under
section 8.3 may continue to request up to a 12-month supply of IP
addresses.”
By moving the location of the 12 month justification rule, this policy effectively removed slow-start for specified transfer recipients. Slow start is the name given to ARIN’s process of vetting new resource holders. Traditionally, when a brand new organization shows up asking ARIN for resources, they are given a very small amount and told to come back for more only when they have efficiently utilized those resources. This gave ARIN a chance to validate the claims of the new organization, to build a relationship and a record of trust.
This policy change removed that buffer and now (in combination with the below ARIN-2011-12 policy change) brand new, never before seen organizations can show up and request a full 2 year supply of IPv4 addresses via specified transfer. I think this was a mistake and worse, that many of the folks who supported the change are still not fully aware of the potential ramifications.
ARIN-2011-12: Set Transfer Need to 24 months
If ARIN-prop-146 passes, also modify “will be utilized within 12 months” to “will be utilized within 24 months”
First off, the whole “if X than Y” binding of policy proposals is unnecessary and unwise. Both the ARIN AC and ARIN staff are fully capable of merging policy changes when needed. Doing so ahead of the fact simply causes confusion. If policy proposals like this are submitted in the future, I will fight even harder to clean that type of language up before accepting them onto the AC docket.
Ranting aside, this policy (fairly obviously I assume) changed the 12-month specified transfer justification requirement to a more generous 24-month justification. That means that now organizations who will receive addresses in a specified transfer are allowed to accept twice as many addresses as they could previously.
FYI – ARIN has posted full Transfer Guidelines at: https://www.arin.net/resources
Be sure to check out part 2 of this update as well, which covers all of the draft policies going into ARIN XXIX!
