Most RFCs specify a protocol. RFC 6274 does something rarer and, in some ways, more useful: it audits one. Fernando Gont's 76-page monograph is a field manual of every known way IPv4 can be abused — a security assessment written thirty years after RFC 791 shipped, cataloging the accumulated wisdom (and scar tissue) of engineers who had to defend the protocol in production. If RFC 791 tells you how IPv4 works, RFC 6274 tells you how it breaks.

The problem it solves. IPv4 was designed in 1981 for a cooperative research network. Every field — TTL, Identification, Fragment Offset, Options, source address — was specified for correctness, not adversarial resilience. By the 2000s, each of those fields had spawned attack classes: fragmentation-based firewall evasion, idle scans using predictable IP IDs, source routing to bypass ingress filters, and dozens more. This knowledge was scattered across CERT advisories, Phrack articles, and vendor errata. RFC 6274 collects it in one place and, crucially, makes normative recommendations for implementers.

The greatest hits. A few examples that show the flavor:

• The Identification field (16 bits) was meant to disambiguate fragments. Antirez discovered in 1998 that if a host uses a globally incrementing counter, an attacker can measure its traffic volume remotely — the basis of the nmap -sI idle scan. RFC 6274 recommends per-destination counters or randomization.
• Source routing (LSRR/SSRR options) lets the sender dictate the path. Beautiful for debugging in 1981; catastrophic in 2011 because it bypasses reverse-path filtering and can be used to reach RFC 1918 hosts through a compromised gateway. The RFC recommends dropping these packets by default.
• The Record Route and Timestamp options leak internal topology. The Router Alert option forces slow-path processing on every router in transit — a low-effort DoS. The Stream ID option is obsolete but still parsed.
• Fragmentation is a chapter unto itself: overlapping fragments (the Ptacek/Newsham 1998 IDS-evasion paper), tiny fragments that split the TCP header across packets, and the reassembly buffer exhaustion attack. RFC 6274 endorses dropping overlapping fragments outright rather than trying to reconcile them.
• Predictable ISN and IP ID generation — Mitnick's 1994 attack on Shimomura's workstation exploited exactly this. The RFC points to RFC 6528's PRNG-based scheme.

Why it's structured the way it is. Gont walks the IPv4 header field-by-field, then covers options, then fragmentation, then addressing. For each, he describes the specified behavior, the known attacks, and concrete mitigations — often with a note about which BSD/Linux/Windows versions did what. It reads less like a standard and more like a code review of the entire IP stack.

Why it matters today. Three reasons. First, IPv4 isn't going away — it still carries the majority of internet traffic in 2026, and every hardening recommendation here applies to hardware you buy tomorrow. Second, RFC 6274 established a template: Gont went on to write parallel assessments of TCP (RFC 6528), ICMP (RFC 5927), and IPv6 (RFC 7123), and the IETF opsec working group now treats "security assessment" as a first-class document type. Third, and most subtly, it's a reminder that protocols are never finished. RFC 791 was declared a Standard in 1981; RFC 6274 is thirty years of errata that never made it into the spec itself. If you're designing a protocol today, budget for the sequel.

Backstory. Gont wrote much of this material while consulting for the UK's CPNI (Centre for the Protection of National Infrastructure), which had commissioned a series of protocol security reviews. The IETF opsec WG picked it up and shepherded it to Informational status — not a standard, but an authoritative reference. It's one of the few RFCs cited routinely by both attackers and defenders.