This is the second of two posts exploring the size of the IPv6 address space, how it’s delegated, and what that means for the Internet.
The first post in this series explored how and why APNIC delegates IPv6 address space to its Members using the ‘binary chop’ method, in which each subsequent delegation of IPv6 can be the size of all the previous delegations given to that Member in this part of the address space. Basically, they can double in size each time if need be.
Today’s post will explore the effects of this approach.
How many Members come back asking for more space?
Crunching the numbers on multiple requests
This question is a bit more complicated than you might think. Back before APNIC followed its current community-developed policy, it was far more restrictive, and most IPv6 applicants received a /35. The exception to this was a large number of applicants who received a /48. These were often enterprise-scale network holders who needed to multi-home in BGP, or needed address portability, but who didn’t qualify for the scale of resource in a /32.
These delegations, of course, all came from the blocks that APNIC received from the Internet Assigned Numbers Authority (IANA). APNIC itself was getting quite small blocks of /23 size and was regularly in touch with IANA to get more.
From July 1999 to June 2004, APNIC received four of them.
Then there was a global change in policy for requesting resources from IANA in 2006. The allocation unit size changed from /23 to /12, which allows RIRs have a bigger pool to implement sparse allocation model. APNIC received 2400::/12 form IANA in Oct 2006. This meant APNIC had a single large integral space to work from thereafter.
This block was, in effect, partially fragmented, and APNIC had to work around some significant large delegations between the ‘little’ and ‘large’ halves.
But, in the spirit of equity, having given many address holders a /35, successive address policy decisions allowed these holders to be upscaled to a /32. So there is a large count of /35, /34, and /33 delegations for these early adopters, to get them to the /32 boundary.
But overall, the data on return requests is really encouraging. Most applicants don’t need to come back for more. Here’s a quick analysis of 11,086 requests for IPv6 over the entire history of APNIC delegations:
|Number of requests||Number of entities with this many requests||Notes|
|1||10,640||95% of applications|
|2||277||2.5% of applications|
|3||65||Includes former /35 holders|
|6 - 20||29||Typically ISPs|
Table 1 — The number of requests for IPv6 address space.
What’s clear in this summary is that 95% of all recipients of IPv6 address space haven’t come back for more. What APNIC delegates as a unit (be it a /32 or a /48) is typically enough.
Of the five percent who do come back for more, half come back just once. There is a cohort who have repeat requests scaling up to the /32 scale from historically smaller /35 units, and a small number of special cases who have justified more delegations.
What’s next for IPv6 delegation models?
As discussed in part one of this post, it’s common for recipients of delegations to want to mark out different things within their delegation. In BGP terms, this tends to be seen as a sub-prefix — a set of bits that denotes a place, in the case of the example discussed, a sub-region within a larger jurisdiction. It may be a nation-state that wants space for each province, or a government that wants space for each department.
Read more: IPv6 adoption in 2021
What if there was another way of using the address space?
Well, there is. It’s called ‘semantic addressing’ and is a kind of bitfield-marking, tagging the address in the high-order bits of the prefix. It’s something that some ISPs have started using to classify traffic in ways that permit them to run parallel networks across a large space, and perform filtering on the edge by a mask to a specific bit. It’s an alternative model of the address plan, using bits of the address to manage behaviours outside the normal routing decisions.
For example, eight bits of the address plan within a delegation could be set aside for eight distinct categories. One could be for government-secure applications, one for banking and finance, one for digital TV, one for mobile, and so on. They then perform router and switch management that permits them to give assurances to the government that their addresses can’t leak into the TV network, because they mask out under a simple rule: “Not with X bit set”.
This gives ISPs simpler filters to control addresses beyond routing; the address could be flowing in the same data network from the core to the edge, but be blocked from distribution into the normal customer network.
Another model of address consumption is to use the address field as ‘content addressing’ for materials. For instance, if somebody starts watching a TV series at episode one, it’s highly likely they will want episode two, three and four in order. If you can use this knowledge to move the video data ‘closer’ to them, you can map the episode names into the IP address space that routes close to them, and preload the content into a local datastore in the background.
They watch episode one with some initial loading delay, but episode two and onward is served locally.
These kinds of clever tricks in addresses aren’t part of APNIC’s engineering planning when delegations are determined. APNIC didn’t work on a model of eight bits of a prefix being eight flags, it worked on it being 256 subnets. The IPv6 delegation model was in RFC 3194, revised from RFC 1715. This model has its own advantages and disadvantages.
But the many different design decisions, like semantic addressing, alter the speed at which people may need bigger address space. They represent significant challenges to the basic address plan conservation model developed under community consensus.
Where should I look for more information about these IPv6 addressing models?
The various ideas around IPv6 addressing are interesting, and they are worth discussing. If you want to be part of that discussion, you should get involved! These ideas are under active discussion in the Internet Research Task Force (IRTF), which meets regularly at the Internet Engineering Task Force (IETF). A good survey of ideas is in this 2021 presentation [PDF] by Daniel King. The semantic addressing idea has been discussed by Huawei, China Telecom and Deutsche Telekom in this 2014 IETF draft. Brian Carpenter also discusses some of these ideas in RFC 8799.
Is IPv6 going to run out? Probably not
It’s easy to be scared by these changes. It’s easy to look at the increase in requests for larger blocks and be worried.
However, it’s important to remember just how big the IPv6 space is, compared to IPv4. However, the problem of scaling is a story for another day.
At this time, I just want to say that by examining the IPv6 address plan map as shown in part one, it should be clear that the amount of ‘unused’ space is significantly larger in IPv6. APNIC holds much more than it has delegated. Unless there is a radical change in address policy, I do not foresee a shortage of IPv6 in the current process, because we operate in the /12 model of 1/512 of the space available in the /3 of the entire number plan that the IETF and IANA consider appropriate for use at this time.
You read that right. If things get tight with what we have now, APNIC and the other Regional Internet Registries have about 500 times more space to use, out of 1/8th of the whole of IPv6, before we have constraints.
Read more: Measuring IPv6
In our current modelling, over the last 20 years we have not had recourse to IANA to ask for a second /12. In the prior life of IPv4 we consumed significantly ‘more’ blocks of addresses as requests to IANA, and earlier delegations. So, if we go by the simple question of ‘how often do you go back to IANA for more?’ the answer is ‘not very often.’
And for 95% of the recipients under APNIC, the same is also true. Most applicants get enough the first time they ask.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.