redzilla
IP Addressing

Inside the Internet: Public IPs, NAT & ASNs

Between your laptop and a server in Tokyo there are address translations, autonomous systems and peering deals. Let’s follow the packet — and learn to investigate any IP like a detective.

≈ 11 min read

The first time I left a condo camera system "ready to watch from your phone," I drove off feeling like a hero. Port 8080 forwarded on the router, local test flawless, happy client. Two hours later, the phone rings: nothing works from outside. I went back, checked the firewall, redid the port forward, rebooted everything twice… and then I finally looked at the router's WAN IP: 100.72.19.4. It looked public. It wasn't. I learned more about how the internet actually works that afternoon than in any course — and this guide is that afternoon, compressed, minus the embarrassment and the wasted gas.

The private neighborhood: why RFC 1918 exists

An IPv4 address is 32 bits: 4,294,967,296 possible combinations — about 4.3 billion. In the 80s that sounded infinite; today there are more chips with antennas than people on the planet. To avoid burning a globally unique address on every printer and smart light bulb, RFC 1918 set aside three blocks in 1996 that anyone can use inside their own network, no permission required.

Think of it as apartment 4B: it exists in thousands of buildings at once and there's never a conflict, because nobody mails a letter to "apartment 4B, Chile" and expects delivery. Inside the building, the unit number is enough. To reach the outside world you need the street address: the public IP.

BlockRangeAddressesWhere you'll see it
10.0.0.0/810.0.0.0 – 10.255.255.25516,777,216Corporate networks and datacenters
172.16.0.0/12172.16.0.0 – 172.31.255.2551,048,576The middle range everyone forgets (and Docker)
192.168.0.0/16192.168.0.0 – 192.168.255.25565,536Homes and small offices: your home router
100.64.0.0/10100.64.0.0 – 100.127.255.2554,194,304CGNAT (RFC 6598): your ISP's, not yours — more on this soon

The three RFC 1918 blocks add up to 17,891,328 addresses — nearly 18 million — reused in millions of networks simultaneously. The golden rule: these ranges never cross the internet. No router along the path will forward a packet sourced from 192.168.1.20; to get out, somebody has to translate it first.

172.16.0.0/12 ends at 172.31.255.255. The address 172.32.0.1 is public IP space belonging to someone else. Every so often an ACL shows up written as "anything starting with 172 is internal" — and it ends up blocking legitimate internet traffic, or worse, trusting it. The /12 runs from 16 through 31. Not one octet more.

NAT and PAT: the front desk that translates addresses

If private IPs can't leave the building, how does your laptop browse anything? Picture the front-desk clerk. Outgoing mail carries the building's street address plus a mailbox number, and the clerk writes in the logbook: mailbox 40001 = apartment 4B. When the reply arrives addressed to mailbox 40001, the clerk knows exactly whose door to knock on. That logbook is the NAT table, and the mailbox number is the port.

Technically: NAT (Network Address Translation) rewrites the packet's source IP; PAT (Port Address Translation — the "NAT overload" your router actually does) rewrites both IP and port, letting hundreds of devices share a single public address. Each conversation is identified by the 5-tuple: protocol, source IP, source port, destination IP, destination port. Change any one of the five and it's a different session — a new row in the clerk's logbook.

A packet crossing NAT: the source IP and port are rewritten according to the translation table Laptop 192.168.1.20 NAT router 203.0.113.7 Web server 198.51.100.10 BEFORE NAT (LAN side) src 192.168.1.20:51344 dst 198.51.100.10:443 AFTER NAT (WAN side) src 203.0.113.7:40001 ← rewritten dst 198.51.100.10:443 TRANSLATION TABLE — one row per 5-tuple proto inside outside destination TCP 192.168.1.20:51344 203.0.113.7:40001 198.51.100.10:443
The packet before and after NAT: the full 5-tuple lives in the router's translation table. Example IPs come from the documentation ranges.

Here comes the number that rules everything: the port field is 16 bits, so 65,536 values. Ports 0 through 1023 are reserved for well-known services, which leaves 1024 through 65535 for translation: 64,512 ephemeral ports per public IP. In other words, one public address multiplexes on the order of 64 thousand simultaneous sessions. Sounds roomy… until you remember that a phone running WhatsApp, Instagram, Spotify and 30 browser tabs keeps dozens of sessions open without anyone noticing.

Worked example: the day the ports run out

Let's model an office building that reaches the internet through one public IP — the same model behind the NAT/PAT exhaustion calculator, in case you want to plug in your own numbers.

  1. Available ports per public IP. Typical ephemeral range: 1024 to 65535. That's 65,535 − 1,024 + 1 = 64,512 ports.
  2. Demand. 700 users × 100 concurrent sessions each = 70,000 sessions asking for a port at the same time. (100 per user is not an exaggeration: browser + email + Teams + streaming get there effortlessly.)
  3. Compare. 70,000 > 64,512: that's 70,000 − 64,512 = 5,488 sessions left without a free port. Utilization lands at 70,000 ÷ 64,512 = 108.5%.
  4. What it looks like in the field. Above 100%, "the internet" doesn't go down — random connections fail. Pages that half-load, apps that keep retrying, video calls that connect on the third attempt. The classic "internet feels weird" ticket nobody can reproduce.
  5. Fix. IPs needed = ⌈70,000 ÷ 64,512⌉ = 2 public IPs. Capacity rises to 2 × 64,512 = 129,024 ports and utilization drops to a comfortable 54.3%, with headroom for Monday-morning spikes.

Another way to see the same limit: with a single IP and 700 users, each one gets at most 92 sessions on average. A single machine running torrents — or malware — can chew through thousands of ports on its own and leave the rest of the building queuing at the front desk.

The model assumes one port per session. Since the 5-tuple includes the destination, a decent NAT can reuse the same external port toward different destinations, so real capacity has some extra slack. Planning with the simple model keeps you on the conservative side — which is exactly where you want to be on a Monday at 9:00 am.

CGNAT: when your "public" IP is private too

Back to the condo and its 100.72.19.4. ISPs face the same problem your office does: they don't have enough public IPv4 addresses to hand one to every customer. Their solution? NAT the customers again, inside the carrier network: Carrier-Grade NAT. For that middle layer, RFC 6598 reserved 100.64.0.0/10 — 4,194,304 addresses that aren't RFC 1918, but aren't public either. No-man's-land between your router and the real internet.

Double NAT with CGNAT: the router's WAN address belongs to the ISP's 100.64.0.0/10 range and port forwarding cannot cross the second NAT Laptop 192.168.1.20 Your router NAT #1 ISP CGNAT NAT #2 Internet RFC 1918 WAN: 100.64.5.9 ISP-private (100.64/10) 203.0.113.7 truly public, shared The port you open on NAT #1 does not exist on NAT #2: port forwarding dies at the CGNAT
Double translation: your router NATs to an ISP-owned 100.64/10 address, and the carrier's CGNAT translates again to a shared public IP.

The practical consequence: there are two translations and you only control the first one. The port forward you set up on your router works perfectly… as far as the edge of your house. When someone tries to reach in from the internet, they knock on the ISP's CGNAT — and that box has no idea your camera exists. The packet dies right there, politely and without a word.

Before promising remote access, compare the router's WAN IP against what the world sees in My IP. If they don't match — or if the WAN address falls between 100.64.0.0 and 100.127.255.255 — you're behind CGNAT. Your options: ask the ISP for a (static) public IP, many sell it as an add-on; set up an outbound VPN like WireGuard or Tailscale; or use a reverse tunnel. And if the ISP offers IPv6, the problem vanishes at the root: every device gets its own address again.

Who owns that IP? Autonomous systems in three sentences

We know how the packet leaves your house. Who carries it from there? Three sentences, as promised. One: the internet is not a network — it's roughly 80,000 independent networks called autonomous systems (AS), each with a unique number: the ASN. Two: each AS announces the address blocks it manages via BGP, and its neighbors decide whether to believe it and where to route. Three: your packet hops across several ASes hand to hand — your ISP, one or two middlemen, the destination's AS — and that, literally, is the entire internet.

ASes connect under two kinds of deals: transit (I pay a bigger AS to carry me everywhere) and peering (two ASes swap traffic for free because it benefits both, usually at an internet exchange, or IX). That's why Netflix and YouTube feel instant: their CDNs peer directly with your ISP and the traffic barely leaves town.

Autonomous system graph: your home connects to your ISP's AS, which reaches the destination via paid transit or free peering Your home no ASN last mile Your ISP AS64496 Transit AS64497 CDN AS64511 Hosting AS65551 transit ($) transit ($) peering (free) The internet ≈ 80,000 ASes swapping routes over BGP
Each bubble is an autonomous system with its ASN (shown here with documentation numbers from RFC 5398). Routes are negotiated over BGP: transit is paid, peering is traded.

About the numbers: ASNs started at 16 bits (up to 65,535) and — same movie as IPv4 — ran out; today they're 32-bit, up to 4,294,967,295. There are two notations: asplain, the flat number (196629), and asdot, in high.low format (3.21 — the same number, because 3 × 65,536 + 21 = 196,629). The dot confuses older gear and breaks more than one regex, so it pays to read both. The ASN converter translates between them and also tells you whether a number is public, private (64512 through 65534 gives you 1,023 private 16-bit ASNs — the "192.168 of BGP") or reserved. A real, verifiable example: in Chile, Entel operates AS27651 — that single number identifies its entire network to the rest of the planet.

Detective mode: investigating any IP

With all the pieces above, investigating an IP takes under a minute. The kit has three tools:

  • How does the world see me? My IP shows your real public IP, your ISP's ASN and organization, geolocation and reverse DNS. It's also the quickest CGNAT test: if what it shows doesn't match your router's WAN, you know exactly what happened.
  • Who owns this IP? RDAP is the modern WHOIS: instead of free-form text, it returns structured data straight from the relevant registry (LACNIC for this part of the world). You get the owning organization, the full assigned range, and — the gem — the abuse contact: the official inbox for reporting that an IP is up to no good.
  • Need to filter the whole range? If you decide to block it or hunt through logs, CIDR to regex turns the entire block into a regular expression and an exact address range, ready for grep or your ACL.

Mini-case: an IP has been hammering your firewall all night. RDAP tells you in seconds that it belongs to a hosting company with a public abuse contact; you report it with logs, date and timezone — and along the way you find out whether that "international attack" was actually a university research scanner that sweeps the whole internet daily (happens more often than you'd think). It won't change the world, but abuse desks really do take down bots — and you stop guessing.

Your move

Open My IP and compare it with your router's WAN: you now know exactly what it means when they don't match. Then run your real numbers through the NAT/PAT calculator before some random Monday runs them for you. And the next suspicious IP in a log gets 30 seconds of RDAP: the internet stops being a cloud and starts being a map.

Tools to practice with