New Policies Implemented at ARIN! (NRPM 2011.4)
The American Registry for Internet Numbers (ARIN) announced today (27 September 2011) the publication of ARIN Number Resource Policy Manual (NRPM) version 2011.4. As an active member of the ARIN community and an elected member of the ARIN Advisory Council (AC), I am always excited to see new policies implemented (yes, I’m a special breed of geek) but this version is particularly exciting. I say this for two reasons and they are the two policies that have been (at least partially) implemented with this version of the NRPM: ARIN-2010-14 and ARIN-2011-3.
If you read my blog at any frequency, you’re probably tired of hearing about this one. So for those of you that do, I’ll keep it short.
The reasons for these (fairly sweeping) changes to the IPv4 and IPv6 reassignment and registration requirements were laid out in bullet-point fashion in the rationale of the proposal:
- Bring IPv4 and IPv6 policy more in line with each other to make the
NRPM easier to understand and comply with – at least as it relates to
- Specifically define what organizational information is required to
be added to WHOIS when reassignments are made to client organizations.
- To specifically state that a client organization may designate the
POC of their choice for any/all WHOIS entries in policy. This includes
designating an upstream POC as their own preferred POC (which allows
for simple reassignments).
- Expands the privileges previously reserved solely for IPv4 cable
ISPs to all ISPs/LIRs with residential/dhcp-type subscribers.
- Specifically define the term “residential customer.”
- Allow ARIN to conduct resource reviews based on failure to comply
with registration / reassignment policies.
Note: You can find the expanded rationale on ARIN’s site and my original thoughts on the need for these changes here on dp for more details.
The story of my struggle to get this policy implemented has already been told, mostly in my previous post “Petitioning ARIN Policy Proposal 109” and the others that it links to, so I won’t delve back into the gory details here – those who are interested can investigate further.
This is a policy that I have not written about previously (at least not that I can remember) but one that is quite important to the deployment of IPv6, and thus the future of the Internet.
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.
In more detail, this policy:
- Requires that allocations to ISPs be made on nibble (4-bit) boundaries (e.g. /32, /28, /24, /20, etc.)
- Sets the minimum allocation at /32 and the overall maximum at /16 (with an exception for a /36 to be requested by particularly small operators)
- Allows the maximum allocation to any individual ISP to be based on a uniform, nibble-aligned, addressing architecture
- Resets the qualifications for an IPv6 allocation
- Allows ISPs to come back for more space in a manner that is consistent with the (industry recommended) uniform addressing architecture
- Recommends that ARIN expand existing allocations to provide additional addresses when possible
Read the full text on ARIN’s website for the whole story.
Note: ARIN-2011-3 was partially implemented – today ARIN is “able to accept requests under policy 2011-3 for IPv6 allocations ranging from /36 to /24″ with functionality for allocations larger than /24 to come by mid-February 2012.