Octet

Packets with extension headers are often dropped on the internet. Why, and what does that mean for your filtering policy?

Show the answer

Say this first

Hardware forwards on a fixed number of header bytes. A long header chain pushes the TCP or UDP header past what the ASIC parses, so ACLs cannot match ports, and Hop-by-Hop options get punted to the CPU, which is a denial-of-service risk. Many operators drop or rate-limit those packets, and measurements (RFC 7872) show real loss on the internet. My policy: drop Routing type 0, rate-limit Hop-by-Hop to the control plane, drop packets whose transport header cannot be found, and allow ESP, AH and fragments where needed.

Go deeper

Why routers struggle

  • Parse depth. Line cards look at a fixed window of the packet. If the transport header is beyond it, the ACL sees "unknown" and has to pick between dropping and permitting blind.
  • Hop-by-Hop. Processing options means the slow path. RFC 8200 now lets routers ignore Hop-by-Hop unless configured to process it, but older gear punts it.
  • Fragments. Non-first fragments carry no port numbers at all.

What this means for a filter

TrafficEdge policy
Routing header type 0drop (deprecated, RFC 5095)
Hop-by-Hoprate-limit or drop at the edge unless a service needs it
Transport header not found in the first fragmentdrop
Fragment headerallow, subject to the above, or large UDP like DNS breaks
ESP, AHallow if you run IPsec
Destination Optionsusually allow, watch for abuse

On Cisco IOS a port or interface ACL entry deny ipv6 any any undetermined-transport drops packets whose upper-layer protocol cannot be determined.

Design consequences

  • New protocols that rely on extension headers (SRv6, some in-band telemetry) work inside one operator's network, not reliably across the internet.
  • Security devices must parse the full chain or fail closed.

Traps

  • Assuming the ASIC sees the whole packet.
  • Dropping all fragments and then wondering why DNSSEC answers fail.
How did you do?Book 4.2 IP Version 6