A bogon IP address is any IP that should never appear as a source on the public Internet. A martian is a narrower, stricter case: an address reserved for special use, or a packet that showed up somewhere it legally cannot be. Most documentation treats the terms as synonyms. They are not.
The distinction matters in practice. Bogon lists shift as RIR assignment state changes, which happens frequently for fullbogon ranges and for IPv6 space that IANA has not yet allocated. Martian address lists rarely change. Filtering them on the same schedule eventually leaks reserved traffic or blackholes recently assigned prefixes.
TL;DR
- A bogon is any IP that should never appear as a source on the public Internet, covering both unallocated IANA/RIR space and reserved ranges.
- A martian address is a subset of bogons: the reserved, special-purpose ranges defined by RFC 6890 and RFC 1918.
- A martian packet is a runtime concept: a packet whose source or destination is impossible on the interface it arrived on, per RFC 1812 §5.3.7.
- All martian addresses are bogons. Not all bogons are martians.
- Bogon lists change as RIR assignment state shifts (especially fullbogons and IPv6). Martian lists barely change. Filter them with that distinction in mind.
Bogons are a policy about address space. Martians are either a subset of that policy (reserved addresses) or a runtime detection pattern (impossible packets). Mixing them up leads to stale filters, false positives, or both.
Bogon vs martian in one table
Before the definitions, the shape of the answer:
| Concept | What it is | Source of truth | How often it changes | How you filter it |
|---|---|---|---|---|
| Bogon (total) | Any IP that should never appear on the public Internet | IANA + RIR allocation data + RFC 6890 | Shifts with RIR assignment state (frequent for fullbogons and IPv6) | Dynamic feed (Team Cymru) or regularly updated prefix list |
| Martian address | A reserved or special-purpose IP range | RFC 6890, RFC 1918, RFC 1812 | Years between changes | Static ACL or router-level filter |
| Martian packet | A packet whose source or destination is impossible for its interface | RFC 1812 §5.3.7 | N/A (runtime pattern, not a list) | Kernel sysctl (log_martians, rp_filter), router ingress ACL |
Team Cymru, which publishes the canonical bogon reference data the rest of the industry pulls from, defines bogons as "martians (private and reserved addresses defined by RFC 1918 and RFC 6890) and netblocks that have not been allocated to a regional internet registry." That sentence captures the whole relationship. All martian addresses are bogons. Not all bogons are martians.
The runtime version, "martian packet," is a different thing again: a packet that arrived somewhere it could not legally have originated. The two concepts overlap most of the time, which is why casual usage collapses them.
What is a bogon IP address?
A bogon falls into one of two buckets:
- Unallocated space. IANA has not assigned the block to a Regional Internet Registry (ARIN, RIPE, APNIC, LACNIC, AFRINIC). The block exists in the global address space but no operator has been delegated authority to announce it.
- Reserved space. The block is set aside by an RFC for a specific purpose, like private networking (RFC 1918) or shared carrier-grade NAT (RFC 6598), and is not meant to be globally routable.
A packet routed over the public Internet with a source in either bucket is spoofed or misconfigured. There is no legitimate reason for it to exist on a transit link.
The IPv4 bogon list has been shrinking for years because IANA has allocated almost all of its /8 reserves to the RIRs. IPv6 bogons still cover a huge fraction of the total address space because so much of IPv6 is intentionally unallocated. For the full list, the IPv4 and IPv6 bogon ranges reference has them in a scannable format with RFC annotations.
Beyond the basic unallocated-plus-reserved definition, the operator community breaks bogons into several more specific categories. The category determines both the filtering method and how often the list has to be refreshed.
Types of bogon addresses
Not every bogon is the same. Operators group them into a handful of distinct categories, and the distinction matters because a filter that works for one type is often the wrong answer for another.
1. Traditional bogons
Traditional bogons, sometimes called classic bogons, are the original definition: martian addresses plus IANA-unallocated space. This is the list most routers and firewalls have in mind when their docs talk about "bogon filtering."
The traditional bogon list used to change several times a year in the early 2000s as IANA handed out /8s to the RIRs. IANA exhausted its free IPv4 pool on February 3, 2011, so the IPv4 traditional bogon list is essentially static now. The only movement left is at the reserved-range layer, and those RFCs change on a scale of years. A traditional IPv4 bogon prefix list does not need frequent updates, which is part of why manual maintenance is still viable for this category.
2. Fullbogons
Fullbogons add a third category to the traditional definition: prefixes that IANA has delegated to an RIR but that the RIR has not yet assigned to an ISP. When IANA hands a /8 to APNIC, that /8 is no longer unallocated at the IANA level, but the individual /16s inside it are not yet reachable. Traffic sourced from an unassigned APNIC prefix on the public Internet is still either spoofed or misconfigured.
The practical consequence is that fullbogons move frequently. Team Cymru refreshes the fullbogon feed every four hours. Operators who want to filter at this granularity use a dynamic feed or BGP peering with a bogon route server rather than a hand-maintained ACL, because a manually maintained fullbogon list falls out of sync with the real state of RIR assignments and can end up blackholing legitimate prefixes once they go live.
This is where most of the operational pain around bogon filtering lives. Traditional bogon filtering is largely a set-and-review exercise. Fullbogon filtering is a subscription to somebody else's feed.
3. IPv6 bogons
IPv6 bogons deserve their own category because the ratio of legitimate to unallocated space is so different. IANA has allocated only a small slice of the IPv6 global unicast range (2000::/3) to the RIRs. The rest of the /0 is still formally unassigned, which means an IPv6 bogon filter is dropping most of the theoretical address space rather than a handful of /8s.
Team Cymru publishes an IPv6 bogon feed alongside the IPv4 one. The IPv6 reserved set is shorter than IPv4's but covers the same ground: loopback (::1/128), link-local (fe80::/10), unique local (fc00::/7), documentation (2001:db8::/32), and transition-mechanism ranges like 6to4 (2002::/16) and Teredo (2001::/32).
Dynamic feeds matter more for IPv6 than they do for IPv4. A snapshot-based IPv6 bogon filter can lag the real state of the IPv6 allocation table by months, which is a long enough window for a newly delegated prefix to sit in the blackhole column while its legitimate owner troubleshoots why nothing reaches them.
4. BGP bogons
At the routing layer, a BGP bogon is a prefix announcement for a range that should not appear in the global BGP table at all: a reserved RFC 1918 range, an IANA-unallocated block, or a fullbogon prefix that IANA has delegated but the RIR has not yet assigned. The concept is strictly about whether the prefix itself is allowed to exist on the public Internet, not about which AS is announcing it.
This distinction is worth calling out because BGP bogon filtering is sometimes lumped together with RPKI Route Origin Validation. They solve different problems. A bogon prefix list answers "should this prefix exist at all" and catches things like a rogue announcement of 10.0.0.0/8. RPKI ROV answers "is this AS authorized to originate this prefix" and catches hijacks where the prefix is legitimate but the origin is not. Operators typically deploy both, because neither catches the other's failure mode.
5. What is not a bogon
A prefix that is allocated to a real organization but currently unannounced is sometimes called dark address space. It is not a bogon. Dark space is legitimately owned, and its owner can start announcing it at any time. Treating it as a bogon and dropping traffic eventually causes an outage when the owner brings the range online.
The same applies to a prefix that is temporarily unroutable because of an operational issue somewhere upstream. Bogon classification is a statement about what a range is allowed to be, not about what it happens to be doing right now.
What is a martian address?
A martian address is a specific kind of bogon: an IP range reserved for a purpose that precludes it from appearing on the public Internet.
The term traces to RFC 1208 (1991), a humorous label for packets "from Mars" because no valid routable network matched the address. RFC 1812 formalized it in §5.3.7, which requires routers to filter martian source and destination addresses.
The current authoritative list of reserved ranges lives in RFC 6890, the IANA Special-Purpose IP Address Registries document that superseded RFC 5735 and RFC 3330. Some examples:
0.0.0.0/8(this network)10.0.0.0/8(private, RFC 1918)100.64.0.0/10(shared address space for CGN, RFC 6598)127.0.0.0/8(loopback)169.254.0.0/16(link-local)172.16.0.0/12(private, RFC 1918)192.0.2.0/24(documentation, TEST-NET-1)192.168.0.0/16(private, RFC 1918)198.18.0.0/15(benchmark testing)198.51.100.0/24(documentation, TEST-NET-2)203.0.113.0/24(documentation, TEST-NET-3)224.0.0.0/4(multicast)240.0.0.0/4(reserved for future use)255.255.255.255/32(limited broadcast)
For IPv6, the reserved set includes ::1/128 (loopback), fe80::/10 (link-local), fc00::/7 (unique local), 2001:db8::/32 (documentation), and several transition-mechanism ranges like 6to4 and Teredo.
Because this list is stable across years, martian filters can be maintained by hand without a dynamic feed.
What is a martian packet? (it's not the same thing)
Here is where most explanations lose the thread. A martian packet is a runtime detection pattern, not an address-space concept: an IP packet observed on an interface where its source or destination is impossible given the routing topology.
The textbook example is a packet arriving on a public-facing interface with a source of 10.0.0.1. That packet cannot legally have come from the Internet, because 10.0.0.0/8 is private per RFC 1918. Either the source is spoofed, the upstream device is misconfigured, or a downstream network is leaking private-range traffic outward.
On Linux, the kernel has two sysctls that govern martian packet handling:
net.ipv4.conf.all.log_martianscontrols whether the kernel writes a log entry when it sees a martian packet. Behavior depends on your distribution: some enable it in startup scripts, others leave it at the kernel default. Check the current value before assuming you would see martian entries in your logs.net.ipv4.conf.all.rp_filtercontrols reverse path filtering. Setting it to 1 (strict mode) or 2 (loose mode) causes the kernel to verify that a packet's source address is reachable via the interface on which it arrived. The upstream kernel default is 0, but many distributions override that in their default sysctl configuration. Check your distribution's default before you assume.
A typical kernel log line looks like:
kernel: IPv4: martian source 10.0.0.1 from 203.0.113.50, on dev eth0"Martian source" does not necessarily mean the packet contained a reserved address. It means the kernel could not route back to the source address via the interface where the packet arrived. A real public IP can still show up as a martian if your routing table says the traffic belongs on a different interface. This is the detail that trips up sysadmins when they first grep their logs for the term.
Classification: is this IP a bogon, a martian, or both?
The simplest way to internalize the distinction is to classify common ranges against both categories at once.
| Range | RFC | Martian address? | Bogon (unallocated)? | Bogon (total)? | Example use |
|---|---|---|---|---|---|
| 10.0.0.0/8 | RFC 1918 | Yes | No | Yes | Private LAN |
| 127.0.0.0/8 | RFC 6890 | Yes | No | Yes | Loopback |
| 169.254.0.0/16 | RFC 3927 | Yes | No | Yes | Link-local |
| 172.16.0.0/12 | RFC 1918 | Yes | No | Yes | Private LAN |
| 192.0.2.0/24 | RFC 5737 | Yes | No | Yes | Documentation |
| 192.168.0.0/16 | RFC 1918 | Yes | No | Yes | Private LAN |
| 100.64.0.0/10 | RFC 6598 | Yes (shared) | No | Yes | Carrier-grade NAT |
| 224.0.0.0/4 | RFC 5771 | Yes | No | Yes | Multicast |
| 240.0.0.0/4 | RFC 6890 | Yes | No | Yes | Reserved for future use |
| 203.0.113.0/24 | RFC 5737 | Yes | No | Yes | Documentation |
| An IANA-unallocated /8 | N/A | No | Yes | Yes | Nothing legitimate |
| An RIR-unassigned /16 (fullbogon only) | N/A | No | No (traditional) / Yes (fullbogon) | Depends on feed | Depends on feed |
| 8.8.8.8 | N/A | No | No | No | Google DNS |
Every martian address in the table is also a bogon. Not every bogon is a martian. For a complete scannable reference, see the bogon IP reference.
Bogon filtering best practices
Operators filter bogons for three reasons: spoofing defense (most DDoS traffic with forged source addresses uses bogon ranges), routing leak containment (stopping accidental private-prefix announcements from leaving the network), and data hygiene (reserved-range addresses break analytics, geolocation, and logging pipelines in subtle ways).
There are two schools for maintaining the filter list, and they are not interchangeable.
Manual prefix lists work for martian addresses because the set is stable. Writing a Cisco ACL or iptables chain once and reviewing it yearly is realistic. For traditional bogons the manual approach is fragile, because IANA allocations quietly invalidate entries over time. A year-old unreviewed filter often has a legitimately assigned prefix sitting in its deny list.
Dynamic bogon feeds are the right answer for fullbogons and any network that cannot tolerate stale filters. Team Cymru publishes bogon and fullbogon lists via BGP peering, DNS, HTTP, and text download. Peering your edge router with the Team Cymru route server means the filter updates itself whenever IANA makes an allocation. NANOG has recommended this approach for large networks since the mid-2000s.
A minimal Linux iptables rule set to drop private-source traffic on a public interface looks like this:
iptables -A INPUT -i eth0 -s 10.0.0.0/8 -j DROP
iptables -A INPUT -i eth0 -s 172.16.0.0/12 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 169.254.0.0/16 -j DROP
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROPOn a Cisco router, the equivalent ACL pattern is:
ip access-list extended BOGON-IN
deny ip 10.0.0.0 0.255.255.255 any
deny ip 172.16.0.0 0.15.255.255 any
deny ip 192.168.0.0 0.0.255.255 any
deny ip 169.254.0.0 0.0.255.255 any
deny ip 127.0.0.0 0.255.255.255 any
permit ip any any
interface GigabitEthernet0/0
ip access-group BOGON-IN inProduction ACLs should cover the full RFC 6890 set and include IPv6 equivalents.
Martian filtering best practices
Martian address filtering is simpler than bogon filtering because the list barely moves. RFC 1812 §5.3.7 requires routers not to forward packets with invalid martian source or destination addresses, and requires that any vendor-provided override default to the filtering state. Actual implementation varies by vendor, so treat RFC 1812 as the requirement and verify behavior on your own platform.
On Linux, the kernel handles martian detection rather than an explicit iptables chain. Enable logging so you can see what is happening:
sysctl -w net.ipv4.conf.all.log_martians=1
sysctl -w net.ipv4.conf.default.log_martians=1Add the same lines to /etc/sysctl.conf or a drop-in file under /etc/sysctl.d/ to persist across reboots.
Enabling log_martians does not change whether the kernel drops the packet. It only controls whether you see a log entry. The dropping decision is made by rp_filter. The upstream kernel default is 0, so verify the current value on your system before assuming strict mode is active:
sysctl net.ipv4.conf.all.rp_filterA value of 1 is strict mode. A value of 2 is loose mode, appropriate for multihomed hosts where the return path may legitimately differ from the arrival interface.
Logging helps debug the rare case where a martian signals a real downstream misconfiguration, but it also fills /var/log/kern.log on noisy links. Rate-limit with iptables -m limit or journald's RateLimitBurst if that becomes a problem.
Bogons, martians, and IP geolocation APIs
Reserved and unallocated IP ranges pose a practical problem for any application that looks up IPs. What should the API return when the input is 10.0.0.1?
There is no geolocation for a private address. There is no country for an unallocated prefix. An API that returns a fake answer, or silently returns a default record, poisons analytics and billing logic downstream.
ipgeolocation.io handles this in two different ways depending on which product the request hits.
The IP Geolocation API refuses to fabricate a location record for reserved or unallocated inputs. For bulk lookups, the documentation shows invalid entries returning an object with a descriptive message field identifying the input, for example {"message": "'10.0.0.0' is a bogon IP address."}. Valid public IPs in the same request are processed normally and returned alongside the error entries. Applications can branch on the presence of message per record rather than maintaining their own bogon range lookup table.
The IP Security API takes a stricter position for single lookups and returns HTTP 423 Locked for bogon and private-range inputs, with an error body identifying the range. Full behavior is documented in the security API documentation. For bulk lookups, bogon, private, and malformed IPs are not counted against the request quota or billed as credits, so running a cleanup pass over dirty log data costs nothing.
If you are building an IP-intelligence pipeline against any geolocation or threat API, verify this behavior before going live. An API that returns default country codes for reserved ranges quietly corrupts your data for months.
Frequently asked questions
In most cases, yes. Edge bogon filtering blocks spoofed traffic with reserved source addresses and prevents internal private-range leaks from being advertised outbound. Apply the filters carefully, though: Team Cymru warns that bogon filtering can have adverse impacts if misapplied, especially around shared ranges like 100.64.0.0/10, so test before deploying on a production edge.
Nothing. "Bogon" is networking slang derived from "bogus." The term was popularized in the 1990s by the IETF community to describe packets with invalid source addresses. It is not an acronym. Later operational documents use it as a formal term without expanding it, because there is nothing to expand.
A martian source log line means the Linux kernel received a packet on an interface where its source address is not routable via that interface's routing table. It does not necessarily mean the source was a reserved address. A legitimate public IP can be logged as a martian if the kernel's view of the routing topology says the packet should have arrived somewhere else.
A BGP bogon is a prefix announcement for a range that should never appear in the global BGP table, including unallocated IANA space, fullbogons, and reserved RFC 1918 ranges. A martian route is the narrower case, limited to reserved ranges. Operators filter both with bogon prefix lists or a Team Cymru BGP feed, which is a separate control from RPKI Route Origin Validation.
Yes. 100.64.0.0/10 is the shared carrier-grade NAT range defined by RFC 6598. It is not globally routable, so any packet with a 100.64.0.0/10 source on the public Internet is a bogon. It is also a martian address because the range is reserved by RFC, even though individual carriers use it internally for subscriber-facing NAT.
Traditional bogons are martian addresses plus IANA-unallocated space. Fullbogons add a third category: prefixes that IANA has already delegated to an RIR but that the RIR has not yet assigned to an ISP. Fullbogons move faster than traditional bogons and require a dynamic feed like Team Cymru's to stay current.
What to do next
Check your edge router or firewall for an existing bogon filter and confirm it matches the current RFC 6890 set. Enable log_martians on any Linux host you care about and read the first hour of output. Confirm your IP intelligence provider returns a distinct response for reserved and unallocated ranges rather than a default record. Those three steps catch the overwhelming majority of issues this topic touches.
