PROTOCOLS-FUN . PACKET ANATOMY

Extension Headers Anatomy

RFC 8200 §4
rev 2026.08
generic shape NH + HdrExtLen
fragment fixed 8 bytes
order mandated, RFC 8200
see also ipv6-anatomy.html

IPv6 moved everything optional out of the fixed header into a chain of extension headers, each pointed to by the previous header's Next Header field. Every one of them shares a generic Next Header + Hdr Ext Len + data shape - except Fragment, the one fixed-size exception. Manipulating this chain (reordering, splitting across fragments, repeating a type) is the main class of IPv6-specific firewall/IDS evasion. Hover a field to light its bytes, click a field marked + for its lookup table.

shapeNext Header(8) + Hdr Ext Len(8) + dataspecRFC 8200 §4

When more than one extension header is present, RFC 8200 mandates this order - a stateless filter that assumes the upper-layer protocol is always right after the fixed IPv6 header can be walked straight past it.

mandated chain order
IPv6 header -> Hop-by-Hop Options (Next Header 0) -> Destination Options (Next Header 60, for intermediate routing) -> Routing (Next Header 43) -> Fragment (Next Header 44) -> Authentication (AH) (Next Header 51) -> Encapsulating Security (Next Header 50) -> Destination Options (Next Header 60, for the final destination) -> Upper-layer (TCP/UDP/ICMPv6)
the generic 2-byte prefix

Shared by every extension header except Fragment. Hdr Ext Len is in 8-octet units, not counting the first 8 octets - so a value of 0 means "this whole header is 8 bytes."

ESP breaks the pattern. Encapsulating Security Payload puts its own Next Header field at the end of the header, after the payload and padding - not the beginning. Any code that walks this chain generically by reading Next Header first has to special-case it.
next header0processed byevery router on the pathsize8 bytes

The one extension header every router must inspect - every other extension header is only processed by the final destination. Must come first in the chain if present.

Hop-by-Hop Options, carrying Router Alert (8 bytes)

Router Alert (RFC 2711) tells routers "inspect this packet's contents even though you're just forwarding it" - exactly how MLD reports get routers to notice group-membership changes without every router running full multicast routing.

next header43type 0deprecated, RFC 5095size24 bytes (1 hop)

Source routing - lists intermediate hops a packet should visit. Type 0 (shown here) let a packet be routed through an arbitrary sequence of addresses; in 2007 Philippe Biondi and Arnaud Ebalard showed it could bounce a packet repeatedly between colluding routers for a large amplification factor. Deprecated within the year.

Routing header, Type 0, one intermediate hop (24 bytes)

Historical structure, shown for what it was: Segments Left counts down as each listed address is visited.

the modern successor. Type 4, the Segment Routing Header (SRv6, RFC 8754), replaces RH0's arbitrary addressing with tightly-scoped, operator-controlled segment lists - used in real traffic-engineering deployments today.
next header44sizefixed 8 bytes, no Hdr Ext Lenoffset unit8 bytes

The odd one out - always exactly 8 bytes, no Hdr Ext Len field at all. Drawn bit by bit here since Fragment Offset, Reserved, and M pack into one 16-bit field. Two fragments lying about their offsets is the classic firewall-evasion trick this header enables.

Fragment header - the last fragment of a 2-fragment message (8 bytes / 64 bits)

Byte offset 8, M=0 (no more fragments follow), Identification 0x1337 ties it to its sibling fragment.

next header60processed byfinal destination onlysize8 bytes

Same TLV option encoding as Hop-by-Hop, but only the final destination ever looks inside it - intermediate routers skip straight past using Hdr Ext Len. Can appear twice in one chain: once for options meant for intermediate routing-header hops, once for the true final destination.

Destination Options, padding to the 8-byte boundary (8 bytes)

A writer with nothing to say still has to pad to a multiple of 8 bytes - PadN is how.

same TLV shape, twice. Hop-by-Hop and Destination Options share identical option encoding (Option Type, Opt Data Len, Opt Data) - the only difference is who's allowed to act on what's inside. The top 2 bits of Option Type tell an unrecognizing node what to do: skip it, discard the packet, or discard and send back an ICMPv6 Parameter Problem.