Since RFC 7872 measured widespread drops of IPv6 packets carrying extension headers, how would you set a border policy toward them, and should a new design rely on them?
answer
- measured loss differs by header type
- parsing cost and missing ports
- drop by policy, not by ignorance
- type 0 Routing deprecated, not all Routing
- controlled domain versus open internet
basics
~20 sDrop IPv6 extension headers only by deliberate per-type policy, as RFC 7045 requires: permit fragments and Destination Options, drop Routing type 0, limit transit Hop-by-Hop. A new design should use them only inside networks you control.
solid answer
~50 sRFC 7872 sent probes to web, mail and name servers and saw roughly 11-21% loss with an 8-byte Destination Options header, 39-54% with an 8-byte Hop-by-Hop header and 28-55% for fragmented packets, with much of the Hop-by-Hop loss in transit networks. Devices drop them because finding the ports means walking a variable chain, non-first fragments have no ports, Hop-by-Hop often lands on a router's slow path, and Routing type 0 enabled traffic amplification until RFC 5095 deprecated it. RFC 7045 says a forwarding node should pass extension headers, and any discard must be an individually configurable policy whose default allows standard headers. So I would drop type 0 Routing but not every Routing header, keep fragments that carry the full header chain, permit Destination Options, AH and ESP, and limit Hop-by-Hop. A new protocol should depend on them only within one operator's network.
go deeper
Recall that IPv6 packets carrying extension headers, especially Hop-by-Hop and fragments, are often dropped on the public internet.
Explain why devices drop them: walking a variable chain to find ports, fragments without transport headers, and Routing type 0's amplification.
Write a per-type policy that follows RFC 7045 and RFC 5095: drop deliberately, never by default ignorance, never every Routing header, and keep counters to audit it.
Decide where extension headers belong in a design: freely inside a domain you control, cautiously across the internet, with probing and fallback and a scheduled review of the policy.
## What RFC 7872 measured **RFC 7872** (Informational, June 2016) sent TCP probes to the service ports of public web, mail and name servers, from two server datasets, using three kinds of packet: | Probe | Measured drop rate | |---|---| | 8-byte Destination Options header | about 11-21% | | 8-byte Hop-by-Hop Options header | about 39-54% | | Packet split into two fragments of about 512 bytes | about 28-55% | For the Hop-by-Hop probes in particular, a large share of the drops happened in an autonomous system other than the destination's, where the destination's owner could not fix them. The authors note they cannot tell whether a drop was intended policy, a device default or a bug. These numbers are a 2016 snapshot, not a constant; the lesson is the ordering, with Hop-by-Hop and fragments faring worst. ## Why devices drop them - **Finding the ports is expensive.** A firewall or load balancer that needs the transport header must walk a chain of variable length, and hardware that parses a fixed depth may give up. - **Fragments hide ports.** Only the first fragment carries a transport header. RFC 7112 therefore requires the first fragment to contain the whole header chain, and allows routers and firewalls to discard first fragments that do not. - **Hop-by-Hop costs routers.** RFC 7045 notes that many high-speed routers ignore Hop-by-Hop Options or process them on a slow path, and a slow path that outside packets can reach is a resource-exhaustion target. RFC 8200 now expects nodes to examine them only when configured to. - **Routing type 0 was dangerous.** One RH0 could list the same addresses repeatedly, bouncing a packet between two remote nodes; RFC 5095 cites an 88-fold amplification and deprecated RH0 in 2007. - **Unknown types.** RFC 7045 records the catch-22: a new extension header cannot deploy until middleboxes pass it, and middleboxes will not pass it until it has deployed. ## What the standards ask of a forwarding node **RFC 7045** (Standards Track) sets the baseline: 1. A node forwarding IPv6 should do so regardless of the extension headers present. 2. A node that examines them, such as a firewall, must recognise all standard types. 3. Discarding a standard extension header must be the result of **policy, configurable per type**, never of failing to recognise it, and the default should allow all standard types. 4. Packets with an unrecognised header may be dropped by default, but the node must be configurable to allow them. On Routing headers specifically, RFC 5095 says a firewall **must not** simply filter every packet carrying a Routing header, and RFC 7045 lists types 2 and 3 as ones to forward by default. Blocking them all would break Mobile IPv6, which uses type 2. ## A defensible border policy | Header | Stance at an internet border | Reason | |---|---|---| | Hop-by-Hop Options | Drop or rate-limit unless a service you run needs it | Slow-path cost; few legitimate transit uses | | Routing | Drop type 0 (and deprecated type 1); permit others or drop only the types you have decided against | RFC 5095 and RFC 7045 | | Fragment | Permit, but drop first fragments missing the full chain | RFC 7112; large UDP payloads need fragments | | Destination Options | Permit | End-to-end only; lowest measured loss | | AH, ESP | Permit if IPsec is used | Blocking them breaks IPsec | | Unrecognised types | Drop by default, keep a switch to allow | RFC 7045 permits a default drop | Alongside it, keep per-type drop counters so the policy can be audited, and never filter ICMPv6 Packet Too Big, since IPv6 routers do not fragment. ## Should a new design rely on them? This is the judgment part, and there is no single answer: - **Inside one operator's network** (a data centre or a backbone that controls every device), extension headers are a legitimate tool, because you can make every hop parse them. - **Across the public internet**, assume a meaningful fraction of paths drop them, and design so the feature degrades rather than blackholes: probe first, fall back to a plain packet, and treat the header as an optimisation. - If the information is end to end, carrying it inside the transport payload, or encapsulating in UDP, survives middleboxes better than a new header. - Avoid depending on fragmentation: RFC 8200 discourages it for any application able to size packets to the path, and methods such as RFC 8899 let datagram transports find a working size. - Revisit the policy as the measurements change, rather than treating a 2016 table as permanent.
- Why not simply drop every IPv6 packet that carries a Routing header at the border?RFC 5095 forbids a firewall from filtering all Routing headers to stop type 0, and RFC 7045 says undeprecated types such as 2 and 3 should be forwarded by default. Blanket blocking breaks Mobile IPv6, which uses type 2, and makes any future Routing type undeployable.
- Why do fragmented IPv6 packets cause trouble for stateless firewalls even when every fragment arrives?Only the first fragment carries the transport header, so later fragments cannot be matched on ports without keeping state. RFC 7112 at least guarantees the first fragment holds the entire header chain, and lets firewalls discard first fragments that do not.
saying these in an interview costs you the question
- Blocking every Routing header is the correct fix for type 0 attacks.
- Extension headers are rare, so dropping all of them breaks nothing.
- A firewall may drop a standard extension header simply because it cannot parse it.
- Hop-by-Hop Options are safe to pass because routers handle them in hardware.
- RFC 7872's drop rates are a permanent property of IPv6.