On Monday I covered all of the policies that have been implemented so far this year in part 1 of this update. Today I’ll give you some info on the draft policies that are still active; the policy changes that will be discussed at ARIN XXIX in Vancouver, British Columbia 22-25 April 2012.

Before diving in I want to remind you all again that, if you have not already done so, now is the time to register for this Public Policy Meeting (PPM). Don’t let the future pass you by when all you have to do is speak up to be heard.

UPDATE: Want to know the results of these draft policies? My June 2012 policy update has all the details of what happened following the PPM in Vancouver!

Draft Policies

The following draft policies are currently on the AC’s docket and will be discussed at ARIN XXIX in Vancouver. Let’s make some sausage!

ARIN-2011-1: ARIN Inter-RIR Transfers

This draft policy seeks to replace NRPM section 8.3 Transfers to Specified Recipients with language that allows the transfer of IPv4 addresses between organizations in different regions (i.e. served by different RIRs). Currently, specified transfers can only take place between two organizations in the same RIR service region.

This policy change was actually recommended for adoption by the AC following the previous PPM in Philadelphia last October. Because of some confusion and complaints primarily regarding textual changes by the AC after the community discussion at ARIN XXVIII, and due to some concerns regarding the need for further safeguards in the policy, the Board has requested further discussion at ARIN XXIX.

There are two factors of interest here. One is that while the Board did not adopt the policy, they did direct the President to “immediately start implementation of this policy in parallel, with final policy availability held until otherwise directed by the Board.” In other words, this policy change will be teed up and ready to implement immediately following the discussion in Vancouver, should that be what the community decides.

The second thing worth noting here is that in response to the ongoing and current concerns about specified transfer policy safeguards, new policy language for NRPM section 8.3 has been proposed. This newer proposal is contained in draft policy ARIN-2012-1 (below) and covers both inter and intra regional specified transfers. This means that there is now a slightly more complicated decision to be made. Instead of a binary, yes or no to ARIN-2011-1, we now have a third option to consider.

ARIN-2011-5: Shared Transition Space for IPv4 Address Extension

With the adoption of RFC-weil-shared-transition-space-request-15 (currently in the RFC Editor Queue), and the subsequent reservation of 100.64.0.0/10 as Shared Transition Space, this policy is no longer needed and will likely be abandoned by the AC at our next meeting.

ARIN-2011-7: Compliance Requirement

This policy seeks to strengthen ARINs ability to enforce compliance with addressing policy, particularly WHOIS information requirements and also provide some additional checks on ARINs power in these proceedings. It was discussed in Philly at ARIN XXVIII but failed to gain consensus. A strong majority of the community did express interest in continuing to pursue the idea however so it will be discussed again at ARIN XXIX.

An interesting dynamic to this policy change is that most of the objections raised have actually been to current policy language, rather than to the actual changes being proposed. A careful analysis of the current policy text and the new policy text is required to fully understand what is and is not changing in this case. As the primary shepherd on this draft policy, I have revised and re-written the text several times in response to community feedback, most recently in February 2012, when I posted the current (fifth) revision. I hope that this newest text provides more clarity and also addresses all legitimate concerns raised.

The key changes are threefold:

• Adds “update reassignment information” as a requirement when an organization is out of compliance with ARIN policy. This is in addition to the current requirement to return resources. If an organization is efficiently utilizing their number resources but have failed to make the proper WHOIS entries, they should be required to make the entries, not return the resources.
• Adds “cease providing reverse DNS services” as an enforcement mechanism available to ARIN staff. This provides a means to attempt to grab the non-compliant organization’s attention before resource revocation is required.
• Adds a 90 day minimum timer before resource revocation can be initiated.

There is also some general language clean-up included, much of which was recommended by ARINs legal counsel.

ARIN-2012-1: Clarifying requirements for IPv4 transfers

As mentioned above, this draft policy seeks to rewrite the specified transfer policy in order to provide additional checks and balances into the process of paid transfers. The policy would place the following conditions on the source of a specified transfer:

• The source entity must be the current registered holder of the IPv4 address resources, and not be involved in any dispute as to the status of those resources.
• The source entity will be ineligible to receive any further IPv4 address allocations or assignments from ARIN for a period of 12 months after a transfer approval, or until the exhaustion of ARIN’s IPv4 space, whichever occurs first.
• The source entity must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request. This restriction does not include M&A transfers.
• The minimum transfer size is a /24

It would also place the following conditions on specified transfer recipients:

• The recipient must demonstrate the need for up to a 24 month supply of IP address resources under current ARIN policies and sign an RSA.
• The resources transferred will be subject to current ARIN policies.

ARIN-2011-1 would also place similar conditions on sources and recipients within the ARIN region when transferring resources into or out of the ARIN service region.

ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement

The purpose behind this draft policy is to make it possible for an organization that erroneously requests too little IPv6 space initially to be able to come back to ARIN and get more space when the problem is discovered. In the policy proposers own words (from the original rationale):

If you are executing to a long-term plan, you should be able to continue to execute on your approved allocation and assignment plan regardless of the number of regions/groupings you originally planned for. We want to promote tie downs on nibbles and long-term planning.

This is a noble goal, and one that I support. Unfortunately, the current text is problematic and simply untenable. I have suggested an alternative approach to the policy’s shepherds and I hope that we (the originator, the ARIN community, and the AC) can find a suitable solution to this problem in the near future.

ARIN-2012-3: ASN Transfers

This draft policy reads:

In NRPM 8.3, replace “IPv4 number resources” with “IPv4 number resources and ASNs”.

As you might guess, this change would allow Autonomous System Numbers (ASNs) to be transferred between organizations at will, under similar conditions as IPv4 addresses.

We should weigh the necessity for such a policy against the known and as of yet unknown dangers associated with the paid transfer of Internet number resources. Is there enough need for the transfer of ASNs to mitigate the risks involved? If you believe that there is, you should support this policy (and I’d love to hear about that need). If you don’t, you should oppose this policy, at least until such time as we better understand the full impact of specified transfers.

ARIN-2012-4: Return to 12 Month Supply and Reset Trigger to /8 in Free Pool

OK, first a bit of history on this one. Previously, organizations who had been ISPs in the ARIN region for more than one year could request up to one years worth of IPv4 addresses. As the world neared IANA IPv4 free pool exhaustion, the ARIN community adopted a policy which changed that from 12 month windows to 3 month windows effective on the date of ARIN receiving its last /8 from the IANA. In other words, once IANA handed out its last five /8s to the five RIRs, ISPs in the ARIN region had their maximum allocation cut to %25 of what it had been the day before.

The reason for this was an attempt to make IPv4 run-out in the ARIN region more fair. There is a large disparity between the largest and smallest service providers in our region. This leads to a large disparity in address consumption. There was a fear that with the 12 month justification window, a large ISP could come in and potentially take the entire remaining IPv4 free pool. The 3 month justification window helps mitigate that threat by forcing every ISP to take smaller bites and thus even out the consumption disparity a bit, allowing smaller ISPs a better chance to run out of IPv4 at about the same time as larger ISPs.

So far, this seems to be working – perhaps too well. IPv4 address consumption in the ARIN region has slowed considerably since the implementation of this policy in February 2011. This, coupled with the growing disparity between the specified transfer justification window (free pool = 3 months / transfer = 24 months) led to ARIN-2012-4.

This draft policy therefor seeks to re-set the justification window on ARIN free pool allocations to 12 months and then move it back again to 3 months when ARIN reaches its last /8 in inventory.

I have heard two strong sentiments from the ARIN community during (and previous to) my tenure as an AC member:

1. Predictability as IPv4 free pools exhaust must be a primary policy goal. Folks don’t want to have to plan for constantly shifting policy in addition to the already uncertain timeline and consequences of IPv4 run out.
2. Stop mucking with IPv4 policy. The Internet Protocol is dead, long live the Internet Protocol! IPv4 is moving steadily into legacy protocol status, IPv6 is obviously the next generation Internet protocol; it’s time to leave IPv4 be and focus on the future.

With those recurring themes in mind, I have a hard time justifying the request to undo the already executed change from a 12 month window to the current three-month window by moving back to a 12 month window… Only to once again shift back to three months at some point in the next 12-18 months (perhaps much sooner with a 12 month justification).

Miscellaneous

A couple parting shots:

First, some of you may remember that there is a global policy currently in flight. ARIN-2011-9, otherwise known as GPP-IPv4-2011, is a global policy which provides a mechanism for the IANA to receive and allocate IPv4 addresses to and from the RIRs post free pool exhaustion (aka: now). This is needed because upon reaching the final five /8s, the IANA entered the “exhaustion phase” which does not allow for any further allocation of IPv4 addresses. Since all five RIRs have adopted the policy, it is now in ICANN and, more specifically, the IANAs court. Louie Lee summed up the current status on 15 March 2012:

On behalf of the ICANN ASO Address Council and the global IP addressing community, I have forwarded the global policy proposal GPP-IPv4-2011 (also known as ARIN-2011-9 in the ARIN region) onto the ICANN Board of Directors for review and ratification.  The ICANN Board’s Review Procedures for such global policy proposals require a 21-day comment period.  ICANN has acknowledged receipt of this global policy proposal from the ASO AC and began a public comment period which will end on April 4, 2012.

The ASO Address Council expects ratification by the ICANN Board within 60 days.  Please stay tuned for further updates.

I will of course let you know when the ICANN board makes their decision.

Finally, for those of you who are not familiar (and even those that are), it’s a great idea to review and understand the process for creating policy change int eh ARIN region. The ARIN Policy Development Process (PDP) is available at: https://www.arin.net/policy/pdp.html.

Cheers!