IP Address News

Providing you with a single site about IP Addresses News and Usage

IP Address News - Providing you with a single site about IP Addresses News and Usage

RIRs sign new service level agreement with ICANN

On June 29th, 2016, the RIRs collectively signed the service level agreement (SLA) that has been negotiated with ICANN for the IANA services.  This SLA or contract was negotiated as part of the number community’s portion of the IANA transition away from a US government contact with ICANN.

The IETF defines the Internet protocols and parameters, and in doing so delegates a portion of the number resources (IPv4, IPV6 & ASNs) used in those protocols to the RIRs for management.

The final step in the transition, from the numbering community’s perspective,  is for the US government to allow the contact for the IANA services with ICANN to expire, sometime before Oct 1, 2017.  Once the transition is completed, the RIRs will have a contract as a group with ICANN to provide the top-level coordination of the IPv4, IPv6, and ASN IP number resources.

ICANN and Regional Internet Registries Sign SLA for the IANA Numbering Services

 

ARIN 37 Public Policy Preview

ARIN37Next week is the ARIN 37 meeting in Jamaica.     Here is my look ahead at the policies being discussed at the meeting.  There is one recommended draft that will be discussed along with five other draft policies.  If you aren’t going to be there in person check out the remote participation options.

2015-3 Remove 30 day utilization requirement in end-user IPv4 policy (Recommended Draft)

Policy Summary: This draft policy removes the 30 day usage requirement for IPv4 end-users.

Discussion: This policy is intended to remove what has been considered an onerous requirement on end-users.  Under current policy an end-users is supposed to put 25% of their block into use with 30 days, based upon a 1 year allocation. This requirement has always been very hard for organizations to meet and has skewed the allocation sizes downward.  With end-users now forced to obtain assignments via the transfer market, this policy provision is even more restrictive.

Commentary: There has been some opposition to this policy because a few contributors believe there should be some near-term requirement for organizations which do not have any assignment history with ARIN.  However, I believe most people support removing this requirement.

2015-2 Inter-RIR Transfers to Specified Recipients

Policy Summary: This policy allows an organization which receives a transfer in the ARIN region to transfer it to another RIR within 24 months of receiving the transfer.

Discussion: The policy is intended to benefit large organizations which receive a block via transfer in the ARIN region and then want to transfer it to a subsidiary or other entity in another region.  This is needed for some organizations which wanted to move address blocks to regions/countries which required the addresses be registered in a local NIR before they can be used.  Language was added to the policy requiring the receiving organization be a subsidiary, but despite attempt to finalize the draft language legal issues were raised prevented which the policy from becoming a recommended draft.

2015-7 Simplified requirements for demonstrated need for IPv4 transfers

Policy Summary: Replaces the needs test for transfers with an officer’s attestation to 50% use within 24 months.

Discussion: This policy is intended to loosen the transfer requirements, but leave the other transfer qualification methods intact in case an organization want to use them.  This policy has seen limited support on the mailing list.  The ARIN AC is looking for if there is sufficient support for the ideas within this policy before proceeding to move this policy to recommended.  Issues raised included concern that the 50% utilization level is way to low.  In general, this policy and 2015-9 are supported by organizations which believe in lessening the needs-basis requirements for IPv4 transfers, but not supported by those who believe that the current needs-based requirements are still working and providing value so they should be retained.

Commentary: I personally like the idea of loosening the needs-basis requirements toward officer attestations of use as long as there is a requirement that the address blocks be used on an operational network.  We could quibble about the utilization levels, but 50% per block seems like the lowest one could go and still have the utilization rate be meaningful.  80% has been the requirement for a long time and retaining that level could be beneficial in bridging the gap for those who would otherwise not support the policy.

2015-9 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers

Policy Summary: Removes needs-based testing from the transfer policy.

Discussion: This policy has been supported and not supported by the “usual” sides in this debate.  This policy was recently proposed for abandonment during the March AC’s meeting, but that motion failed.  Most of the issue revolved around the lack of formal support for this policy.  The AC will be looking for statements of support at the upcoming meeting to see if there is a path forward for this policy.  The text of the policy has not really changed much since the last meeting, other than removing Inter-RIR transfers from the policy as to not upset the interdependent policies between RIRs.

Commentary: I have specifically noted two issues which I believe should be addressed in this policy. 1. I believe there should be a base requirement that address blocks should only be transferred to organizations which intend to use them on an operational network. 2. I don’t like how the policy is constructed from a textual perspective.  The policy uses the phrase “excluding any policies related to needs-based justification”  While I think I know what that means, there is no definitive definition of what exactly constitutes a “needs-basis policy.”  We should be constructing clear text which clearly states any requirements for a transfer.

2016-1 Reserve pool transfer policy

Policy Summary: Restricts the ability to transfer IPv4 blocks which are received from reserved pools including the critical infrastructure pool (4.4) and the IPv6 transition pool (4.10).

Discussion: This is a new policy which grew out of a discussion at the last NANOG meeting in San Diego.  It was noted by some of the participants there that these reserved blocks could be transferred and that was perhaps not what the authors of the reserved block policy had intended.  The current practice allows an organization to obtain a block for a specific purpose and then transfer it to another organization which can use it without restrictions.   The IPv6 transition block was also intended to allow block sizes smaller than /24.  Some contributors believe that if blocks are allowed to be transferred some operators won’t lower their filters to allow these smaller blocks to propagate in BGP.

ARIN 36 Public Policy Preview

arin-36-logoNext week is the ARIN 36 meeting in Montreal.   Here is my look ahead at the some of the policies being discussed at the meetings.  There are two recommended drafts that will be discussed along with nine other draft policies.  If you aren’t going to be there in person check out the remote participation options.

2015-1 IPv6 Initial End-User Assignments (Recommended Draft)

Policy Summary: This recommended draft policy allows organizations which have 13 different sites to qualify for an /40 IPv6 block.

Discussion: This policy is intended to aid the widespread adoption and stabilization of IPv6 by allowing small organizations to obtain a permanent block of IPv6 addresses rather than having to obtain a block from their upstream provider. There has been little opposition to this policy change and I expect it to move forward to Last-Call.

2015-4 Modify 8.2 section to better reflect how ARIN handles reorganizations (Recommended Draft)

Policy Summary: This recommended draft policy clarifies existing staff practice regarding reorganizations.  It explicitly notes that a needs-test is not required for reorganizations.

Discussion: This policy was created by the AC after a Policy Experience Report noted that the current policy is causing some confusion by the membership.  The AC originally consider this as a possible editorial change, but decided that it was best to put this policy through the entire policy process.  There has been no opposition to this codification of existing practice.  I expect this policy to move forward to Last-Call.

2014-14 Remove Needs Test on Small Transfers

2014-14 Policy Summary: This draft policy removes needs testing from blocks which are smaller than /20 and permits an organization to have one needs-free transfer per year as long as a corporate officer attests to the organizations need of the addresses.

Discussion: This policy was rewritten extensively, largely by myself, with input from members of the AC.  When the policy was returned to the list the new text seems to have fallen flat without much discussion.  In my mind this means I have crafted text that now appeals to very few because it makes great compromises between the two sides of the argument for and against needs testing in the transfer market, or people don’t think this type of policy will solve the problems that exist in the current transfer market.  I suspect this policy will likely be abandoned by the AC following the meeting.  Hopefully, at least we have a robust discussion about what types of policy changes are needed as ARIN moves to mostly processing transfers rather than issuing addresses from the IPv4 free pool.

2015-2 Inter-RIR Transfers to Specified Recipients

Policy Summary: This policy allows an organization which receives a transfer in the ARIN region to transfer it to another RIR within 24 months of receiving the transfer.

Discussion: The policy is intended to benefit large organizations which receive a block via transfer in the ARIN region and then want to transfer it to a subsidiary or other entity in another region.  (There is however no restriction in the existing text that it be a subsidiary.)   Some have not supported this policy as it is a “workaround” for broken geolocation issues.  Furthermore some have opposed this as they see potential for increased address market speculation.

2015-3 Remove 30 day utilization requirement in end-user IPv4 policy

Policy Summary: This draft policy remove the 30 day usages requirement for IPv4 end-users.

Discussion: This policy is intended to remove what has been considered an onerous requirement on end-users.  Under current policy an end-users is supposed to put 25% of their block into use with 30 days, based upon a 1 year allocation. This requirement has always been very hard for organizations to meet and has skewed the allocation sizes downward.  With end-users now forced to obtain assignments via the transfer market, this policy provision is much less relevant.

2015-5 Out of region use

2015-6 Transfers and Multi-national Networks

Policy Summary: This two policy drafts are followups to the previous policy 2014-1 Out of Region use.

Discussion: 2015-5 is a rewrite of the original 2014-1 policy but with the an expanded definition of nexus to determine if an organization should be allowed to obtain address blocks from ARIN.  2015-6 is a different look at the same problem and approach it by looking only at the transfer market.  In 2015-6, the policy instructs ARIN to ignore where addresses are utilized when processing transfers.  Currently ARIN only considers a block utilized if a covering route is announced in the ARIN region and the usual utilization requirements have been met.

There has been quite a bit of discussion on these two items and previous policy it will be interesting to see if either or both of them obtain enough support to move them forward to be a recommended policy at a future meeting.

2015-7 Simplified requirements for demonstrated need for IPv4 transfers

Policy Summary: Replaces the needs test for transfers with an officer’s attestation to 50% use within 24 months.

Discussion: This policy is intended to loosen the transfer requirements, but leave the other transfer qualification methods intact in case an organization want to use them.

2015-8 Reassignment records for IPv4 End-Users

Policy Summary: Allows end-user organizations to add reassignment records to the ARIN database.

Discussion: Reassignment records can be used for a number of different functions which could benefit the overall desire to increase database accuracy by allowing organizations to add additional details in the database.  This policy has been weakly supported on the list, but it will be interesting to see if it gathers more support at the meeting.

2015-9 Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers

Policy Summary: Removes needs-based testing from the transfer policy.

Discussion: This policy has been supported and not supported by the “usual” sides in this debate.  It is unclear if anything has changes substantially at this point such that a policy like this could move forward.

2015-10 Minimum IPv6 Assignments

Policy Summary: Sets a utilization “floor” to encourage ISPs to give users an adequate IPv6 allocation per the IETF guidelines.

Discussion: This policy is supported by those who believe that ISPs will not issue large enough blocks (e.g. /56 or larger) to end users.  Statements of non-support have been seen by operators who note that how they provision their network with their users is a organizational decision, not a registry and public policy issue.

2015-11 Remove transfer language which only applied pre-exhaustion of IPv4 pool

Policy Summary: Removes language in the policy manual which was used prior to IPv4 exhaustion.

Discussion: This policy is intended to cleanup the policy manual by removing language that is no longer applicable because the policy conditions under which policy sections were slated to be used are no longer applicable.

ARIN’s IPv4 wait-list already almost a /12

ARIN announced a new report (Waiting List for Unmet Requests) on its website showing its waiting list for IPv4 address space.  As of Aug 24, 2015, the list has already grown to almost a /12 worth of IPv4 address space in just 7 weeks since the first organization was put on the list July 1st, 2015.  Today, there are 56 organizations with requests on the wait list.  The average size is about a /19, with the largest request(s) being a /16.

While some of these requests will be filled with space from the IANA recovered address pool, some requests will not be met with the next allocation.  IANA is slated to issue its next block of addresses to each RIR on September 1st, 2015.  According to the published code IANA will issue a /14 equivalent to each of the RIRs.

Waiting List for Unmet Requests (snapshot – 20150824)

ARIN’s IPv4 free pool empty

American-Registry-for-Internet-Numbers-ARIN-LogoAs expected, ARIN was forced to turn away a qualified applicant earlier this week for IPv4 addresses as its stock has been depleted.  The organization was then put on ARIN’s waiting list with hopes that someday it still might get an additional block.  These leaves organizations with the prospect of waiting, using more NAT (network address translation), or purchasing IPv4 blocks from organizations which have excess addresses via the transfer market.

No doubt, we will continue to see calls for increased adoption of IPv6 in the next weeks, but as I’ve written earlier IPv6 in many ways has economic disincentives to deployment.  However, we continue to see the largest broadband and mobile providers continuing their rollout of IPv6 as these organizations are large enough that purchasing additional IPv4 blocks won’t scale over time.

While ARIN has a a few reserved blocks and special purpose blocks, and may receive some small allocations from IANA via the reclaimed address pool, the free pool is now exhausted and organizations can’t expect to obtain IPv4 addresses directly from ARIN.

This leaves the African registry, AfriNIC, as the only registry with an available IPv4 free pool.  As of today, using previous allocation rates, AfriNIC still has until April of 2019 before its address pool runs dry. Only time will tell if we see an acceleration of the use of AfriNIC’s pool from economic incentives outside the region.

I’ll update this post with articles from other locations with interesting takes on the event.

 

ARIN’s IPv4 pool has just a few drops left

ARIN-IPV4 counterThis has been a long time coming, but looking at the available addresses in the ARIN IPv4 free pool today, you can see that there are just a few specs of IPv4 addresses available.

While many of our predictions on when this day would come have been very wrong.  It can only be a matter of days now before some organization will not receive the block they would have normally received.

I would expect to see ARIN’s announcement either tomorrow (Friday June 26th, 2015) or early next week that the first organization which met the needs test and qualified for a specific sized block did not receive it because there wasn’t a block large enough in the pool.

ARIN-IPv4 blocks - 20150625

ARIN 35 Public Policy Preview

ARIN35Next week is the ARIN 35 meeting in San Francisco.   Here is my look ahead at the some of the nine policies being discussed at the meetings.  There are four recommended draft that will be discussed along with lots of other items on our agenda.  If you aren’t going to be there in person check out the remote participation options.

2014-1 Out of Region Use

Policy Summary: This recommended draft policy allows organizations which have a small block in the region to request resources for use outside of the region.

Discussion: This policy started after it became known that organizations which are generally outside the region were requesting resources and using them almost exclusively outside the region.  The primary motivation for these companies is that IPv4 has already been depleted at other RIRs.  The policy took a number of twists and turns, but in general the community would like to see organizations which are headquartered in the region to be able to get addresses for all of their networks globally.  While this seems simple reducing this to policy has been a challenge.

The policy as currently drafted only requires a small nexus of addresses in the region /22 of IPv4, /44 of IPv6, or 1 ASN.  ARIN’s legal counsel has raised strong concerns regarding this policy and those concerns will likely be the root of the discussion at the meeting.

2014-6 Remove Operational Reverse DNS Text

Policy Summary: This recommended draft policy removes text in the number policy manual which defines ARIN’s operational practice with regard to reverse DNS records.

Discussion: The purpose of this policy is to remove text out of the policy manual which is operational in nature rather than number policy.  It is planned that this operational policy be moved to other locations where it can be updated as needed by ARIN’s operational staff, rather than the number resource community.

2014-14 Remove Needs Test on Small Transfers

2014-14 Policy Summary: This draft policy removes needs testing from blocks which are smaller than /20 and permits an organization to have one needs-free transfer per year as long as a corporate officer attests to the organizations need of the addresses.

Discussion: This policy was rewritten extensively, largely by myself, with input from members of the AC.  When the policy was returned to the list the new text seems to have fallen flat without much discussion.  In my mind this means I have crafted text that now appeals to very few because it makes great compromises between the two sides of the argument for and against needs testing in the transfer market, or people don’t think this type of policy will solve the problems that exist in the current transfer market.  I suspect this policy will likely be abandoned by the AC following the meeting.  Hopefully, at least we have a robust discussion about what types of policy changes are needed as ARIN moves to mostly processing transfers rather than issuing addresses from the IPv4 free pool.

2014-21 Modification to CI pool

Policy Summary: This recommended draft policy sets asside an additional /16 for use by critical infrastructure.

Discussion: The policy is intended to benefit the  Internet exchange point community, which is rapidly changing in the region.  Given the imminent run-out of IPv4 free pool in the ARIN region, this policy is intended to insure that exchange points will have the number resources they need to continue to expand and provide needed interchange services for years to come.

2014-22 Removal of Minimum in Section 4.10

Policy Summary: This recommended draft policy changes the minimum block size from /28 to /24 for the IPv6 transition block.

Discussion: This policy increases the minimum block size because recent testing has noted that smaller blocks may not be routable.  This is, in my opinion, a chicken and egg, problem.  People aren’t accepting smaller blocks because there aren’t many of them now, and they haven’t really been issued by the registries to entities which have the ability to get them routed.  Others believe that the /24 boundary is so engrained in the operator community that they won’t change thus making smaller blocks basically useless to organizations which receive them.  I suspect that the larger ISPs and providers will support this change as it allows them to maintain the status quo rather than changing to support the changing network environment.

2015-1 Change in IPv6 End-User Assignment criteria

Policy Summary: This draft policy changes the assignment rules for small organizations.

Discussion: It was pointed out recently that a type of small organization currently cannot receive an IPv6 assignment because the criteria is too strict.  Furthermore, it is noted that renumbering is a complicated and costly process and these small organizations would not like to have to take on the renumbering process when they change providers.

IP addresses in 2014

Geoff Huston has posted his 2014 version of his IP addressing report.  A few notes from within the report.

  •  Cisco, Morgan Stanely, & Gartner predicted that by 2020 there will be between 25 – 75 billion devices on the Internet as the “Internet of things” comes to life with embedded devices all requiring connections.
  • LacNIC, RIPE, and APNIC’s austerity address pools are slated to be depleted between 2017-2021 if current trends continue to hold.
  • IPv4 transfers increased quite dramatically in 2014 with APNIC performing 340 a 220% increase, and RIPE 919 a 600% increase.  RIPE’s increasing transfers seem to be clearly being driven by the lack of needs-basis requirements in the region.
  • LacNIC and RIPE continue to lead the world in IPv6 allocations with 1,208 and 2,218 respectively.

Addressing 2014 – And then there were 2!  (copy)