What Is Bogon Filtering? Martians, BCP38, and uRPF

A bogon is an IP address that should never appear as the source of a packet traversing the public internet. The word comes from "bogus" — these are addresses that are either unallocated by IANA, reserved for private use, or otherwise definitionally impossible to originate from a legitimate internet host. Filtering bogons at network edges is one of the oldest and most straightforward defenses in network operations, yet spoofed traffic from bogon space still causes measurable harm in 2026.

The Two Categories: Martians and Full Bogons

Martians are the permanently reserved ranges that can never be legitimate on the public internet by definition. They are codified in multiple RFCs and have not changed in decades:

The three RFC 1918 blocks (10/8, 172.16/12, 192.168/16) account for the vast majority of real-world bogon traffic because they are actively used inside enterprise and home networks and routinely leak onto the internet through misconfigured NAT, VPNs, or route redistribution.

Full bogons extend the martian list to include all IP space that IANA has not yet allocated to any regional registry (RIR). This set changes as IANA makes new allocations — when APNIC received the last of the IPv4 unicast free pool in 2011, the full bogon list effectively converged with the martian list for IPv4, though small pockets of reserved and unallocated space remained. Tracking full bogons requires a live feed rather than a static ACL.

Why Bogon Traffic Appears on the Internet

There are three distinct causes, each requiring a different response:

Misconfiguration is the most common cause. A router redistributes internal OSPF routes (which include RFC 1918 prefixes) into BGP. A VPN concentrator accepts a split-tunnel configuration and forwards private-addressed packets toward a public-facing interface. A network engineer misconfigures a default route and sends all unmatched traffic toward an upstream transit provider. These scenarios produce genuine bogon source addresses that the operator did not intend to expose.

Spoofed source addresses are the security-critical case. IP source address spoofing allows attackers to forge the source IP in UDP and ICMP packets (TCP spoofing is harder because the three-way handshake reveals the real source, but SYN floods use it). Attackers use RFC 1918 and other bogon sources because they are unroutable — the victim's replies go nowhere, the amplification traffic saturates targets without the attacker exposing their real address. DDoS amplification attacks via DNS, NTP, and memcached rely on spoofed sources.

BGP hijacks and leaks can cause bogon prefixes to become routable. If a network announces 10.0.0.0/8 into the DFZ — which has happened — some routers without proper NLRI validation will install it. See the BGP hijacking article for how this unfolds. RPKI does not protect against martian announcements (no ROA will ever be issued for RFC 1918), but it does prevent hijacks of legitimate address space.

Bogon Feeds: Team Cymru and Others

Maintaining a static ACL for bogons is error-prone and falls out of date when IANA makes allocations. Team Cymru operates the most widely used bogon feeds, updated within hours of IANA changes. They offer two delivery mechanisms:

BGP peering feed: Cymru announces the current bogon prefixes via BGP. Operators peer with Cymru's route servers and receive a full bogon routing table. Traffic matching those prefixes can be null-routed (blackholed) at the edge. This approach works at line rate on hardware routers and automatically tracks allocations.

DNS-based feed (Bogon Reference via DNS): A DNS lookup against bogon.cymru.com zone allows operators to query whether a specific IP is a bogon. This is useful for scripted validation and monitoring pipelines, though not suitable for forwarding-plane enforcement at high rates.

Other sources include the Merit Network RADB, Spamhaus's BGP feeds (focused on malicious space rather than unallocated space), and many IXPs that distribute bogon communities to their members.

uRPF: Unicast Reverse Path Forwarding

Access control lists drop bogon-addressed packets after the fact. Unicast Reverse Path Forwarding (uRPF, RFC 3704) takes a different approach: for each arriving packet, the router looks up the source address in its FIB. If the route for that source does not point back out the interface the packet arrived on (strict mode) or does not exist at all (loose mode), the packet is dropped.

Strict mode requires that the best route for the source address point back out the interface the packet arrived on. This is the strongest filter, but it breaks on multi-homed customer connections where asymmetric routing is intentional — traffic arrives on one link but routes back via another. Strict mode is appropriate on single-homed customer-facing interfaces.

Loose mode only requires that the source address be reachable somewhere in the routing table. It will not catch asymmetric routing, but it drops packets with completely unroutable sources — RFC 1918 addresses, loopback, and other martians — since no route for those prefixes exists in a correctly configured internet router. Loose mode is more widely deployable on transit interfaces.

A practical deployment: apply strict uRPF on every customer-facing access interface. Apply loose uRPF on transit and peer interfaces. Apply explicit ACL bogon filtering as a belt-and-suspenders layer on customer interfaces. Many operators apply all three.

BCP38 and RFC 2827: Ingress Filtering

BCP38, published as RFC 2827 in 2000, formalizes the ingress filtering approach: ISPs should filter packets arriving from customer networks to ensure the source addresses are within the customer's assigned address space. If a customer is assigned 192.0.2.0/24, the ISP's router should drop any packet from that customer with a source outside 192.0.2.0/24.

This is conceptually simple, universally agreed upon, and 26 years later still not universally deployed. The MANRS (Mutually Agreed Norms for Routing Security) initiative tracks deployment. As of 2025, roughly 30–40% of networks on the internet apply some form of ingress filtering — meaning the majority do not. This is why spoofed-source DDoS attacks remain effective: the packets can still be launched from the large fraction of networks that do not filter.

The incentive problem is structural: the network that deploys BCP38 bears the operational cost, while the benefit accrues to the rest of the internet (the attacker's packets never reach victims). This is a classic network externality. MANRS attempts to shift this through peer pressure, peering policy, and public accountability. Some large IXPs now require BCP38 compliance as a condition of membership.

Filtering at the Edge vs the DFZ

The Default-Free Zone (DFZ) is the set of routers that carry a full internet routing table. DFZ routers exchange routes with many peers and handle complex transit relationships; applying strict bogon ACLs at DFZ peering interfaces is operationally difficult because it requires constant maintenance as the bogon list changes. Most DFZ-level filtering relies on BGP-level mechanisms: rejecting announcements of bogon prefixes via prefix-list or route-map, and not propagating them. RPKI Route Origin Validation provides cryptographic assurance for legitimate prefixes but does not address martians (no ROA exists for RFC 1918).

The most effective bogon filtering happens at the network edge: the interface where a customer or end-user connects to an ISP. This is where BCP38 is applied and where uRPF is most effective. At the edge, the operator knows exactly which address space the customer legitimately owns, making strict filtering practical.

For IPv6, the same principles apply with different specifics. The ::1/128 loopback, fc00::/7 unique local addresses (RFC 4193, the IPv6 equivalent of RFC 1918), fe80::/10 link-local addresses, and ::/128 unspecified address are all bogons on the public internet. IPv6's vast address space means the "full bogon" category for IPv6 includes enormous unallocated regions — the current BGP table carries routes for a small fraction of the 2001::/32 through 2c00::/12 ranges actually allocated to RIRs.

Bogon Filtering in Practice: Router Configuration

On a Cisco IOS edge router facing a single-homed customer, a minimal bogon ACL applied inbound looks something like:

ip access-list extended BOGON-IN
 deny ip 0.0.0.0 0.255.255.255 any
 deny ip 10.0.0.0 0.255.255.255 any
 deny ip 100.64.0.0 0.63.255.255 any
 deny ip 127.0.0.0 0.255.255.255 any
 deny ip 169.254.0.0 0.0.255.255 any
 deny ip 172.16.0.0 0.15.255.255 any
 deny ip 192.0.2.0 0.0.0.255 any
 deny ip 192.168.0.0 0.0.255.255 any
 deny ip 198.18.0.0 0.1.255.255 any
 deny ip 198.51.100.0 0.0.0.255 any
 deny ip 203.0.113.0 0.0.0.255 any
 deny ip 224.0.0.0 15.255.255.255 any
 deny ip 240.0.0.0 15.255.255.255 any
 permit ip any any

Additionally the router should deny the customer's own prefix as a source if the customer's block does not match — this is the BCP38 enforcement: permit the customer's assigned range as source, deny everything else. The permit-any-any at the end exists because this ACL is applied inbound on the customer interface, and outbound traffic from the router toward the customer does not carry spoofed sources from that customer.

On Juniper, prefix-list-based filter terms accomplish the same goal. For transit interfaces, operators often use the Team Cymru BGP feed to null-route bogon prefixes (destination-based, not source-based) rather than ACLs — the BGP route approach scales to high-speed interfaces where ACL lookups would affect forwarding performance.

A subtlety worth noting: bogon filtering for destination prefixes (blocking packets whose destination is a bogon) is separate from filtering for source prefixes (the BCP38 anti-spoofing goal). Destination bogon filtering prevents operators from accidentally forwarding traffic into black holes or sending DNS queries to unallocated space. Both forms of filtering are useful and address different threats. Many operators apply both with separate ACLs or route policies, clearly labeled to distinguish purpose.

Maintaining Currency: Why Static Lists Fail

A static bogon ACL maintained by hand will become incorrect over time. IANA makes allocations to RIRs (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), and RIRs allocate to organizations. Space that was "unallocated" (full bogon) becomes legitimately routed. A router with a static ACL blocking that space will break connectivity to newly allocated addresses — a scenario called a false positive in bogon filtering. This has happened to real networks; the consequences range from loss of access to new CDN infrastructure to routing failures affecting customer traffic.

The Team Cymru BGP feed solves this by pushing updates as allocations happen. The DNS-based feed allows per-IP validation in scripts. Alternatively, the IANA Special-Purpose Address Registry and the five RIR's allocation histories are machine-readable and can be used to generate current ACLs programmatically. Tools like bgpq4 can generate prefix-lists from IRR data, and some vendors support automatic ACL generation from RPKI or IANA data sources. For any operator running BGP infrastructure, treating bogon filtering as a live operational process rather than a one-time configuration task is the correct model.

Explore It Live

You can see the effects of bogon filtering directly in the BGP table — prefixes covering martian space simply do not exist in the DFZ because well-configured routers reject them at ingress. Look up any network to see whether their routing practices align with BCP38 norms:

• AS3356 (Lumen/Level3) — a major transit network whose filtering policies propagate to thousands of downstream networks
• AS174 (Cogent) — another large transit provider, explore its prefix advertisements
• 1.1.1.1 — Cloudflare's resolver, reachable via a network with strict ingress filtering