What Is a Bogon IP Address and Why It Matters
A bogon IP address is an address from private, reserved or unallocated space that should never appear as the source of traffic on the public internet. The name comes from "bogus", and the ranges involved are set by IANA and a set of RFCs, so checking whether an address is a bogon is a lookup against a published, standards-based list rather than a guess.
The main bogon ranges
There are two groups worth separating. Reserved special-purpose ranges are defined by standards and will never be routed publicly. Unallocated space, sometimes called "full bogons", is address space that no registry has yet handed out. The reserved ranges below are the ones you will meet most often.
0.0.0.0/8: "this network"; appears as a source when a host has no address yet.10.0.0.0/8,172.16.0.0/12,192.168.0.0/16: private networks from RFC 1918.100.64.0.0/10: shared address space for carrier-grade NAT (RFC 6598).127.0.0.0/8: loopback.169.254.0.0/16: link-local, assigned automatically when DHCP fails.192.0.0.0/24: IETF protocol assignments.192.0.2.0/24,198.51.100.0/24,203.0.113.0/24: documentation blocks (RFC 5737) that you will see in examples and tutorials.198.18.0.0/15: network benchmarking (RFC 2544).224.0.0.0/4: multicast.240.0.0.0/4: reserved for future use, plus255.255.255.255, the limited broadcast address.
For IPv6 the equivalents include ::/128 (unspecified), ::1/128 (loopback), fc00::/7 (unique local addresses), fe80::/10 (link-local), ff00::/8 (multicast) and 2001:db8::/32 (documentation). IPv4-mapped addresses such as ::ffff:0:0/96 and the NAT64 prefix 64:ff9b::/96 also deserve attention, because they are translation mechanisms that should not show up as client addresses either. Some older write-ups also list 192.88.99.0/24 (6to4 relay anycast), which has been deprecated.
Why a bogon in your logs matters
If a bogon appears as the apparent client of a request that came across the public internet, one of a few things is true, and it is not always malicious. Often the cause is plumbing: a reverse proxy or load balancer is not passing the real client address, so your application sees the proxy's private address; an X-Forwarded-For entry has been taken from the wrong position; or a NAT setup leaked an internal address into a public field. Those are configuration bugs and worth fixing because they break rate limiting, geolocation and abuse reporting.
The other cause is deliberate. Source addresses can be forged in packets and in headers, and attackers use bogon sources for spoofed floods or to probe filtering. Because legitimate traffic cannot originate from these ranges, upstream operators filter them at the network edge (the idea behind ingress filtering in BCP 38), and your own firewall should drop bogon sources arriving on public interfaces. Note the nuance: inside your network, private addresses are normal, so apply the rule only at the public boundary.
Reserved versus unallocated space
The distinction matters when you build your own filter. Reserved ranges are fixed by standards and change rarely, so a static table of them stays correct for years. Unallocated space is different, because registries hand out blocks over time and an address that was a bogon last year may belong to a real network today. Filters that hard-code unallocated blocks have historically blocked new customers of newly assigned ranges, which is why the reserved list is the safer thing to embed in application code and why ownership questions about public addresses belong to registry data rather than to a bogon list.
Checking an address
You can test any address in the bogon IP checker, which compares it against the published IPv4 and IPv6 reserved ranges and shows the matching block with a reference table. In the API, the IP lookup response includes bogon and bogon_type, so a log pipeline can flag these addresses without any custom range tables. The API documentation lists the full response.
One limit is worth knowing. The checker uses a standards-based reserved list, not a live view of what is routed. An address outside the reserved ranges is not guaranteed to be allocated or reachable. To find out whether a public address actually has an owner, use the IP whois lookup for the registry record, or the ASN lookup to see the network that announces it.
Practical handling
- Normalize and validate addresses early; reject bogons in fields that expect a public client IP.
- Drop bogon sources at your public edge with firewall rules, but do not apply them to internal traffic.
- When a bogon turns up unexpectedly, check proxy and load balancer configuration first, since misconfiguration is more common than attack.
- Remember that bogon addresses carry no geolocation, so skip geolocation and reputation lookups for them and save the request.