"Space is big. Really big. You just won't believe how vastly, hugely, mind-bogglingly big it is. I mean, you may think it's long  way down the road to the chemist, but that's just peanuts to space.”

Douglas Adams, The Hitchhiker's Guide to the Galaxy.

IPv6: How big is big really?

You can download the detailed IPv6 chart from here (see image on the right).

A /64 is big. A single /64 contains the equivalent of giving half of the entire IPv4 address space to every person on the Earth. Yet it’s considered the smallest building block of a network.

A /48 is even bigger. It contains 65,536 /64s, and yet we think about it as a reasonable “business” assignment and refer to it as a 'network' or 'site'.

A /32 and a /29 are massive, they cover 16 million domestic customers with a /56, and 512,000 “sites” with a /48s respectively.

A /12 is humongous. It would cover 1 million /32 allocations if we packed them continuously. And yet, we have managed to use this up in a mere 14 years. But, we’re not worried yet, there are 512 /12s within 2000::/3, and only a few of them have been allocated...

Seven years after the World IPv6 Launch, the RIPE NCC is the first RIR to request and receive another /12 from IANA. So how did we get to this moment? 

RIPE community policy in short

The first IPv6 Assignment and Allocation Policy in our service region was ripe-196, published on the 20 July 1999. This was a provisional joint document, shared with APNIC and ARIN, to ensure that IPv6 addresses would be managed with consideration to the long-term interests of the global Internet community. The policy allowed the RIPE NCC to issue /35s as initial allocations, while reserving 6 bits for the allocation to be extended to a /29. This meant networks could request more IPv6 in the future, while still having one single aggregated address block. The policy was updated in 2002, removing this reservation as an explicit requirement, after which it simply became customary to leave space between allocations, in case they needed to be extended.

The policies in each RIR service region are community-driven and so it was inevitable that they would diverge from the joint IPv6 policy over time.

Here is a summary of the main changes made by the RIPE community:

• ripe-196 (1999): Initial allocation size of /35 with a /29 reservation
• ripe-246 (2002): Initial allocation size of /32 with no explicit reservation
• ripe-466 (2009): Introduced Provider Independent (PI) assignments
• ripe-552 (2012): Initial allocation size can range from a /32 to /29 with no additional documentation needed
• ripe-641 (2015): Allowed IPv6 transfers between networks
• ripe-707 (2018): Clarified that an allocation could be requested for each LIR (rather than each member)

Goodbye 2a00::/12 

So, how did we manage to use a whole /12?

Figure 1: IPv6 prefixes allocated to LIRs by the RIPE NCC from 2a00::/12

This chart shows the IPv6 address space the RIPE NCC has allocated to LIRs from 2a00::/12. Approximately 75% of the address space was allocated in "standard" prefix sizes (between /32 and /29), which can be provided without justifying the request. 25% of the space is made up of allocations larger than a /29. These larger allocations are evaluated by our staff to check that the request is justified according to the documented needs of the LIR.

On 14 September 2012, we started to allocate IPv4 space from 185/8, and a new IPv4 policy came into effect. The policy's intent was to allow new entrants to interconnect their IPv6 networks with a still-largely IPv4 Internet. The policy therefore required LIRs to request and obtain IPv6 address space in order to qualify for their “last /22” IPv4 allocation.

Many new members joining after we reached our last /8 did not follow this model. As it was no longer possible to receive Provider Independent IPv4 assignments via a sponsoring LIR, a significant number of End User organisations became members to obtain IPv4 addresses for their own infrastructure.

While the policy aimed to push members towards using IPv6, in practice, it didn't quite work the way it was intended to. While LIRs were now obliged to request IPv6 to receive their IPv4 allocation, this did not mean they would actually deploy it on their networks. Recognising this, and to avoid wasting IPv6, the RIPE community removed this requirement from the IPv4 policy in March 2015.

Figure 2: Number of IPv6 addresses allocated vs. prefixes announced in BGP

The plots above and below clearly show the impact of the "last /8" policy. The difference between allocated and routed address space was not very noticeable until the policy came into effect. The gap has widened steadily since then. Similarly, the number of members without IPv6 decreased until the policy was updated in 2015, after which it began to grow again.

Figure 3: LIRs with and without an IPv6 allocation over time.

Unique requests

While it’s true that IPv6 has a seemingly endless amount of address space compared to IPv4, short-sighted or wasteful allocation policies could lead to premature exhaustion of the address space, as shown in the presentation “The Art of Running Out of IPv6 Addresses” by Benedikt Stockebrand at RIPE 77.

This is why RIPE's IPv6 policy explicitly lists "conservation" of address space as one of its goals, while recognising that there may be cases where an LIR needs an initial allocation greater than /29 or an extension of their allocation. In these cases the LIR can submit documentation to justify its request, which allows our Internet Resource Analysts to evaluate their needs.

It’s interesting to draw a parallel between this particular provision and the IANA-to-RIR IPv6 Policy: an RIR is eligible to receive additional IPv6 address space from the IANA only when some particular conditions are met and only after submitting a detailed justification.

So will the world run out of IPv6?

Well, not any time soon.

One of IANA's roles is to allocate Internet Number Resources (IP addresses and ASNs) from the global pool of unallocated resources to the RIRs, which then distribute them to networks in their respective service regions.

In December 1995, the Internet Engineeering Task Force (IETF) gave IANA responsibility for managing IPv6 address space (RFC 1881) while RFC 1884 defined the addressing architecture. This limited the Global Unicast Address range to 2000::/3 and reserved approximately 85% of the IPv6 address space for future definition and use.

On 14 July 1999, IANA started issuing /23 IPv6 blocks to the RIRs active at that time, in line with the relevant documents and RFCs.

The current IANA-to-RIR IPv6 Policy (also published as ripe-376) came into force in 2006, and is based on the following principles:

• The unit of IPv6 allocation from IANA to an RIR is a /12,
• RIRs are able to apply their own allocation and reservation strategies, as defined by their communities
• An RIR is eligible to receive additional IPv6 address space from IANA when certain conditions are met

Figure 4: Pool of available, reserved and issued IPv6 address space

This chart shows how our IPv6 pool has changed over time. You can see when we received 2a00::/12 from IANA and that most of this address space is held in reserve, allowing LIRs to extend their allocations in the future without fragmenting the address space. At present, this is good practice, though no longer mandated by policy. The amount of space reserved for each allocation has changed during the last 20 years as further updates have been made to the policy, balancing fairness with responsible stewardship of the IPv6 address space.

If you're curious about IANA's IPv6 assignments to the RIRs, you can view their registry here.

(Not so) slow and steady wins the race

The anniversary of World IPv6 Launch is a good chance to periodically take stock of how IPv6 deployment is doing around the world. In the first few years, there wasn’t much to celebrate, but as the statistics from our colleagues at APNIC show, good progress is being made – and we are starting to see some very real numbers – with large markets like the US and India crossing the 50% mark, and with Germany, Japan, France and the UK sitting between 30-40%. 

Of course, there is still plenty of red on the map, and more progress needs to be made. Today though, it seems that we are heading in the right direction – and it is important to recognise just how quickly these percentages can increase with the deployment of a single large service provider in a country (with India being one notable example of this).