What is a bogon?
A bogon is an IP prefix that should never appear in global routing: private, reserved and unallocated space. We cover martians, fullbogons and filtering.
Last updated:
A bogon is an IP prefix that should never appear in the global routing table, because it covers address space that is private, reserved or not yet allocated by IANA and the regional registries. When such a prefix shows up in a BGP announcement, it is a strong signal of misconfiguration, a route leak or abuse, for example spam delivery or an attack using a spoofed source address. For that reason operators filter bogons both at the BGP session level and in the packet forwarding path.
Bogons, martians and special-purpose addresses
These terms overlap, though they are not identical. A martian is a source or destination address that cannot be routed correctly on the public internet, such as the loopback 127.0.0.0/8, link-local 169.254.0.0/16 or multicast 224.0.0.0/4. Special-purpose addresses are catalogued in the IANA registry and in RFC 6890, which consolidates earlier documents. A bogon is the broader term. It includes the martians plus all of the address space that has not yet been formally allocated to anyone.
- RFC 1918 private space: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.
- Loopback 127.0.0.0/8 and link-local 169.254.0.0/16 (RFC 3927).
- CGNAT 100.64.0.0/10 (RFC 6598) and documentation space such as 192.0.2.0/24 (RFC 5737).
- IPv6: ULA fc00::/7 (RFC 4193), link-local fe80::/10, documentation 2001:db8::/32.
- Address space not yet allocated by IANA to a given regional registry.
Classic bogons versus fullbogons
Bogon lists fall into two categories. Classic bogons are the RFC-defined prefixes that do not change: private, reserved and documentation space. Fullbogons are a much larger set that additionally includes all address space already allocated by IANA to the regional registries but not yet handed out to end operators. Fullbogons change frequently, sometimes daily, as the RIRs assign new blocks. They should therefore never be hard-coded, but pulled dynamically instead, for example from the Team Cymru lists over BGP, DNS or HTTP.
How to filter bogons
Filtering happens on two levels. At the routing level you apply prefix lists or RPSL filters on BGP sessions to drop any announcement covering bogon space, regardless of its AS_PATH. At the packet level you use ACLs and unicast Reverse Path Forwarding (uRPF), which discards traffic with a spoofed source address, in line with the anti-spoofing guidance of BCP 38 (RFC 2827). Classic bogons can be maintained statically, but fullbogons require automation, since manual updates are not feasible. Increasingly, alongside bogon filtering, operators also deploy RPKI route origin validation, which protects against a far wider class of invalid announcements.
Bogons on the AS202520 SkyPass network
On the AS202520 SkyPass network, filtering bogons and martians is a standard part of every session. On IP transit ports and on peering sessions at the Polish internet exchanges (THINX, TPIX, WRIX, 1-IX) we reject announcements from private and reserved space, apply uRPF in line with BCP 38 and run RPKI validation. We update the fullbogon lists automatically, so newly allocated blocks are not blocked once they enter global routing. Our transit and remote IXP customers in the Warsaw and Wrocław PoPs therefore get a clean routing table, while their own prefixes are never mistaken for bogons.
Frequently asked questions
How is a bogon different from a martian?
A martian is an address that by definition cannot be routed on the public internet, such as 127.0.0.0/8 or 169.254.0.0/16. A bogon is broader and includes the martians plus all space not yet allocated by IANA and the regional registries.
Should bogon lists be hard-coded?
Classic RFC-defined bogons are stable and can be kept static. Fullbogons change frequently, so they must be pulled dynamically, for example from the Team Cymru lists, to avoid blocking newly allocated blocks.
How does bogon filtering differ from RPKI?
Bogon filtering rejects space that should never be routed at all. RPKI verifies whether a specific autonomous system is authorised to originate a given allocated prefix. The two mechanisms complement each other and are best used together.
What is BCP 38 and how does it relate to bogons?
BCP 38 (RFC 2827) is the recommendation to filter traffic with spoofed source addresses at the network edge. In practice it is implemented with uRPF and ACLs, which also block packets sourced from bogon space.