RFC 6598 · · Best Current Practice

The fourth private range nobody voted for.

The official title is "IANA-Reserved IPv4 Prefix for Shared Address Space." What it actually decides: a new block, 100.64.0.0/10, for internet providers to run carrier-grade NAT without stealing the private addresses already sitting inside your house.

Status
✓ Still current
Also known as
BCP 153
Updates
RFC 5735

Written by Noel Lang · IT trainer

TL;DR

RFC 6598 reserves 100.64.0.0/10, the Shared Address Space. It is a fourth private-ish IPv4 block, but not for you: it exists so internet providers can run carrier-grade NAT without colliding with the 10.x, 172.16.x and 192.168.x addresses already used inside customers’ homes. If your router’s WAN side shows a 100.x address between 100.64 and 100.127, you are behind CGN and share one public IP with strangers.

The problem it solves, one layer up

RFC 1918 solved the address shortage for you in 1996: your home network reuses a shared pool of private addresses, and one public address per household is enough. It worked so well that IPv4 survived two decades longer than the math said it should.

Then, around 2012, the pool ran dry at a higher level. The providers themselves ran out of public addresses to hand out. A new customer signing up for mobile data or fibre could no longer be guaranteed a public IPv4 at all. The industry’s answer was carrier-grade NAT: put a second, giant NAT inside the provider’s network and let hundreds of customers share a single public address, exactly the way your household already shares one.

But that second NAT needs addresses of its own for the link between you and it. And this is where a subtle, expensive trap appears.

Why the old private ranges wouldn’t do

The obvious move was to reuse RFC 1918 space for the provider’s side. It is free, it is private, it is right there. The problem: your home already uses it. If your ISP ran its NAT on 192.168.x, and your router hands out 192.168.x inside your house, the two would collide. Your router would see the same range on both its inside and its outside, and the packets would have nowhere sensible to go.

This is the core of RFC 6598, and it is a genuinely clean piece of reasoning. Reusing public space that belongs to someone else would break connections to that someone. Asking for a fresh block of real public addresses defeated the whole point, since public addresses were the thing in short supply. The least-bad option left was to carve out one new /10, roughly 4.2 million addresses, that nobody had ever been told to use for anything, and reserve it strictly for this provider-to-customer plumbing.

The apartment building, one floor up

Keep the RFC 1918 picture: the internet is a city, your home is an apartment building, your public IP is its one street address, and inside, apartments are numbered privately.

Carrier-grade NAT is what happens when even the streets run out of addresses. Now a whole housing estate shares one street address and one central mailroom. Your building’s “street address” turns out to be just an internal unit number in the estate, meaningful only to the estate’s mailroom, which is your provider’s CGN. Shared Address Space is simply the rule that says which numbers the estate may use for those internal unit numbers, so they never clash with the apartment numbers already painted on doors inside each building.

The catch is the same catch, doubled. An apartment number means nothing outside its building; now a building number means nothing outside its estate. Mail addressed to your building specifically, an inbound connection, cannot find its way in, because from the city’s point of view your building does not have an address at all.

Two NATs stacked: what carrier-grade NAT looks like

The RFC 1918 diagram had one translation step. Carrier-grade NAT adds a second one inside the provider. Your private address becomes a shared 100.64 address, which becomes one public address you share with strangers.

Your home · RFC 1918💻 Laptop192.168.0.23📱 Phone192.168.0.42Home routerin: 192.168.0.1out: 100.64.10.5100.64.x · sharedProvider · RFC 6598Carrier-grade NATin: 100.64.10.5out: 203.0.113.7one public IPInternetshared with strangers
The 203.0.113.7 you appear to use is also several neighbours’ address. That is why a geoblock or a ban aimed at one of them can land on you.

What double NAT does to you

Most of the time you never notice, because outbound browsing survives two NATs just fine. The pain starts the moment something needs to reach you from outside. Port forwarding stops working, because the public IP is not yours to configure. Self-hosting a game server, a home camera, or a small website behind CGN ranges from awkward to impossible. Console and PC games flag your NAT type as strict or moderate, which hurts matchmaking and voice chat. Some peer-to-peer apps fall back to slow relay servers.

There is a social cost too. Because you share one public address with strangers, their behaviour becomes your reputation. A rate-limit, a captcha wall, a geoblock, or an outright ban aimed at whoever else is on your CGN can land on you, even though you did nothing. This is the quiet reason “why am I suddenly asked to solve captchas” threads exist.

The escapes are limited: ask your provider for a real public IPv4, which some sell as an add-on, lean on RFC 8200 where it is available, or reach your devices through a tunnel or relay that already has a public address.

What the RFC actually says

The original is short and readable, and unusually candid about being a stopgap. The map:

Section In plain words
1 · Introduction CGN needs an address range on the customer-facing side, and none of the existing options were safe. Here is a new one.
3 · Alternatives The heart of the argument: why reusing RFC 1918, squatting on someone else’s public block, or asking for real public space all fail. Reserving a fresh /10 was the least-bad option.
4 · Use of Shared CGN Space The rule: use it only between the subscriber and the provider’s NAT. It must never leak onto the public internet, and providers must filter it at their borders.
5 · Risk An honest list of what can still break: apps and devices that assume an address is either clearly public or clearly private get confused by a third category.
6 · Security One warning: this is not a trust boundary. A host must not treat a neighbour on the shared range as safe just because the address looks local.
7 · IANA Considerations The actual allocation, in a few sentences: 100.64.0.0/10, Shared Address Space, not globally routable.

Things people get wrong

  • "100.64.x.x is just another RFC 1918 range."

    It is not. RFC 1918 reserves 10.x, 172.16.x and 192.168.x. RFC 6598 reserves 100.64.0.0/10 separately, and that separation is the entire point. If your ISP ran its NAT on 192.168.x, it would collide with the 192.168.x network inside your house. A brand-new block guarantees the two layers never overlap.

  • "Being behind CGN makes me more secure."

    No. Like private addresses, Shared Address Space hides you from unsolicited inbound traffic, but that is a side effect, not a shield. RFC 6598 spells out that it is not a trust boundary: the other customers sharing your provider’s NAT are strangers, not housemates. Your firewall is still what protects you.

  • "Websites can see my 100.64 address."

    They cannot. Providers are required to filter Shared Address Space at their borders, so it never travels across the public internet. Any site checking "your IP" sees the one public address your CGN shares out, the same one your neighbours on that NAT appear to use.

  • "None of this would exist with IPv6."

    Correct, and worth stating plainly. RFC 6598 describes itself as a short-term measure while the internet migrates to IPv6 (RFC 8200). IPv6 has enough addresses that nobody needs to share, so there is nothing to carrier-grade-NAT. CGN is the tax we pay for IPv4 lasting longer than it should have.

How to tell if you're behind CGN

Shared Address Space leaves fingerprints. A field guide to spotting it on your own connection:

You see What it means
WAN IP 100.64.x.x to 100.127.x.x You are behind carrier-grade NAT. This is the RFC 6598 range, full stop.
Router WAN IP ≠ the IP a "what’s my IP" site shows There is a NAT layer above your router. With a 100.x WAN address, that layer is your ISP’s CGN.
Mobile data, 5G home internet, some fibre, Starlink Very likely CGN. These networks grew after IPv4 ran out and rarely hand each customer a public IPv4.
Games report NAT type "strict" or "moderate"; ports won’t open A classic CGN symptom. You cannot forward a port on a public IP you do not own.
A public IPv6 address but an IPv4 starting 100.x Dual-stack with CGN’d IPv4. IPv6 reaches you directly; IPv4 goes through the shared NAT.
100.64.x.x on a data-centre or lab interface Not always an ISP. Some Kubernetes, cloud and load-balancer setups borrow the range internally too.

Questions people actually ask

What is 100.64.0.0/10 used for? +

It is Shared Address Space, reserved by RFC 6598 for carrier-grade NAT (CGN). Your internet provider uses it on the link between your home router and their big NAT box. A 100.x address on your router's WAN side almost always means you are behind CGN and do not have a public IPv4 address of your own.

How do I know if I'm behind carrier-grade NAT? +

Log into your router and look at its WAN or internet IP. If it starts with anything from 100.64 to 100.127, you are behind CGN. A second tell: the address your router shows differs from the public IP a "what's my IP" site reports. That gap is the provider's NAT layer sitting between you and the internet.

Is 100.64.0.0/10 a private RFC 1918 address? +

No. It is private in the sense that it never appears on the public internet, but it is defined by RFC 6598, not RFC 1918. The whole reason it exists is to stay separate from 10.x, 172.16.x and 192.168.x, which are already in use inside people's homes. Two different documents, two different blocks, deliberately kept apart.

Why can't I port forward or host a server behind CGN? +

Because the public IP is not yours. It is shared with dozens or hundreds of other customers on the provider's NAT, and you cannot open a port on a box you do not control. Inbound connections, self-hosting, some peer-to-peer and console gaming all break or degrade. The usual fixes are asking the ISP for a real public IPv4 (sometimes paid), or using IPv6, or tunnelling in through a service that has a public address.

Would IPv6 make carrier-grade NAT unnecessary? +

Yes, and RFC 6598 says as much. CGN is explicitly a short-term patch while the industry moves to IPv6, which has enough addresses to give every device a public one and no reason to share. Where IPv6 is fully deployed, there is nothing to carrier-grade-NAT. Shared Address Space is a bridge, not a destination.

Referenced by

Other explainers on this site that point back to this RFC:

How RFC 6598 connects

What came before

  1. RFC 1918 RFC 1918 gave every network private addresses. Twenty years later even the ISPs ran out, so 6598 added a fourth block just for them. Same trick, one layer up.

  2. RFC 791 Defines the 32-bit address that only reaches about 4.3 billion values. Shared Address Space exists because that number was never enough. 6598 is a symptom of 791's original sin.

Part of a guided cluster: The networking basics, explained