On 3 February 2011, the Internet Assigned Numbers Authortity (IANA) allocated the last /8 blocks from the global IPv4 pool to the Regional Internet Registries. In a ceremony held by the Internet Corporation for Names and Numbers (ICANN), we (the RIPE NCC) received the block 185/8. At the time, the available pool still held 75 million IPv4 addresses, which were allocated and assigned according to a needs-based policy: Local Internet Registries (LIRs) documented their addressing plans and were allocated IPv4 addresses to cover a time period of three months.

It was not until 14 September 2012 that the pool dropped to the level where the only available space remaining was 185/8, the "last /8". This caused section 5.6 of the (then current) IPv4 policy to be activated, which stipulated that each LIR could only receive one final /22 allocation from this last /8 (or any other address space that was returned to the RIPE NCC). Five and a half years later, the space in 185/8 available for allocations is now exhausted. We wanted to take a moment to reflect on how this address space has been distributed and used.

Figure 1: Managing Director Axel Pawlik accepts 185/8 on behalf of the RIPE NCC on 3 February 2011

Timeline of allocations

With exception of two /16s set aside for Internet Exchange Points (IXPs) and for unforeseen circumstances, 185/8 was allocated in just five and a half years. This may have been faster than anticipated, but in comparison, the preceding /8 - allocated under the old needs-based policy - lasted only five months, from April to September 2012.

The more restrictive last /8 policy thus will have helped new entrants to connect to the Internet - organisations that otherwise would have had to try their luck on the transfer market. Figure 2 below shows the monthly allocation rate (figure 2a) and the evolution of total allocated address space from 185/8 (Figure 2b). Following an initial peak in demand immediately after activation of the last /8 policy, the allocation rate first showed a decreasing trend for around 12 months. However, from September 2013 onward, the general trend changed to one where the allocation rate increased, as more and more new LIRs were created. 

This trend of accelerated growth is also visible in the evolution of total allocated space over time. The blue line in Figure 2b, which plots the observed growth, is not straight and cannot be described by a linear model. A quadratic model (the green line) fits much better. The fit is not perfect, sometimes actual growth was a little slower, other times a little faster than the model - but overall the differences with the actual allocated address space are relatively small. This makes it useful in estimating future developments.

Figure 2a and 2b: Monthly allocation rate from 185/8 and the evolution of total allocated address space from 185/8

Who received the allocations?

The intention

In 2010, when it became clear that IANA would distribute its last available /8s to the RIRs in less than a year, the RIPE community developed a policy which set special rules for this final /8. Motivated by the observation that during the transition to an IPv6-based Internet, new entrants would still require some IPv4 space, it was decided not to allocate these last addresses according to demonstrated need, but rather to allow each LIR to request one small sized block (a /22) only. Quoting from the archived policy proposal:

The final /8 of IPv4 address space received from the IANA will have a special policy applicable to it in the RIPE region. This avoids the risk of one or a few organisations consuming the entire block with a well crafted and fully justified resource application. The proposal attempts to ensure that no organisation lacks real routable IPv4 address space during the coming transition to IPv6. It is very important that new entrants also have the chance to get some IPv4 space before it totally runs out because a small block of IPv4 addresses will be necessary for a while before the Internet can run on an IPv6-only platform.

Specifically, the prevailing idea was that the last /8 should be used to help the transition from IPv4 to IPv6, rather than for existing organisations to number their growing networks. Translated to the practice of daily operations at the RIPE NCC, the policy became:

• LIRs may only receive one allocation from this /8.
• The size of the allocation made under this policy will be exactly one /22.
• LIRs receive only one /22, even if their needs justify a larger allocation.
• A /16 will be held in reserve for some future uses, as yet unforeseen
• Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC.
• IPv4 PI addresses will not be assigned through this policy.

In 2011, this was amended with a clause that reserved another /16 for exclusive use by IXPs. When applying for IPv4 resources, an IXP can receive one single IPv4 assignment from this /16, no larger than a /22.

The reality

If the intent of the last /8 policy was to accommodate new entrants that would use IPv6 for their internal networks and required some IPv4 to connect to the global Internet, many of the new members joining the RIPE NCC after reaching the last /8 did not fit this model. With Provider Independent assignments via sponsoring LIRs no longer an option, a significant number of End User organisations signed up, seeing a RIPE NCC membership as the most affordable way to obtain (additional) IP addresses for their own infrastructure.

The stimulus in the policy to push members towards IPv6 turned out not to be working either. The majority of LIRs that requested IPv6 to qualify for a final IPv4 allocation, did not go on to do anything with IPv6. In recognition of this fact, and to avoid wasting IPv6 blocks, the RIPE community removed the IPv6 requirement from the policy in March 2015.

Another factor contributing to faster consumption of 185/8 was the creation of additional LIRs by existing members. Back in 2010, when performing the impact analysis for the last /8 policy proposal, the RIPE NCC had identified this as a possible risk. By November 2015, the scenario had become reality and the RIPE NCC's Executive Board temporarily suspended the creation of additonal LIRs. We published an article here on RIPE Labs that described the situation.

After discussion in the community, the RIPE NCC General Meeting in May 2016 lifted this suspension, allowing once more the creation of additional LIR accounts. By this time organisations had begun to get around the restriction by registering new business entities, each of which was able to open an LIR. It was felt to be fairer and in the best interest of the membership if additional accounts could be opened via the standard procedures rather than have them sneaking in via the back door. 

Grouping all related LIRs by member and counting the /22s held in total, we find that 10% of members today hold more than one /22 from the last /8. Some of these were obtained via transfer from another organisation, though most came from the member opening additional LIRs. Figure 3 shows the distribution. About 3,900 members still do not hold a /22 from 185/5, 12,000 have just one, 786 have two /22s and 190 have three. The distribution does have a long tail, leading up to one member with 66 /22s in its account(s). To better illustrate this, the bottom part of Figure 3 provides a zoomed-in view.

Figure 3: Distribution of the number of /22s held by members. The bottom half zooms in to the tail of the distribution.

Where are the allocations now?

The map in Figure 4 below shows the distribution of the /22 allocations per country, as recorded in the delegated statistics file. Because of transfers, this distribution is not necessarily the same as the distribution of countries where the blocks  were originally allocated. Transfers also caused some allocations to be split into /23s or /24s. To avoid cluttering the map, the totals have been rounded to nearest integer number of /22s.

It's no surprise that countries with large numbers of LIRs are also in the top ten when it comes to the distribution of allocations from the last /8. On a regional level, however, there are some interesting differences. For example, compared to their neighbours, relatively few organisations in Belgium or Portugal have requested IPv4 space from the last /8.

 
Figure 4: Geographical distribution of allocations from 185/8.

How many /22s are in the routing system?

Although several scenarios exist where public IP addresses obtained from RIRs are needed to number networks but do not need to be announced in the routing system, the stated intention of the last /8 policy was provide newcomers with a way to connect to the IPv4 internet. This raises expectations for the /22s allocated from this address block. To investigate the level to which these allocations are present in BGP, we look at the data from RIPE NCC's Routing Information Service (RIS). For all the address space that was allocated in each month, we checked the latest table dumps to determine the percentage that was covered by announced prefixes. Figure 5 below shows the results.

 Figure 5: Visibilty of monthly allocated address space in the routing system

It's easy to understand why address space allocated in the most recent months has the lowest percentage of coverage in the Border Gateway Protocol (BGP). After receiving an allocation from the RIPE NCC, organisations may need some time to set up their network and make arrangements for transit. Nevertheless, even when we exclude the results for the last seven months, a general trend of decreasing visibility remains: the older the allocations, the better the coverage in BGP. Where address space allocated in autumn 2012 sees over 90% routed, this gradually drops to under 75% for addresses allocated in Spring 2017.

What happened in transfers?

Figure 6 shows the monthly transfers from 185/8. Initially, the IPv4 policy didn't place any restrictions on transfers from the last /8. The relevant section of the policy was developed before the idea of setting aside a /8 with a rationed allocation policy was born. When in 2015 it became apparent that an increasing amount of /22s were being transferred to different LIRs within weeks or days of being allocated by the RIPE NCC, the community adopted a change to the policy which set a 24-month holding period on all IPv4 space coming to an LIR, whether via a transfer from another LIR or an allocation from the RIPE NCC. The effects of this are seen clearly in the monthly transfer statistics. The number of IPv4 addresses transferred from 185/8 fell sharply in August 2015 and remained low until November 2016.

Figure 6: Monthly transferred IPv4 addresses from185/8

In 2017 and 2018, transfers from 185/8 picked up again. However, whereas until August 2015 the median time between allocation and transfer was a mere 48 days, this has increased to a median of 2.5 years for transfers conducted after the policy change came into effect. In total, 1,164 blocks changed LIRs between 1 January 2013 and 15 April 2018. Most of these transfers were /22s. Only in 5% of the cases was the original /22 split up and transferred in parts.

The future

Although the last /8 received has now been exhausted, the RIPE NCC still has some 9.3 million IPv4 addresses in the available and reserved pool. Four million of these came from a pool of roughly 20 million addresses that was recovered by IANA and were distributed evenly to all five RIRs over a four-year period. The remaining five million addresses were recovered by the RIPE NCC, primarily when implementing the policy "Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region". As described in the implementation details, where the RIPE NCC did not receive a response from the End User, the resources were deregistered.

Extrapolating the growth in allocated addresses from the past five years, the remaining IPv4 addresses in the available pool are expected to last a further two years, until May 2020. This date does come with some uncertainty however. Faster growth in terms of new members requesting /22 allocations could bring the date forward, while recovering more (previously allocated) IPv4 space could push the date back a little. Those interested are invited to regularly check the  graphs of the available IPv4 pool on our website - these are updated weekly.