skip to content

How does the IPv6 Next Header field chain extension headers together, and in what order does RFC 8200 recommend placing them?

level: seniorimportance: should knowfreq 20%

answer

  1. each header names the next
  2. 8-octet units, first 8 not counted
  3. Hop-by-Hop must come first
  4. Destination Options may appear twice
  5. first fragment carries the whole chain

basics

~20 s

Each IPv6 header ends its job by naming the next one in its Next Header byte, until a value names the upper layer. RFC 8200 recommends Hop-by-Hop, Destination Options, Routing, Fragment, AH, ESP, Destination Options, then the upper layer.

solid answer

~40 s

The base header's `Next Header` names the first extension header, each extension header starts with its own `Next Header` byte, and the first value that is not an extension header type (6 TCP, 17 UDP, 58 ICMPv6) is the upper layer; 59 means nothing follows. Every extension header is a multiple of 8 octets. RFC 8200's recommended order is Hop-by-Hop Options, Destination Options (for each Routing hop), Routing, Fragment, AH, ESP, Destination Options (final destination only), then the upper layer. Only one rule is hard: Hop-by-Hop must sit immediately after the base header. Each header should appear at most once, Destination Options at most twice, yet receivers must accept any order. Destinations process the chain strictly in sequence, and RFC 7112 requires the first fragment to carry the entire chain.

code

pseudocode · 19 lines
pseudocode
// Find the upper-layer header of an IPv6 packet
nh  = byte(6)                 // base header's Next Header
pos = 40                      // first byte after the base header
loop:
  if nh == 0 and pos != 40:
      return ParameterProblem(code 1)    // Hop-by-Hop not first
  if nh in {0, 43, 60}:       // Hop-by-Hop, Routing, Destination Options
      next = byte(pos)
      pos  = pos + (byte(pos + 1) + 1) * 8   // Hdr Ext Len
      nh   = next
  else if nh == 44:           // Fragment header, always 8 bytes
      if fragment_offset(pos) != 0:
          return NonFirstFragment     // no upper-layer header here
      nh  = byte(pos)
      pos = pos + 8
  else if nh == 59:
      return NothingFollows
  else:
      return (nh, pos)        // 6 TCP, 17 UDP, 58 ICMPv6, or a header not parsed here, such as AH

go deeper

for a junior

Recall that IPv6 options live in extension headers after the 40-byte base header, and that each header's Next Header field names the one after it.

for a middle

Walk a chain value by value, naming 0, 43, 44 and 60, and recite the recommended order with the two places Destination Options can appear.

for a senior

Explain what the chain does to devices that need transport ports: they must walk every header, a non-first fragment has no ports at all, and RFC 7112 exists so the first fragment always does.

for a principal

Judge how much a design should lean on header ordering: receivers must accept any order, so a parser that assumes the recommended sequence is a robustness bug and a filter-evasion opening.

## How the chain works IPv6 moved IPv4's options out of the base header into **extension headers** placed between the 40-byte base header and the upper-layer header. They are linked like a list: - The base header's `Next Header` names the first header that follows. - Every extension header begins with its own 8-bit `Next Header` field naming the header after it. - The first value that is **not** an extension header type identifies the upper layer. Value 59, **No Next Header**, says nothing follows. - Each extension header is an integer multiple of **8 octets**, which keeps whatever follows 8-octet aligned. - Hop-by-Hop Options, Routing and Destination Options carry `Hdr Ext Len`: the length in 8-octet units **not counting the first 8 octets**, so a value of 0 means 8 bytes and 1 means 16. The Fragment header has no length field because it is always 8 bytes. | Next Header value | Header | |---|---| | 0 | Hop-by-Hop Options | | 43 | Routing | | 44 | Fragment | | 50 | Encapsulating Security Payload (ESP) | | 51 | Authentication Header (AH) | | 60 | Destination Options | | 59 | No Next Header | | 6 / 17 / 58 | TCP / UDP / ICMPv6 (upper layer) | ## RFC 8200's recommended order When several extension headers are present, RFC 8200 section 4.1 recommends: 1. IPv6 base header 2. **Hop-by-Hop Options** 3. **Destination Options**, for options read by the first destination and by each node listed in the Routing header 4. **Routing** 5. **Fragment** 6. **Authentication Header** 7. **Encapsulating Security Payload** 8. **Destination Options**, for options read only by the final destination 9. Upper-layer header The logic follows who must read each header. Headers that nodes on the way need come first; the Fragment header follows them because everything after it is split across fragments; AH and ESP come next so that what follows them is authenticated or encrypted; final-destination options can then sit inside ESP's protection. ## Rules versus recommendations - **Hard rule:** Hop-by-Hop Options must immediately follow the base header. A destination that meets Next Header 0 anywhere else should discard the packet and send ICMPv6 Parameter Problem with code 1. - Each extension header **should** occur at most once, except Destination Options, which should occur at most twice. - Nodes **must** accept and attempt to process extension headers in any order and any number of times, Hop-by-Hop excepted; sources are strongly advised to follow the recommended order. - If the upper layer is another IPv6 header (IPv6 in IPv6), the inner packet has its own chain under the same recommendations. ## Who reads the chain - Apart from Hop-by-Hop Options, extension headers are not processed, inserted or deleted on the path; only the node in the `Destination Address` processes them. With a Routing header, each listed node becomes the destination in turn, which is why the first Destination Options header is read at every one of them. - Hop-by-Hop Options may be examined en route. RFC 2460 required every node to process it; RFC 8200 expects nodes to do so only if configured to. - The destination must process headers **strictly in order**; it may not scan ahead for one header and act on it before the ones in front. - An unrecognised `Next Header` value mid-chain means: discard, and send Parameter Problem code 1 with a pointer to the offending byte. - Inside Hop-by-Hop and Destination Options, each option's two highest Option Type bits say what to do if it is unrecognised: skip it, discard silently, or discard and send Parameter Problem code 2 (the last case only for non-multicast destinations when the bits are 11). ## Where fragmentation cuts the chain RFC 8200 splits a packet into a **Per-Fragment** part, which is the base header plus every header through the Routing header (or through Hop-by-Hop if there is no Routing header), and the rest. The Per-Fragment part is repeated in every fragment so each can be routed, and the Fragment header follows it. **RFC 7112** adds that the first fragment must hold the entire header chain through the upper-layer header; a host should discard a first fragment that does not and may report Parameter Problem code 3, and routers and firewalls may discard it as well. A host that does not discover the path MTU must keep its header chain within 1,280 bytes.

  • What does an IPv6 destination do when it meets a Next Header value it does not recognise in the middle of the chain?
    It discards the packet and sends ICMPv6 Parameter Problem with code 1, unrecognised Next Header type, with the pointer set to the offset of that value in the original packet. RFC 8200 asks for the same response when Next Header 0 appears anywhere other than the base header.
  • Why does the Fragment header come after the Routing header in the recommended order?
    Because headers that nodes on the path must read have to be present in every fragment. RFC 8200 defines the Per-Fragment part as the base header plus everything through the Routing header, repeats it in each fragment, and places the Fragment header after it; everything behind the Fragment header is what gets split.
  • How does a node handle an option it does not recognise inside a Hop-by-Hop or Destination Options header?
    The two highest bits of the Option Type decide: 00 skip the option, 01 discard the packet, 10 discard and send Parameter Problem code 2, 11 discard and send it only if the destination was not multicast. The third bit says whether the option data may change en route.

A parcel packed in nested boxes, where the label on each box says only what kind of box is inside it. To find what the innermost box holds you read the labels one by one, outermost first; you cannot cut straight to the middle, because nothing tells you where the middle starts.

saying these in an interview costs you the question

  • Receivers drop packets whose extension headers are not in the recommended order.
  • Every router on the path processes every extension header.
  • A receiver may scan ahead to the TCP header and skip the headers in front.
  • Hdr Ext Len gives the extension header's length in bytes.
  • The Fragment header may come before Hop-by-Hop Options if the source prefers.