What Are Bogon IP Addresses?

Bogon IP addresses (or bogons) are IP addresses that should never appear as a source or destination in legitimate internet routing, because they fall into ranges that are unallocated by IANA, reserved for special purposes, or designated for private use under RFC 1918, RFC 5735, and RFC 6890. Traffic carrying a bogon source address is a strong signal of IP spoofing or misconfiguration, which makes bogon filtering a foundational, low-cost control in anti-spoofing and DDoS defense architectures.

TL;DR: Bogons are IP address ranges that have no legitimate reason to appear on the public internet: unallocated space, reserved blocks, private-use ranges, documentation ranges, multicast, and other special-purpose allocations defined by IANA and codified in RFCs including 1918, 5735, and 6890. Because these ranges cannot represent real internet hosts, any packet arriving from or destined to a bogon address is almost certainly the product of spoofing, misrouting, or misconfiguration. Networks filter bogons at the BGP and firewall ACL level using maintained lists such as Team Cymru’s, reducing the attack surface available to spoofed-source DDoS traffic and complementing source-validation controls like BCP38 and uRPF.

Last updated: 2026-08-27

How Bogon Filtering Works

What makes an address a bogon

The IANA IPv4 Special-Purpose Address Registry and its IPv6 counterpart formally track every reserved, private, or otherwise special-purpose block. A bogon is any address within a block that:

1. Has not been allocated by IANA to a Regional Internet Registry (unallocated/“dark” space), or
2. Has been reserved for a specific non-routable purpose (private use, documentation, loopback, link-local, multicast, or future use).

Because these ranges are either not assigned to any organization or explicitly reserved for non-internet-routable purposes, a packet with a bogon source address cannot represent a real, reachable internet host — it is either spoofed, misconfigured, or leaking from an internal network.

Example bogon categories and ranges:

0.0.0.0/8          "This" network — reserved (RFC 791 / RFC 1122)
10.0.0.0/8         Private-use (RFC 1918)
100.64.0.0/10      Shared address space, carrier-grade NAT (RFC 6598)
127.0.0.0/8        Loopback (RFC 1122)
169.254.0.0/16     Link-local (RFC 3927)
172.16.0.0/12      Private-use (RFC 1918)
192.0.0.0/24       IETF Protocol Assignments (RFC 6890)
192.0.2.0/24       Documentation — TEST-NET-1 (RFC 5737)
192.168.0.0/16     Private-use (RFC 1918)
198.18.0.0/15      Benchmarking (RFC 2544)
198.51.100.0/24    Documentation — TEST-NET-2 (RFC 5737)
203.0.113.0/24     Documentation — TEST-NET-3 (RFC 5737)
224.0.0.0/4        Multicast (RFC 5771)
240.0.0.0/4        Reserved for future use (RFC 1112 / RFC 6890)

Why bogon traffic indicates spoofing or misconfiguration

Legitimate internet traffic should never carry a source address from a private-use, reserved, documentation, or unallocated range, because no real host on the public internet is assigned one of those addresses. When a bogon address appears:

Bogon-sourced packet arriving from the public internet:

Internet ──packet, src=192.0.2.55 (TEST-NET-1, documentation-only)──▶ Your network

This cannot be a real return path. Two explanations:
1. Spoofing — an attacker fabricated a source address from a bogon range
   deliberately, often as part of a DDoS or reflection/amplification setup
2. Misconfiguration — a misconfigured device, NAT boundary, or lab/test
   environment is leaking non-routable addresses onto the public internet

Bogon-destined traffic — packets sent toward a bogon address from inside your network — usually indicates misconfigured routing, stale static routes, or compromised hosts attempting to reach non-routable or unallocated space, sometimes as part of malware behavior probing for internal services.

Bogon Range Categories

Bogons vs. Fullbogons

Classic “bogon” lists cover space that IANA has never allocated to any Regional Internet Registry plus the reserved special-purpose ranges above. “Fullbogon” lists extend this to include IANA-allocated space that has not yet been assigned by a Regional Internet Registry to an actual network operator — space that is technically allocated at the top level but not yet legitimately routable anywhere. Because IANA allocations change over time, fullbogon lists require more frequent updates than the largely static reserved-range list.

Detection Signals and Telemetry

# Check whether a route or prefix matches known bogon space (example using a
# local bogon prefix list loaded into a route filter)
grep -F "192.0.2." /etc/bogon-bn-agg.txt

# BGP route filtering — reject announcements for bogon prefixes (Cisco-style ACL example)
ip prefix-list BOGONS seq 5 deny 0.0.0.0/8 le 32
ip prefix-list BOGONS seq 10 deny 10.0.0.0/8 le 32
ip prefix-list BOGONS seq 15 deny 127.0.0.0/8 le 32

# iptables — drop inbound packets with bogon source addresses at the firewall
iptables -A INPUT -s 10.0.0.0/8 -i eth0 -j DROP
iptables -A INPUT -s 192.0.2.0/24 -i eth0 -j DROP
iptables -A INPUT -s 240.0.0.0/4 -i eth0 -j DROP

# Flow analysis — correlate bogon-sourced traffic with potential spoofing
# using NetFlow/sFlow tools filtered against a maintained bogon list

Mitigation and Implementation

Maintaining and subscribing to bogon lists

Two authoritative sources anchor most bogon filtering programs:

• Team Cymru’s bogon reference provides regularly updated bogon and fullbogon lists in multiple consumable formats, including static text lists and a BGP feed that networks can peer with to receive live updates.
• IANA IPv4 Special-Purpose Address Registry (and its IPv6 equivalent) is the authoritative registry of record for every reserved and special-purpose block, and is the source that projects like Team Cymru’s list derive from.

Automating bogon ACL updates

Because IANA periodically allocates previously-unallocated space to Regional Internet Registries, static bogon lists age and can become inaccurate — a block that was a bogon last year may be legitimately routed today. Automating updates is essential:

Bogon filtering as an anti-spoofing layer

Bogon filtering addresses a narrower but complementary problem to source-address validation controls:

• BCP38 / RFC 2827 requires networks to filter outbound traffic so that packets leaving a customer network carry only source addresses legitimately assigned to that network — this stops spoofing at the origin network.
• uRPF (Unicast Reverse Path Forwarding), per RFC 3704, checks that inbound traffic’s source address has a valid return route through the receiving interface — this stops some spoofing at transit and peering points.
• Bogon filtering rejects traffic with source or destination addresses that could never be legitimate anywhere on the internet, regardless of return-route topology — this stops the specific, common case of obviously-fabricated addresses, including many used in reflection and amplification setups.

None of these three controls alone is sufficient. BCP38 depends on adoption by the originating network, which remains uneven globally; uRPF strict mode can break legitimate asymmetric routing; bogon filtering only catches addresses in known non-routable ranges and does nothing against spoofing that uses a legitimately-allocated but unrelated real IP address. Layering all three closes more of the spoofing surface than any single control.

Common Mistakes

How to Implement on Azion

Bogon filtering is one layer within a broader anti-spoofing and DDoS defense posture. Azion applies network-layer filtering at distributed points of presence before traffic reaches origin infrastructure:

• Network Shield supports programmable network-layer rules using IP, CIDR, and ASN-based lists, which can be configured to reflect bogon and known-bad-source filtering policy.
• DDoS Protection provides always-on detection and mitigation for spoofed-source and reflection-style traffic patterns at the edge.
• Firewall enables custom rules for source-address validation and blocking of known non-routable ranges.
• WAAP combines network and application-layer protections for organizations facing blended, spoofing-driven attack campaigns.

Because Azion sits at the network edge across distributed points of presence, spoofed or bogon-sourced traffic aimed at reflection or amplification techniques can be filtered before it consumes origin bandwidth or compute resources. Bogon filtering, BCP38 adoption by upstream providers, and uRPF at transit points remain complementary controls that operate outside any single vendor’s platform and should be verified as part of a complete anti-spoofing strategy.

Related Resources

• What Is a DDoS Attack?
• DDoS Attack Types
• What Is a SYN Flood Attack?
• What Is DDoS Protection and Mitigation?
• Azion DDoS Protection

Frequently Asked Questions

What are bogon IP addresses? Bogon IP addresses are ranges that should never appear in legitimate internet routing because they are unallocated by IANA or reserved for special, non-internet-routable purposes such as private networks, documentation, loopback, or future use. Any traffic carrying a bogon address as source or destination indicates spoofing or misconfiguration.

What is the difference between bogons and fullbogons? Bogons are the permanently reserved, special-purpose ranges defined by RFCs such as 1918, 5735, and 6890, plus space IANA has never allocated. Fullbogons additionally include IANA-allocated space that has not yet been assigned by a Regional Internet Registry to an operator — space that changes as new allocations happen, requiring more frequent list updates.

Are private IP ranges like 10.0.0.0/8 always bogons? Yes, when seen on the public internet. RFC 1918 private-use ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are legitimate inside private networks but should never appear as a source or destination address on public internet-facing interfaces. Their appearance there indicates a NAT misconfiguration or spoofing attempt.

Why does bogon filtering matter for DDoS defense specifically? Many DDoS techniques, especially reflection and amplification attacks, rely on spoofed source addresses, and a portion of that spoofed traffic uses bogon ranges because they are easy to fabricate and otherwise unmonitored. Filtering bogon-sourced traffic removes a meaningful slice of that spoofing surface at low operational cost.

What is Team Cymru’s bogon list? Team Cymru maintains and publishes regularly updated bogon and fullbogon lists derived from IANA’s allocation registries, available as static text feeds and as a live BGP feed that networks can peer with to receive continuous updates without manual list maintenance.

Does bogon filtering replace BCP38 or uRPF? No. Bogon filtering only catches traffic using addresses from known non-routable ranges. BCP38 (RFC 2827) filters at the source network to ensure outbound traffic uses only legitimately assigned addresses, and uRPF checks that inbound source addresses have a valid return route. An attacker spoofing a real, legitimately-allocated IP address that is not a bogon will bypass bogon filtering entirely, which is why all three controls are complementary, not substitutes for each other.

What happens if a bogon list is not updated regularly? A stale bogon list can block traffic from space that IANA has since legitimately allocated to an operator, causing false-positive drops of real traffic, or fail to filter newly-reserved ranges, leaving a filtering gap. Automated updates via a maintained feed or BGP peering session address this.

Can bogon-destined traffic from inside my network indicate a problem? Yes. Outbound traffic destined to bogon ranges usually points to stale or misconfigured static routes, or in some cases malware probing for internal or non-routable services. It is worth monitoring both directions, not just inbound bogon-sourced traffic.

Is bogon filtering effective against botnets using real, compromised-device IP addresses? No. Bogon filtering only addresses traffic using fabricated addresses from non-routable ranges. A botnet of compromised devices using their own legitimately-allocated IP addresses will not appear as bogon traffic and requires different detection approaches, such as behavioral and volumetric analysis.

Where should bogon filtering be applied in a network? Ideally at every ingress point: internet-facing edge routers via BGP prefix filtering, firewalls via ACLs, and cloud or VPC route tables where applicable. Applying it only at a single chokepoint can leave gaps at VPNs, peering connections, or cloud interconnects that bypass the primary filter.

Sources:

• IETF. “Address Allocation for Private Internets.” RFC 1918. 1996.
• IETF. “Special Use IPv4 Addresses.” RFC 5735. 2010.
• IETF. “Special-Purpose IP Address Registries.” RFC 6890. 2013.
• IETF. “IPv4 Address Blocks Reserved for Documentation.” RFC 5737. 2010.
• IETF. “IANA-Reserved IPv4 Prefix for Shared Address Space.” RFC 6598. 2012.
• IETF. “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing.” RFC 2827 (BCP 38). 2000.
• IETF. “Network Ingress Filtering: Unicast Reverse Path Forwarding.” RFC 3704 (BCP 84). 2004.
• IANA. “IPv4 Special-Purpose Address Registry.”
• Team Cymru. “The Bogon Reference.”
• CISA. “Understanding and Responding to Distributed Denial-of-Service Attacks.”