August 17, 2026

Bogon prefixes and why your filter is old

Bogon prefixes are addresses that should not be on the public internet: reserved, documentation, default-free space that IANA has not handed out, or ranges your policy treats as martians. Filtering them is hygiene. Freezing the list in 2011 is how you blackhole a real /8 that got allocated while you were not looking.

I do not keep a handwritten bogon ACL as the source of truth. I keep a feed I can explain, and I check surprises in a BGP prefix lookup and the WHOIS lookup. If IANA says it is allocated and my filter says bogon, my filter is wrong. Team Cymru still maintains a list people actually update; IANA’s registries are the court.

Bogon prefixes I always drop

RFC 1918 on the public edge. 127/8, 169.254/16, 224/4 on unicast sessions. 0/8. Documentation nets (TEST-NET, 2001:db8::/32). 100.64/10 on the public side. IPv6 reserved ranges that have not been released. I will not drop a unicast range just because it was unallocated in a textbook from my first job.

A static bogon list is a time capsule. Time capsules do not belong in the forwarding path.

How I verify before I add a drop

Is it reserved forever, or unallocated this quarter? Does RIS already show a real origin? Does the IRR lookup have a route object that is not a joke? If a customer asks me to accept a “bogon” they just received from a RIR, I believe the RIR, not the ACL comment.

Update the list on a calendar, not after an outage. Document the source. Then go look at your IPv6 filter, which is where the stale entries like to hide.