A recent post on the NANOG mailing list made me look again at the size of the full BGP routing table. A full BGP table, held in routers in the default-free zone of the Internet, now consists of over 500,000 prefixes. This in itself is not a direct indication of how much of the address space is being consumed, but it did make me wonder.
We know that IANA, the numbers authority, ran out of IPv4 space to allocate in early 2011, and we also know that most of the regional registries are in the final stage of their IPv4 deployment plans: APNIC ran out on the 15th of April, 2011, RIPE ran out on the 14th of September, 2012, and ARIN ran out on the 23rd of April, 2014. LACNIC predicts it will run out in June 2014. This suggests that, even with time between address allocations being made and parts of those allocations being advertised over BGP, we should expect the advertised space to be nearing full, at least in those regions that have been exhausted.
I initially hand-waved that around 73% of the available IPv4 globally routable unicast space was already being advertised. In this post, I want to offer a bit more background on what that figure represents. I’ve written about this specific topic previously.
We all know that IPv4 addresses are 32 bits wide, but that doesn’t mean that IPv4 offers 232 publicly routable addresses. Blocks of addresses are reserved for particular purposes, and most of those are defined in the IPv4 special-purpose address registry. That document defines address blocks have particular meaning distinct from publicly routable unicast. The special-purpose space is as follows:
Combined, these reservations remove 592,708,864 potential addresses from the unicast pool, leaving a potential maximum occupancy of 3,702,258,432 addresses.
The Route Views project archives BGP state from routers located at various peering points around the world. The tables generated by different routers will vary slightly based on the time of day the state was dumped, the delays inherent in route propagation, and sometimes business or geopolitical filtering, but they’re approximately consistent enough that the routing state in any one collector is indicative of the full space being advertised globally over BGP.
Looking at BGP data from routeviews2 in the Route Views archive, the total space advertised on the 10th of May, 2014, was 2,684,231,168 addresses (ignoring any address blocks smaller than a /24 as space that would not have been advertised via BGP). Therefore, in simplistic terms, we’re currently advertising 72.50% of all of the IPv4 space. This figure, however, is global and doesn’t take into account regional variance. Where is the remaining 27.5% of the space?
The IPv4 space is carved up into geographic regions and primarily managed by the five regional Internet registries (RIRs): AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC. The IPv4 address space registry divides the address space into /8s (i.e., 224-sized blocks), and maintains a list of which RIR manages each /8. For historical reasons, there is space marked as legacy space which I’ll count separately from the rest of the space. This list gives us a broad indication of approximately where address space is allocated. Those /8 blocks don’t really move between regions, and eligibility for space from a given RIR is governed by various rules or expectations around where a business operates and where the space will be advertised from.
It’s not too difficult to then determine from the data and the space allocated to each RIR how much of it is advertised. If I accumulate the address space for each RIR and convert to a /8 equivalent, the amount of space consumed by each RIR on the 10th of May 2014 is as follows:
|RIR||/8s available||/8s advertised||/8s free||% advertised|
With little more than the equivalent of 60 /8s still to be consumed, a third of that is legacy space which might be difficult to reclaim. A little more than a third is in North America (which might not desirable for geographic and/or political reasons), leaving less than a third of the available unadvertised space for the rest of the world. Much of this is administered by APNIC, a strong growth region. RIPE, AfriNIC, and LACNIC are now grossly underprovisioned, with very little space remaining that has not yet been advertised in these regions.
routeviews2’s archives go back to 2002, so to consider how the space has grown over time I’ve taken a routing table for every May 10th going back to the the earliest available. There are two gotchas in the data, which are documented in the code I used to generate the plots: in 2004, a bunch of /8s were advertised from the same origin, all following the same path to routeviews2. These appear to be advertised in error, or part of a measurement project, but I couldn’t find a definitive explanation. Removing precisely that path removes the discrepancy. There’s a similar artefact in 2009 with a bunch of /9s advertised, again all following precisely one path. These, again, were filtered out.
The growth since 2002 looks as follows:
In this plot, the y-axis indicates the total number of /8 equivalents advertised into BGP, with the absolute maximum currently available for public unicast indicated by the dashed line.
The only decreasing “region” here is the legacy space, possibly through natural atrophy as organisations holding this space evolve, or prepare to return the space or sell it. Each of the geographic regions have grown. In particular, the two fastest growth regions here are RIPE and APNIC, the result now being that there is no more space for them to request from IANA, making it very difficult to receive new IPv4 address allocations in these regions.
Plotting the same data as a percentage consumed, it’s interesting to observe the proportion of each RIRs address space as it’s advertised over time. The /8s awarded to each RIR to administer has not been constant during throughout 2002 – 2014, but for the purposes of considering relative growth I’ve assumed that the May 2014 RIR allocation applies to the past. In fact, blocks would have been listed by IANA as unassigned prior to their allocation to a RIR, but I feel it’s more informative to see how the space available (now) at each RIR has filled out. The relative growth, shown as a percentage of current RIR administration, looks as follows:
It’s interesting to observe that the address space advertised from the RIRs with the least space available (LACNIC and AfriNIC) appears to be accelerating as their Internet sectors expand. This is in terms of the small amounts of space they administer, of course; the growth in these regions is still relatively slow. ARIN’s consumption appears near-constant, but advertisement of space from the APNIC and RIPE regions appears to have slowed since they exhausted their free pools. This, perhaps, is not super surprising: to an extent, organisations who request address space will have genuine reasons to use that address space. Portions of the unadvertised space may have been held by organisations for much longer, either to eventually be handed back to the RIR or reprovisioned and advertised in the future.
Something this data doesn’t cover is how much of the advertised space is being actively used. The difference between the amount of space advertised and the amount of space actually in use may be large. The ANT lab ran measurements on how much of the address space is responsive. This project leads to an underestimate, given that it’s technically asking how much of the space is responsive to ICMP pings. ICMP packets might be filtered by edge networks, or packets might be lost, links might be transient, or the hosts themselves might be transient. Further, unresponsive space doesn’t imply a lack of intent to use that space in the future.
If we do assume that, in many cases, most of a /24 is not utilised and never will be, would it be possible to stretch the IPv4 space out further by advertising and routing against smaller address blocks? There’s no BGP-level requirement stating that /25s or /26s couldn’t be advertised and propagated, but current practice is to limit propagation of advertisements to /24s or larger (primarily to avoid routing table state explosion). Given that it’s the concern of routing state that led to writing this post, I’ll assume that a widespread policy shift to allow /25s is unlikely.
Although we have the equivalent of over 60 /8s currently unadvertised, this space is not free for all. A little of that space will be held in reserve by the RIRs, and the equivalent of over 20 /8s are listed as legacy space owned by individual organisations. Some legacy blocks, like those owned by the US Department of Defense, are likely to never be released, though others might be if policy conditions are favourable and the price is right. An interesting diversion from here would be to investigate what parts of this legacy space is in use, and what’s been reclaimed recently.
Disregarding the 20 legacy /8s, and a /8 per RIR to assist IPv6 transition (some RIRs will retain less space, but let’s not bicker) this leaves the equivalent of around 35 /8s currently unadvertised. Many of those will already be allocated, and not yet advertised. Some of that space might even be forgotten about, and thus never will be advertised.
With the equivalent of 35 available /8s currently unadvertised, if we were to assume all of those will eventually be lit up, we’ll achieve the equivalent of 195 /8s advertised. That’s a respectable 88.4% utilisation. Naturally, the total address space advertised continues to climb. Though this expansion has slowed in recent years, between May 2006 and May 2011 the rate of change was notable (increasing by an equivalent of 10.6755 /8s (to May 2007), 10.066 /8s (to May 2008), 9.427 /8s (to May 2009), 9.77 /8s (to May 2010), and 12.947 /8s (to May 2011)). Numbers like those indicate just how tight the remaining unadvertised space actually is.
The amount of free space left to allocate is truly sparse, even with legacy space to potentially reclaim. Trading of IPv4 space is one mechanism to prevent the system from ossifying completely once all possible allocations are made, but movement of IPv4 space will still eventually become tricky.
The code I bolted together to generate the numbers and the plots is available on github.