Bogons, CGNAT, and Other IP Ranges That Will Ruin Your Day

The public IPv4 address space looks like a flat 4-billion-address pool from outside, but it is in fact carved up by a dozen reservations that should never appear on the internet. These ranges — collectively called bogons — are critical to filter in production network configurations, because their presence on internet traffic is almost always a sign of spoofing, misconfiguration, or malicious activity.

This article walks through every bogon range, the lesser-known semi-private ranges like CGNAT, and the operational impact of not filtering them. If you maintain firewall rules, BGP feeds, or any network ACLs, this is the reference you want.

The standard bogon list

Together, these ranges total roughly 593 million IPv4 addresses — about 14% of the total IPv4 space — that should never appear as a source on an internet uplink. If you see traffic from one of these ranges arriving on a public-facing interface, it is almost certainly spoofed or misconfigured.

The semi-private ranges that confuse people

CGNAT: 100.64.0.0/10

The biggest source of confusion. CGNAT (Carrier-Grade NAT) space is defined in RFC 6598 and reserved for ISP-internal use. It is not RFC 1918 private, but it is also not public — it sits in a third category specifically for ISP NAT pools.

The range contains 4,194,304 addresses, which is what mobile carriers use to NAT millions of subscribers behind a smaller pool of public IPv4 addresses. Real-world uses today:

• Mobile carriers NAT'ing subscribers
• AWS EKS clusters using 100.64.0.0/16 as a secondary VPC CIDR for pod IPs (avoids burning RFC 1918 space — see our Kubernetes CIDR sizing article)
• Tailscale and other overlay networks
• VPN concentrator client pools

Routes to this range are filtered at internet edges by most ISPs. CGNAT acts effectively private even though it is not RFC 1918. If you see 100.64.x.x traffic on your internet uplink, it usually means a customer's ISP is leaking their internal CGNAT.

APIPA: 169.254.0.0/16

The link-local range that hosts assign themselves when DHCP fails. If you see 169.254.x.x on a machine, your DHCP server is unreachable.

Legitimate uses include AirPlay, Bonjour/mDNS, and ad-hoc networking. The most operationally significant use today is the AWS instance metadata service at 169.254.169.254 — every EC2 instance reaches it for credentials and config. Azure similarly uses 168.63.129.16 (technically not link-local but uses the convention).

192.0.0.0/24 — IANA assignments

A small block reserved for IANA's protocol assignments. Includes 192.0.0.8/32 (IPv4 dummy address used by some applications) and 192.0.0.170/192.0.0.171 (NAT64/DNS64 well-known). Drop all of it on internet ingress.

198.18.0.0/15 — benchmark range

RFC 2544 reserves this for lab benchmark testing. You will rarely see it in the wild — but if you do, someone is leaking lab traffic onto the public internet.

Where bogons cause real damage

Spoofed DDoS attacks

Attackers spoof source addresses in reflection attacks. Without bogon filtering at your edge, the attacker's traffic uses fake source IPs from RFC 1918 or TEST-NET ranges, making attribution impossible. Standard bogon filtering at your network edge limits the source addresses an attacker can use.

BGP hijacks via bogon space

A malicious or compromised AS can announce a bogon range. Without BGP-level filtering, your routers may install routes to 10.0.0.0/8 via some upstream peer — disrupting all your internal RFC 1918 traffic. Standard practice: filter bogon prefixes in BGP imports.

Improper firewall rules

A rule like "permit any source to webserver port 443" will accept connections from 169.254.x.x if your edge is misconfigured. While rare in practice, lazy firewall rules that do not exclude bogon sources can be exploited in cases of route leaks or accidental peerings.

Internal misconfigurations

The most common bogon issue is internal: someone configures a static route to 0.0.0.0/8 by mistake, or uses TEST-NET addresses in a production config thinking they are private. The result is silently broken traffic for that range.

Sources of bogon lists

The bogon list changes occasionally when previously-reserved IPv4 ranges get allocated. Always use a maintained feed rather than hand-maintaining a list:

• Team Cymru Bogon BGP Feed — free BGP feed of current bogons. The industry standard for internet-edge routers.
• SpamHaus DROP and EDROP lists — "Don't Route Or Peer" lists of hijacked and bogus prefixes.
• RPKI route validation — does not directly filter bogons but reduces the risk of bogon hijacks by validating route origins.

IPv6 bogons

IPv6 has its own bogon list, though the space is so much larger that bogons are a smaller percentage:

Also any prefix not currently allocated by IANA. Because IPv6 allocations change more frequently than IPv4, the maintained feeds (Team Cymru) are even more important.

Detecting bogons in your traffic

Our Validate tool checks a list of CIDR blocks for overlaps with reserved ranges. If you paste in a list of source IPs from a firewall log and run it through Validate, anything overlapping a bogon range is immediately visible.

For ongoing monitoring, flow analysis tools (NetFlow, sFlow, IPFIX) can identify traffic from bogon source addresses on your edge interfaces. Any non-zero count is worth investigating — it is either a misconfigured customer or an active attack.

Key takeaways

• The standard bogon list covers ~14% of IPv4 address space that should never appear on the internet.
• The most operationally important non-obvious ranges: CGNAT (100.64.0.0/10), link-local (169.254/16), and the three TEST-NET blocks.
• CGNAT is not RFC 1918 but acts effectively private. Modern cloud and overlay networking commonly use it.
• Filter bogons at your internet edge, in BGP imports, and in firewall rules.
• Use a maintained feed (Team Cymru) rather than a hand-maintained list — bogon ranges change.