With the Autumnal Equinox behind us, fall is in the air and that means we are nearing the next ARIN PPM: ARIN XXX! It will be held 24-26 October 2012 in Dallas, TX.
Of course an impending ARIN Public Policy Meeting means that it’s time for me to provide a policy update, so, here it is!
Draft Policies
The following are all of the Draft Policies up for Adoption Discussion in Dallas next month:
ARIN-2012-2: IPv6 Subsequent Allocations Utilization Requirement
This proposed policy change has gone through several textual changes, without getting much clearer IMO. The final text (as I now understand it) does two things:
- It adds a sentence to the definition of an IPv6 serving site, explicitly removing any requirement to perform route aggregation at a serving site.
- It adds a third criteria under which a local Internet registry (LIR, typically an ISP in the ARIN region) can qualify for subsequent allocations of IPv6 address space.
The first change seems to be a textual clarification and probably a no-op. The second change is more consequential. Current policy includes two criteria under which an LIR can receive additional IPv6 address space (a subsequant allocation): “show utilization of 75% or more of their total address space, or more than 90% of any serving site“. The new criteria proposed in ARIN-2012-2 reads:
Has allocated more than 90% of their serving site blocks to serving
sites, and has sufficient actual utilization at their serving sites to
continue to justify the block size being utilized for all serving sites as
specified in section 6.5.2.
OK, that one is hard to parse, even for me. Since the referenced section 6.5.2. does not discuss actual utilization, I am unsure what “sufficient actual utilization” effectively means in this context (if anything at all). Unfortunately, even getting beyond the current text is hard because the stated rationale for the change doesn’t add much clarity either:
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.
I also want to promote subnetting on nibble boundaries and long term address planning in IPv6. But the fact is that existing policy allows LIRs to request very large amounts of space, based on nibble-boundary-aggregation, with allowances for long term planning built in (see ARIN-2011-3). That same policy also allows SPs who grab a too-small-allocation initially to come back and get the properly IPv6-sized allocation (See NRPM 6.5.7.) without a renumbering requirement. So I’m having a hard time understanding why this change is needed (and what it is really intending to do).
The only explanation that I have received is that this policy change is aiming to cover the case of an LIR that is unable to add additional serving sites after they have already received at least two allocations from ARIN. I take issue with that on two fronts. First, if you mess up your first allocation, you should really change your planning method for the second one – if you still screw it up, I have a feeling this policy won’t be able to help you anyway (especially considering how generous the existing policy already is). Second, we are very early in this IPv6 game, and we just last year implemented the current policy – is there really even one case of this happening in the real world today? I believe that policy changes should fix real problems, and so far I am unconvinced that there is a problem here.
ARIN-2012-5: Removal of Renumbering Requirement for Small Multihomers
Today, if you are an end-user (I.e. you use the addresses assigned from ARIN on your own network, not to hand out to customers), the minimum IPv4 allocation size (the smallest prefix you must qualify for to get space from ARIN) is a /20. There is however an exception to this minimum:
For multihomed end-users who demonstrate an intent to announce the requested space in a multihomed fashion to two or more distinct ASNs not owned or controlled by the end-user, the minimum block of IP address space assigned is a /24.
The catch is that any assignments smaller than a /22 must be returned (within 12 months) in order to get a larger block. So, if you get a /24 initially and then grow; you are required to return the /24 when you receive your /23, and then you must return that /23 in order to move up to a /22. This renumbering requirement is contained in section 4.3.6.2. of the NRPM, titled: Additional Assignments for Small Multihomers. ARIN-2012-5 seeks to remove that section from the NRPM completely. The effect of this would be, as the name of the draft implies, to remove the requirement for small IPv4 multihomers to renumber in order to receive more address space. The downside is that we may see more routing table fragmentation if small multihomers are allowed to keep and use multiple, small, non-aggregatable prefixes. The upside is that we may see more multihomed end-users able to get the provider independent (PI) space they need.
Of course, this being an IPv4-specific policy, we may see IPv4 address exhaustion make both points moot shortly after (or even before) the policy can be implemented.
ARIN-2012-6: Revising Section 4.4 C/I Reserved Pool Size
Currently ARIN has a /16 of IPv4 space reserved for “critical infrastructure.” The reservation of this space was set to expire three years from the implementation of the policy, which was on 27 July 2011; so it’s set to expire in a bit less than two years from now. ARIN-2012-6 proposes to double that reservation to a /15 and remove the expiration timer (thus reserving the space indefinitely). Since the current policy (ARIN-2011-4) was only adopted last year, and we have not seen any uptick in critical infrastructure requests since then (in fact, all CI ever handed out adds up to just over a /16 in total), I don’t see the need to make changes here at this time. Some reservation for critical infrastructure is good for the Internet, but reserving too many addresses for too long only robs other users of those addresses.
ARIN-2012-7: Reassignments for Third Party Internet Access (TPIA) over Cable
This one is somewhat of a sticky situation. As I understand it, Canada has laws that require their Cable companies to sell wholesale transit to competitive ISPs. In other words, they must allow third parties to provide Internet access over their physical infrastructure, for a reasonable fee (hence the TPIA name). This is similar to the common carriage laws in the United States which apply to telecommunications companies. Unfortunately, in a typical Cable network today, these third parties don’t have any view into what equipment corresponds to which addresses/customers. In response to this, the Canadian Cable companies require TPIA providers to number (add IP addresses) equally across all equipment in a given region that the TPIA provider wishes to serve. In most cases, this results in the TPIA provider (TPIA-P) using a lot of addresses to serve a small number of clients. Therein lies the rub. Once a TPIA-P numbers out a region, they are commonly unable to meet ARIN utilization criteria and thus unable to acquire more addresses. So, when the number of TPIA customers connected to one cable modem termination system (CMTS) exceeds the number of addresses available, the TPIA-P is stuck. They can’t move addresses around because of CableCo requirements and/or minimum prefix requirements on other CMTS’ and they can’t get more addresses from ARIN to number the fast growing areas. This is the dilemma that birthed draft policy ARIN-2012-7.
Despite this noble effort there are two potential problems:
- This is a hard issue to solve in policy; on one side you open the system up for abuse and on the other you keep the rules so tight that the situation is not improved. The current text is much better than the original proposal but still has problems.
- This feels a lot like a policy solution to a technical problem. While I don’t propose to have an answer, as I only know the details of the problem second hand, I’m not completely convinced there isn’t one. Right off the bat my mind wanders to the idea of network interface devices (NIDs) and tunneling, à la other Type-2 Ethernet services.
ARIN-2012-8: Aligning 8.2 and 8.3 Transfer Policy
Last but not least, ARIN-2012-8. This is the one policy I am shepherding for the Dallas PPM. Basically, this policy intends to bring the requirements, restrictions, and protections which are written explicitly into NRPM section 8.3. Transfers between Specified Recipients within the ARIN Region into section 8.2. Mergers and Acquisitions (M&A). From the rationale:
The base intent here is to lower confusion, raise clarity, and level the bar between 8.2 and 8.3 transfers. M&A transfers are distinct from specified transfers and not all of the same rules can apply – but many can and should. Therefor this policy change explicitly adds requirements which do not exist in 8.2 policy text today: [The transfer] source must be the undisputed current registered holder, [the transfer] recipient must sign an RSA (and is subject to [ARIN] policy), and [it adds a] /24 minimum [transfer size] for IPv4, /48 for IPv6.
The most persuasive argument against this change that I have heard is that ARIN staff already practices these controls for M&A transfers. Personally, I still think we are better of codifying the rules, rather than expecting people to know how things are done through experience.
Register Now!
The only way to have your voice heard is to participate. Register for ARIN XXX today (in addition to physical attendance, there is great remote participation available as well)!
