At the RIPE meeting this week in Madrid, a new presentation on the IPv4 transfer market was presented.
Measuring the IPv4 Transfers Market (copy) Video
Last week at the ARIN/NANOG meeting in Dallas, two other presentations were made about transfer market.
How to Navigate Getting IPv4 Space in a Post-Run-Out World (copy) Video
Smarter Purchasing of IPv4 Addresses in the Market (copy) Video
Next 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.
In a recent report from the IETF meeting there was a discussion of considering IPv4 “Historic” from a protocols perspective. Geoff Huston notes his commentary in one of his recent posts. Spoiler alert: I for one think its a little to early to consider something that is actively used by billions of devices every day “historic”…
I recently returned from the APNIC meeting in Auckland, New Zealand. Here are a few notes and highlights from the meeting.
A interactive panel on current trends in the IPv4 transfer market.
Alain Duran (ICANN Research) – IPv4 market might be considered concentrated depending on how you slice the data. The RIRs are reporting transfers in different formats and different fields and this is hindering analysis. Most transfers are happening in the region, but some are moving between the regions (ARIN is a net exporter). Most of the addresses that are being transferred are “old” ones that were issued more than 20 years ago. (copy)
Geoff Huston (APNIC) – The largest transfers are happening in the ARIN region. More than 58M addresses were transferred globally in 2015. There is a difference between what we see in the routing table for transfers vs. what is recorded in the registry. We don’t have a good way to measure the amount of addresses that are being Leased/Rented. We also can’t measure how many devices are behind NATs. Transfers aren’t making a difference in the route-table growth. (copy)
Sandra Brown (IPv4 Market Group) – Sandra that price will still rise, but is currently being depressed due to the large blocks (/8’s) coming to market. Price differentials between regions have largely disappeared since inter-RIR transfers have started with RIPE. Using the /16 as a base size block, pricing bottomed out in Sept 2015 at about $5/IPv4 address and is now in the $7-8 range for /16s. (copy)
Gabe Fried (HilcoStreambank) – Only 1/3 of large “Elephant” transactions have been recorded with the registry. Smaller blocks command price premiums, so some holders are choosing to break up their blocks and slowly sell them over the course of a year generating additional value to the current block holder. Largest transactions (Option Agreements): Buyer pays at closing, seller keeps the block until the buyer is ready to transfer, buyer retains the right to direct the seller to transfer the blocks to a specific receiver at a future time. 10% of the volume of addresses are direct transfers constituting 96% of transfer transactions. The remaining 4% of the transactions are 90% of the address transfer volume. (copy)
Q&A period included discussions about how Letters of Authority (LOAs) are being used to route blocks. Organizations should really check to see if people are really authorized to advertise blocks. There was some discussion about if reassignment records be used to record renting and leasing records? How can we bring more transparency to the industry for options contracts and leasing/renting issues.
All formal action items were resolved before the meeting; 2 policies were implemented recently: Prop-113 & Prop-114
Prop-113 – new minimum assignment criteria, for a /24
Prop-114 – new ASN assignment criteria
2 new proposals submitted were not accepted by chairs:
First proposal submitted allowed aggregation of /21 approvals instead of /22 from 103/8 and /22 from other pool.
Second proposal submitted required whois contact email should be validated once per month.
Prop-105 – IANA returns pool – allows an organization to get another /22
The IANA returns pool is depleting. The non-103/8 pool is for a second /22 per organization. The pool will deplete soon likely in April/May 2016. March will add a /15. September will add an /18. Recovered blocks, if any, go into this pool as well. When the pool depletes, it’s going to bounce a few times as it gets repeatedly depleted and then refilled. Secretariat proposed at the Jakarta meeting the creation of a waiting list for this pool. The staff has started working on implementation of the wait-list which will be based on a strict order of request.
Interesting presentation about blocks that are being hijacked and the methods (fraudulently prepared LOAs) to get the blocks routed. Don’t trust LOAs, they are sometimes not worth the “paper” they are written on.
BGP Hijack Issue on Nov 6 2015
Some hijackings are causing a race to the bottom of announcing everything as /24s in some cases. This could have longer-term issues if this type of behavior became the norm rather than a transient exception.
APNIC has a new tool that one can use to visualize ASN data.
Geoff Huston recently released his 2015 report on IP addressing. Here are a few notes from the larger report.