Loading learning content...
In our previous examination of IPv6 extension headers, we established a fundamental principle: extension headers are processed only by the destination, not by intermediate routers. This architectural decision enables high-speed router forwarding by keeping optional processing out of the critical path.
But there's one critical exception: the Hop-by-Hop Options header.
This extension header breaks the rule deliberately. Some functionality simply cannot wait until the destination—it must be examined and acted upon by every router along the path. Flow control signals, resource reservation, jumbo packet handling, and router alerts all require in-path processing.
The Hop-by-Hop Options header exists precisely to carry this class of time-critical, path-sensitive information. Its design, placement, and encoding reflect the unique demands of per-hop processing.
By the end of this page, you will understand: (1) Why certain options require hop-by-hop processing, (2) The precise binary structure of the Hop-by-Hop Options header, (3) The TLV encoding scheme for individual options, (4) All major option types including Pad1, PadN, Router Alert, Jumbo Payload, and CALIPSO, (5) The processing algorithm routers must implement, and (6) Performance and security implications of hop-by-hop processing.
Not all network functionality can be deferred to the destination. Some operations are inherently path-dependent—they require action from intermediate nodes as packets traverse the network. Understanding these use cases clarifies why the Hop-by-Hop Options header exists.
Categories of Hop-by-Hop Functionality:
| Category | Example Option | Why Hop-by-Hop? | Consequence if Ignored |
|---|---|---|---|
| Oversized Packets | Jumbo Payload | Routers must know actual packet length to allocate buffers and forward correctly | Packet truncation, forwarding failure |
| Resource Signaling | Router Alert | Routers must intercept packets for local protocol processing (RSVP, MLD) | QoS reservations fail, multicast groups break |
| Security Classification | CALIPSO | Each router must verify security label authorization for its network segment | Classified data may leak to unauthorized networks |
| Congestion Feedback | Quick-Start | Each router must approve or modify requested rate | Congestion collapse, unfair bandwidth allocation |
The Jumbo Payload Case Study:
The IPv6 main header's Payload Length field is 16 bits, limiting standard payload to 65,535 bytes. But some high-performance networks (supercomputer interconnects, data center fabrics) can benefit from much larger packets—reducing per-packet overhead for bulk transfers.
The Jumbo Payload option enables packets up to 4,294,967,295 bytes (2³² - 1). But here's the critical insight: every router on the path must know the true packet length, not just the destination. Routers need this to:
If the Jumbo Payload option were in a Destination Options header (processed only at the destination), routers would see Payload Length = 0 and have no idea how large the packet actually is. They'd allocate minimal buffers, try to forward a truncated packet, and cause catastrophic failures.
This is why Hop-by-Hop exists: some information is path-essential, not just destination-relevant.
Router Alert is particularly elegant: rather than forcing routers to deeply inspect every packet looking for RSVP or MLD messages, the sender simply sets the Router Alert option. Routers check one field to determine if the packet needs local protocol processing, avoiding expensive deep packet inspection in the fast path.
The Hop-by-Hop Options header follows the standard extension header format but carries Type-Length-Value (TLV) encoded options. Its structure is optimized for efficient sequential parsing.
Binary Format:
Hop-by-Hop Options Header Structure════════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header | Hdr Ext Len | |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| |. .. Options .. .| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ┌─────────────────────────────────────────────────────────────────────────┐│ FIELD DEFINITIONS │├─────────────────────────────────────────────────────────────────────────┤│ ││ Next Header (8 bits) ││ Identifies the type of header immediately following the Hop-by-Hop ││ Options header. Uses the same values as the IPv6 Next Header field. ││ Common values: ││ - 6 = TCP ││ - 17 = UDP ││ - 43 = Routing Header ││ - 58 = ICMPv6 ││ - 60 = Destination Options ││ ││ Hdr Ext Len (8 bits) ││ Length of the Hop-by-Hop Options header in 8-octet units, ││ NOT including the first 8 octets. ││ ││ Total Header Length = (Hdr Ext Len + 1) × 8 bytes ││ ││ Examples: ││ - Hdr Ext Len = 0 → Total length = 8 bytes (minimum) ││ - Hdr Ext Len = 1 → Total length = 16 bytes ││ - Hdr Ext Len = 2 → Total length = 24 bytes ││ - Hdr Ext Len = 255 → Total length = 2048 bytes (maximum) ││ ││ Options (variable) ││ One or more TLV-encoded options, padded to 8-octet boundary. ││ Options are parsed sequentially from start to end. ││ The header MUST be padded to a multiple of 8 octets. ││ │└─────────────────────────────────────────────────────────────────────────┘ Example: Minimum Hop-by-Hop Header (8 bytes, just padding)═══════════════════════════════════════════════════════════════════════════ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 6 | 0 | 1 | 4 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 0 | 0 | 0 | 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Decoded:- Next Header: 6 (TCP follows)- Hdr Ext Len: 0 (total length = 8 bytes)- Options: PadN with length 4, then 4 bytes of zero paddingThe Hop-by-Hop Options header MUST appear immediately after the IPv6 header—never in any other position. The IPv6 header's Next Header field must be 0 to indicate Hop-by-Hop follows. This positioning enables the critical optimization: routers check one field (Next Header in IPv6 header) to determine if any hop-by-hop processing is needed.
Options within the Hop-by-Hop Options header use Type-Length-Value (TLV) encoding. This flexible format allows multiple options of varying sizes to be packed into a single header while maintaining backward compatibility as new options are defined.
Standard TLV Format:
Standard TLV Option Format═══════════════════════════════════════════════════════════════════════════ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+| Option Type | Opt Data Len | Option Data (variable) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+|<--- 8 bits -->|<--- 8 bits -->|<---- Opt Data Len bytes ----->| Option Type Field Encoding (8 bits)═══════════════════════════════════════════════════════════════════════════ The Option Type byte contains encoded processing directives: 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | act |chg| Option Number | +---+---+---+---+---+---+---+---+ act (bits 0-1): Action if option type is unrecognized═══════════════════════════════════════════════════════════════════════════ 00 = Skip over this option and continue processing 01 = Discard the packet silently 10 = Discard and send ICMP Parameter Problem (all destinations) 11 = Discard and send ICMP Parameter Problem (only if not multicast) chg (bit 2): Change flag═══════════════════════════════════════════════════════════════════════════ 0 = Option data does NOT change en route 1 = Option data MAY change en route (critical for authentication: changed options cannot be authenticated) Option Number (bits 3-7): The specific option type within this class Decoding Examples:═══════════════════════════════════════════════════════════════════════════ Option Type = 0x00 (binary: 00 0 00000) = Pad1 - act=00: skip if unknown - chg=0: does not change - number=0: padding option 1 Option Type = 0x01 (binary: 00 0 00001) = PadN - act=00: skip if unknown - chg=0: does not change - number=1: padding option N Option Type = 0x05 (binary: 00 0 00101) = Router Alert - act=00: skip if unknown (but routers SHOULD recognize this) - chg=0: does not change - number=5: router alert Option Type = 0xC2 (binary: 11 0 00010) = Jumbo Payload - act=11: discard + ICMP if unknown (unless multicast) - chg=0: does not change - number=2: jumbo payloadThe Action Bits Rationale:
The two-bit action field enables graduated responses to unrecognized options:
The 'chg' bit is critical for IPsec Authentication Header (AH) operation. AH computes an integrity check over the entire packet, including extension headers. But if an option value may legitimately change en route (like Hop Count in an experimental option), AH must exclude it from the integrity computation. Options with chg=1 are zeroed before AH computation and restored after verification.
Every Hop-by-Hop Options header must be a multiple of 8 bytes. Additionally, many options require specific alignment within the header for efficient processing. Two special padding options enable this alignment: Pad1 and PadN.
Pad1 Option (Type = 0):
Pad1 is unique—it has NO length or value fields. The entire option is a single zero byte:
Pad1 Option Format═══════════════════════════════════════════════════════════════════════════ +-+-+-+-+-+-+-+-+| 0 | ← Entire option is just this one byte+-+-+-+-+-+-+-+-+ Used to insert 1 byte of padding. The absence of length/value fields is intentional:- If Type=0 always used standard TLV, minimum would be 2 bytes (type + length)- Pad1 saves one byte per single-byte alignment need- Parser recognizes Type=0, consumes exactly 1 byte, continuesPadN Option (Type = 1):
PadN uses the standard TLV format to insert N bytes of padding (where N ≥ 2):
PadN Option Format═══════════════════════════════════════════════════════════════════════════ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+| 1 | Opt Data Len | Zero Padding |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+ Opt Data Len contains (N-2) where N is total bytes of padding desired. Examples:═══════════════════════════════════════════════════════════════════════════ 2 bytes of padding:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 1 | 0 | ← PadN with data length 0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 bytes of padding:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 1 | 2 | 0 | 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 bytes of padding:+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 1 | 4 | 0 | 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 0 | 0 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Options specify alignment requirements as xn+y, meaning the option must start at a byte offset that equals y when divided by x. For example, the Jumbo Payload option (4n+2) must start at byte 2, 6, 10, etc. within the options area. Padding options fill gaps to achieve these alignments.
The Router Alert option signals to intermediate routers that the packet requires local processing beyond simple forwarding. This enables protocols like RSVP (Resource Reservation), MLD (Multicast Listener Discovery), and specific ICMP operations without requiring routers to deeply inspect every packet.
Option Format:
Router Alert Option Format═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 0x05 | 0x02 | Router Alert Value |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields:═══════════════════════════════════════════════════════════════════════════Option Type: 0x05 (binary: 00 0 00101) - Action: 00 = skip if unknown - Change: 0 = does not change en route - Number: 5 = Router Alert Option Length: 0x02 (2 bytes of option data) Router Alert Value (16 bits): 0 = Datagram contains MLD message (Multicast Listener Discovery) 1 = Datagram contains RSVP message (Resource Reservation) 2 = Datagram contains an Active Network message 3 = Aggregated RSVP reservation 4 = QoS NSLP Aggregation-level 0 5-34 = QoS NSLP Aggregation levels 1-30 35 = NSIS NATFW NSLP 65535 = Reserved for future expansion (Complete registry maintained by IANA)Processing Algorithm:
When a router encounters a packet with the Router Alert option:
Multicast Listener Discovery (MLD) messages—the IPv6 equivalent of IGMP—always include the Router Alert option. This ensures that MLD packets are processed by multicast routers even if they're addressed to a multicast group address. Without Router Alert, a router might simply forward the MLD packet without updating its multicast state.
The Jumbo Payload option enables IPv6 packets larger than 65,535 bytes—the maximum expressible in the 16-bit Payload Length field. This option is essential for networks supporting "jumbograms" (extremely large packets used in high-performance computing).
When Jumbo Payload is Used:
Option Format:
Jumbo Payload Option Format═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 0xC2 | 0x04 | Jumbo Payload Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields:═══════════════════════════════════════════════════════════════════════════Option Type: 0xC2 (binary: 11 0 00010) - Action: 11 = discard + ICMP if unknown (unless multicast) - Change: 0 = does not change en route - Number: 2 = Jumbo Payload Option Length: 0x04 (4 bytes = 32-bit length value) Jumbo Payload Length (32 bits): - Length of the packet in bytes, excluding the IPv6 header (40 bytes) - Includes all extension headers, plus upper-layer data - MUST be greater than 65,535 (else standard Payload Length would work) - Maximum value: 4,294,967,295 Alignment: 4n+2 (must start at offset 2, 6, 10, etc.) Complete Hop-by-Hop Header with Jumbo Payload:═══════════════════════════════════════════════════════════════════════════ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Next Header=6 | Hdr Ext Len=0 | 0xC2 | 0x04 |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| Jumbo Payload Length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This 8-byte Hop-by-Hop header specifies a jumbogram; TCP data follows.Critical Processing Rules:
Jumbograms are rarely used on the public Internet—most paths have MTU limits well below 65,535 bytes. They're primarily found in specialized environments: supercomputer interconnects (InfiniBand bridging), high-speed research networks, and data center fabrics where end-to-end MTU can be guaranteed.
Beyond Router Alert and Jumbo Payload, several other options are defined for the Hop-by-Hop Options header. While less commonly encountered, understanding them completes the picture of hop-by-hop functionality.
CALIPSO (Common Architecture Label IPv6 Security Option):
| Field | Size | Description |
|---|---|---|
| Domain of Interpretation | 32 bits | Identifies the security policy domain |
| Compartment Length | 8 bits | Length of compartment bitmap in 32-bit words |
| Sensitivity Level | 8 bits | Hierarchical classification level |
| Compartment Bitmap | Variable | Non-hierarchical category markings |
CALIPSO is used in Multi-Level Secure (MLS) networks—environments where traffic at different classification levels (Unclassified, Secret, Top Secret) must traverse shared infrastructure while maintaining separation. Each router verifies that incoming traffic's security label is authorized for its network segment.
RPL Option (Routing Protocol for Low-Power and Lossy Networks):
The RPL Option carries routing state for constrained networks (IoT, sensor networks):
RPL Option (Type = 0x63)═══════════════════════════════════════════════════════════════════════════ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| 0x63 | Opt Data Len |O|R|F| 0 | RPLInstanceID |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| SenderRank | (sub-TLVs if O=1) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - -+ O = Down flag (packet moving toward root or away)R = Rank-Error flag (inconsistent rank detected)F = Forwarding-Error flag (forwarding problem)RPLInstanceID = Identifies the RPL routing instanceSenderRank = Rank of sending node in the RPL DAGSMF_DPD (Simplified Multicast Forwarding Duplicate Packet Detection):
This option supports multicast forwarding in networks without full multicast routing protocols:
The complete list of assigned Hop-by-Hop Option Types is maintained by IANA. New options can be registered following the procedures in RFC 2780, allowing the protocol to evolve without changing the fundamental architecture.
The Hop-by-Hop Options header's requirement for per-hop processing creates both performance and security considerations that network operators must understand.
Performance Impact:
The Middlebox Reality:
Empirical studies (notably RFC 7872) found that packets with Hop-by-Hop Options headers experience significantly higher drop rates across the Internet:
This creates a deployment challenge: legitimate uses of Hop-by-Hop Options (like MLD) may not work across all network paths.
Security Considerations:
RFC 8200 notes that routers SHOULD be configurable to ignore the Hop-by-Hop Options header in some deployments—treating packets as if the option weren't present. This acknowledges the reality that security and performance concerns sometimes outweigh protocol compliance, though it may break legitimate functionality like MLD.
We've completed an exhaustive examination of the Hop-by-Hop Options header—the singular extension header that demands per-hop processing. Let's consolidate the essential knowledge:
What's Next:
The next page examines the Routing Header—the extension header that enables source routing, segment routing, and path control. Unlike Hop-by-Hop, Routing Headers are processed only at destinations, but their impact on packet forwarding is profound.
You now possess comprehensive understanding of the Hop-by-Hop Options header—from its architectural necessity through its binary encoding to its operational implications. This knowledge is fundamental for understanding IPv6's extension header ecosystem.