This is the first of two posts exploring the size of the IPv6 address space, how it’s delegated, and what that means for the Internet.
Read part 2.
IPv6 was mainly introduced as an alternative to IPv4 for one simple reason: IPv4 addresses were running out.
But how large is the world of IPv6 when compared to IPv4? How big is the space to expand into? In today’s post, we’ll make some comparisons between the IPv4 and IPv6 spaces and look at how APNIC divides those address spaces to delegate them to Members.
When examining the Regional Internet Registry (RIR) delegated statistics files, you may notice a significant difference between how things look to be done in IPv4, and how they’re done in IPv6.
Let’s start with some examples.
Here are 10 delegations of IPv4, made during the same five-month window across 2010-2011, to eight entities:
apnic|IN|ipv4|223.224.0.0|1048576|20100914|assigned|A9199197|e-statsapnic|CN|ipv4|223.240.0.0|524288|20100803|assigned|A9248097|e-statsapnic|CN|ipv4|223.248.0.0|262144|20100713|assigned|A92869B9|e-statsapnic|AU|ipv4|223.252.0.0|16384|20100727|assigned|A91776C8|e-statsapnic|JP|ipv4|223.252.64.0|8192|20100727|assigned|A9290EF1|e-statsapnic|AU|ipv4|223.252.96.0|4096|20100727|assigned|A91776C8|e-statsapnic|JP|ipv4|223.252.112.0|4096|20100727|assigned|A918B936|e-statsapnic|CN|ipv4|223.252.128.0|32768|20110131|assigned|A92E14F7|e-statsapnic|KR|ipv4|223.253.0.0|65536|20100728|assigned|A925D762|e-statsapnic|CN|ipv4|223.254.0.0|65536|20100723|assigned|A92FD265|e-stats
Notice the fifth column. It may be a little hard to see in the format shown in Figure 1, which is a CSV-based reporting form that the RIRs came up with. The fourth column is the prefix, and the fifth column is the host count, because APNIC sometimes delegates ranges that can’t be represented as a single prefix instance. Here’s a ‘map’ of these 10 delegations to give you an idea of their relative sizes.
This shows two things. Firstly, not everyone gets the same size, and secondly, it’s all gone! All the space has been delegated, and if you look into the IPv4 map, the gaps between delegated ranges are small. They all butt up against something else that somebody else has. In fact, in the chunk of IPv4 space in Figure 1, there is no free space at all!
Read more: How bad is IPv4 exhaustion?
This is a key reason why address management is needed to begin with. There isn’t enough IPv4 address space to meet global community expectations, and at the same time, it’s necessary to limit how fragmented the space gets to prevent an explosion in the cost of routing by prefix count (the more addresses are spread out across more prefixes, the harder things are to find and the slower everything gets).
There are debates over this ‘cost of routing’ goal, but regardless, it is one of the goals that was used to drive the RIR address distribution model and is enshrined in the address policy that was developed by the community and put into place by APNIC.
Compare the IPv4 delegations to IPv6. Figure 2 is quite different to Figure 1. The grey spaces below are address space that is not delegated. The thin strips with bright colours are the resources that have been delegated.
Look at the difference! There is space around every single IPv6 delegation, and the space is far bigger than the delegations. APNIC preserves more IPv6 space than it delegates.
Notice how as you move from the highlighted allocated space on the left and go to the right, the undelegated grey space gets larger? That’s because of a deliberate logarithmic progression. In fact, it doubles in size. Each block is twice the size of its predecessor.
Read more: Whatever it is, you need more
How sparse allocation works: binary chop
The doubling in size of these gaps is not a mistake. APNIC follows a community-developed policy for delegation called sparse allocation to ensure two things:
- That organizations had some space ahead of their initial delegation in case they got bigger. This means that instead of routing two fragments of address space, they have a chance to route one bigger prefix. If APNIC gives an organization more space, it becomes part of a bigger chunk that is announced as one bigger prefix. Think of it this way — when you get a new house, there’s plenty of room in the neighbourhood, so the vacant lot next door has been set aside for you. When you need to expand, you can stay on the same street instead of having your premises all spread out across different parts of town.
- Organizations are given equal space for growth when they start out, ensuring equity. Unless an organization has a very strong case for why they need more to begin with, they get the same allocation.
In reality, over time, organizations do have different horizons of growth, but the policy that APNIC follows includes a mechanism to limit this effect at the outset. When the horizon has to be reduced, it is done equitably across all recipients in the same space. Over time, things ‘equalize’ to most organizations of similar size having similar horizons of growth without having to route two or more prefixes to achieve it.
The process of giving out a ‘chunk’ of address space, in this model of binary-chop (dividing things in two) means that every unit APNIC gives out creates a ‘partner’ space next door, which is exactly the same size. If you take this pair of things, it becomes a chunk that is exactly the same size as its neighbour, the total of which is now four times the size of the original unit. When another request for a delegation comes from this Member, the four-times-the-size sized unit is then paired up with another unit of that size, to make a unit of eight times the size, and so on. This explains the growth in size by doubling. It’s the process working exactly as designed.
This allows for rapid growth, even if the organization requesting address space has already experienced rapid growth. If the allocation sizes stayed constant, imagine how many times, say, Amazon, would need to request more space compared to a tiny ISP.
Modified sparse: binary chop in two strides big and little
APNIC implements this model in two forms — large and normal applications of address space. This is because APNIC could foresee a future in which every delegate gets IPv6 and the registry would run out and be forced to ask for another /12 of address space before it had achieved anything like 75% utilization. The alternative would be to reduce the horizon for growth in front of delegates. That didn’t sound like the best way to serve delegates.
Therefore, APNIC subdivided its /12 space into two spaces, one for the normal-sized delegation of a /32 to most Members, but permitting somewhat larger initial allocations where needed.
The second space of larger allocations would be designed for fewer participants, but if the initial request for space was sufficiently large APNIC would delegate from this half, to ensure preservation of a horizon of need for these applicants so they could grow from their already larger base.
The /12 for APNIC is 2400::/12. That’s a big block of IPv6 that runs from 2400:0000:0000:0000:0000:0000:0000:0000 all the way to 240f:ffff:ffff:ffff:ffff:ffff:ffff:ffff (f is the hex digit, which means ‘all bits set’ in a binary string of digits 0 or 1. For our purposes here, it means ‘a lot’, and includes all of the IPv6 combinations within that /12 prefix).
This space was divided into two halves.
The top half from 2408::/13 all the way to 240f:ffff:ffff:ffff:ffff:ffff:ffff:ffff is the big half, and it currently looks like this:
The size of these thin stripes is actually significantly ‘larger’ in IPv6 terms than in the previous image. These are delegations of a /26 to a /20, where the previous IPv6 map showed delegations of a /32 to a /26 or so. Remembering that the arithmetic of a prefix is kind-of backwards, the difference in size of a /26 to a /32 is 32-26, which equals 6 bits, and 2^6 is 64 times bigger. So the unit of scale APNIC works with is the ‘big’ side of IPv6 is at minimum 64 times bigger. When you get up to a /20, 32-20, which equals 12, and 2^12 is 4,096 times bigger!
This is a seriously large chunk of space. So, why is it done this way?
Big chunks can be subdivided in more efficient ways
Take a nation-scale telco, for example, or a former monopoly telco, or a large market player. Imagine an economy with a population of 400 million customers, with a legal structure of 16 provinces. It’s not unusual for provincial state boundaries to be recognized, or even have distinct sub-entities operating in these regions. Perhaps, there may be a couple of major cities that can be large enough to become special administrative areas all by themselves.
This model of a federated structure is not uncommon; it could reflect India, China, Brazil, or Russia. These are large economies with large populations and large regional elements, which make up a federation of semi-independent (sort of) legal entities under the single banner. In these situations, you are faced with two drivers when designing your network.
- Be as routing efficient as possible: Try to use fewer prefixes if possible. You want to have each independent operating entity be given enough space to manage all of its customers, without having to come back for more.
- Reflect any administrative or legal boundaries on how you operate: If you have to operate as a combination of sub-entities, you want them to have independent status inside the address planning and routing design.
Now you could have each of them come up with a joint address management process as individuals, go to all of that effort, and have completely unrelated blocks of addresses.
But, if the organization does operate a single offshore international link, or all its links are under one umbrella of management, it can use a single delegation of a ‘super block’ to make one single BGP announcement, covering all of the provinces, all of the major cities, and still allow each independent operator to manage a complex internal network.
That internal network may subdivide into fibre, cable, wireless-mobile, satellite, government, and banking… there can be any number of technological or organizational drivers to subdividing the address delegation into some rational plan.
Each time the organization wants to do this, it looks at its prefix, thinking “OK, so now I need to identify eight distinct classes of major subdivision. That’s three bits of my address plan (2^3 is 8) so if you imagine a /20, divided among 32 sub-entities you get 5 bits, so now the /20 is a /25.” Then the sub-entities have to construct 3 bits of space for their 8 distinct categories, so each /25 is now a /28. Suddenly, we’re actually not very far off the /32, which is the original starting place where most normal sized operators begin.
These large blocks look 4,000 times bigger. But, if you have to treat the 12 bits of the prefix as a ‘mask’ and subdivide by type, you consume bits rapidly. This is why APNIC ends up giving some organizations more: they service larger, more complex markets, and APNIC wants to help them manage address space and routing efficiently.
The next post in this series will explore the effects of this address allocation model.
How often do recipients of allocations come back asking for more? How many times? What’s next for IP address allocation models? Why is it unlikely we will run out of IPv6?
Tune in to the next post for answers to these questions!
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.