IPv4 exhaustion (2022)

Today is the 10th anniversary of World IPv6 Launch. IPv6 has been around since the 1990s, but some organisations were hesitant about using it for their websites. So, World IPv6 Day (in June 2011) was an opportunity for these organisations to enable IPv6 for 24 hours. That way, if anything broke then it would probably affect all these sites rather than just one, and therefore it would be obvious that the problem was related to IPv6 connectivity in general rather than Facebook (or whatever) in particular. Also, these problems would only be temporary, for the duration of the 24 hour test. This event was successful, so it was followed by World IPv6 Launch in June 2012: this was when lots of companies would enable IPv6 and then leave it turned on permanently.

Meanwhile, ISPs (Internet Service Providers) are gradually making IPv6 available to more customers (in parallel with IPv4). Google have statistics for IPv6 adoption, showing the percentage of their users who connect to Google services over IPv6; this includes the Google search engine, along with Gmail, YouTube, etc. Globally, that’s now up to 38%, with the UK on 44%, the USA on 50%, and France in the lead on 71%.

So, this is a good time to summarise the current state of IPv4 exhaustion; what does it mean, and how significant is it? In brief, we’re now at the point where UK ISPs can’t get any new IPv4 addresses; they’re almost at the point of operating a “one in, one out” system, i.e. they’ll have to reclaim addresses from old customers in order to issue them to new customers.

As an analogy, think of baked beans. I can’t buy a single can directly from Heinz, because they sell in bulk. Instead, they send their lorries along the motorway, packed full of pallets, going to distribution centres. Each distribution centre would then send out trucks to the individual supermarkets, which might just have one pallet of beans (along with various other items). The supermarket would then open up the pallet, and put the cans onto the shelves. I can then take a can off the shelf and put it in my basket.

Turning to IPv4, there’s a big pool of about 4 billion addresses. Some of these are reserved (e.g. the private address space defined in RFC 1918), but most are for public use.

Originally, these were held by IANA (the Internet Assigned Numbers Authority). IANA then issued these addresses in /8 blocks (roughly 16 million addresses at a time) to the 5 RIRs (Regional Internet Registries):

  • AFRINIC (Africa)
  • APNIC (Asia Pacific)
  • ARIN (North America)
  • LACNIC (Latin America and some Caribbean islands)
  • RIPE NCC (Europe, the Middle East, and Central Asia)

APNIC and LACNIC then issued addresses to NIRs (National Internet Registries), e.g. JPNIC (for Japan) and VNNIC (for Vietnam). The NIRs then issued addresses to LIRs (Local Internet Registries); in some cases, the RIR would also deal with LIRs directly.

AFRINIC, ARIN, and RIPE don’t have NIRs, so they issued addresses directly to LIRs.

The LIRs are usually ISPs (e.g. BT or Sky Broadband in the UK), and they issue addresses to customers. E.g. if you have a VDSL connection then you’ll typically get 1 public IPv4 address with it, and you’ll use NAT (Network Address Translation) so that your devices can all use private IPv4 addresses across the local network. If you have an Ethernet connection (formerly known as a leased line) then you might get a block of 8 public IPv4 addresses, but you’ll still need to use NAT internally; the days of getting a public IPv4 address for every device on your network are long gone.

This diagram illustrates the basic idea, although there are too many LIRs to include by name:

Hierarchy of IANA, RIRs, NIRs, and LIRs

As you might have noticed, some of the description above used the past tense.

On 2011-02-03, IANA ran out of IPv4 addresses, issuing a final /8 block to each RIR. After that, each RIR just had to make do with the addresses that they’d already been issued; they wouldn’t get any more. Putting that another way, every possible IPv4 address has either been allocated (to an RIR) or it’s reserved (via an RFC).

Taking another food analogy, Kellogg’s stopped making Ricicles in January 2018. I.e. from that point on, there were no more lorries delivering pallets to the distribution centres. However, the cereal boxes didn’t immediately disappear from shelves, because there were still existing boxes working their way along the pipeline.

In a similar way, it took a while for the RIRs to use up their supply of IPv4 addresses:

  • AFRINIC entered phase 1 of their exhaustion phase on 2017-03-31, when they reached their final /8 block. They entered phase 2 on 2020-01-13, when they had no more than a /11 block left (roughly 2 million addresses). Their current policy is that LIRs can get a maximum of a /22 block (1024 addresses).
  • APNIC reached their final /8 block on 2011-04-15 (2 months after the final allocation from IANA). Their current policy is that new or existing members (NIRs) can get a maximum of a /23 block (512 addresses).
  • ARIN reached their final /8 block on 2014-04-23. Their free pool reached zero on 2015-09-24. Their current policy is that IPv4 addresses are only available for 2 specific scenarios (IPv6 transition and critical infrastructure); everyone else has to go on a waiting list and wait for someone to return addresses (e.g. if an LIR goes out of business).
  • LACNIC reached their final /8 block on 2014-03-17. They assigned the last remaining IPv4 address block on 2020-08-19. Their current policy is that new LIRs have to join a waiting list. When IPv4 blocks are returned, they get quarantined for 6 months, then each LIR can get a maximum of a /22 block (1024 addresses). NIC Mexico is applying the same policy, and I’m guessing that the same also applies to NIC Brazil.
    NB Existing LIRs can’t get any more addresses from LACNIC; only new LIRs can join the waiting list.
  • RIPE NCC reached their final /8 block on 2012-09-14. They allocated their final /22 block on 2019-11-25, so that’s when they completely ran out of IPv4 addresses. Their current policy is that LIRs can join a waiting list to request a single /24 block (256 addresses), if and when IPv4 addresses are returned; at the time of writing, the LIR that’s first in line has been waiting for 154 days. So, don’t hold your breath! Also, LIRs can only join the waiting list “if they have never received anĀ IPv4Ā allocation from the RIPE NCC before (of any size)”.

So, the IANA and 3 out of the 5 RIRs (ARIN, LACNIC, and RIPE NCC) have completely run out of IPv4 addresses, except for special cases. The other 2 RIRs (AFRINIC and APNIC) don’t have many IPv4 addresses left.

I’ve updated the diagram to show which registries have run out of IPv4 addresses:

Hierarchy of IANA, RIRs, NIRs, and LIRs with some crossed out

If you’re based in the UK, that means that your ISP can’t get any new IPv4 addresses from RIPE NCC; once they’ve used up everything they’ve got, they’ll either have to wait for existing customers to cancel contracts or buy a block from another LIR. However, there’s a limit as to how much trading can be done, because each LIR only has a finite number of IP addresses that they can sell. I don’t think that LIRs publish statistics for IPv4 exhaustion in the same way as RIRs, so I don’t know how close they are to zero.

My previous analogies involved food (baked beans and cereal). However, IP addresses are a bit different because they don’t get consumed; once you’ve got an address, you can keep using it for as long as you like (or at least for as long as you pay your bill). The problem will come when people want to set up new accounts, e.g. when they move house; at some point, the ISP will say “Sorry, we can’t give you a public IPv4 address”.

As a workaround, some ISPs have implemented CGNAT (carrier-grade NAT). With traditional NAT, all your devices have private IPv4 addresses, then your router has a public IPv4 address. With CGNAT, your router also has a private IPv4 address (on a different subnet to your internal network), then there’s 1 public address shared between multiple customers. However, this has some drawbacks; in particular, you can’t do port forwarding (to host a server), which means that peer-to-peer gaming won’t work if you’re on different ISPs.

More recently, Seth Schoen has suggested “cutting down on IP address waste”. However, that would require updating every device which uses IPv4, which I think is impractical; even if it worked, it would only be stalling for time.

So, the best solution is IPv6. All modern operating systems support this, and most network infrastructure (e.g. wireless routers) should do too. The main question is whether your ISP does, particularly if they’re supplying your router. You can test your IPv6 connectivity, and then contact your ISP if it doesn’t work.

Leave a comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.