Summary

  • RFC 7872 measured 2014–15 loss for three specific IPv6 probe constructions across web, mail and name-server address sets. Its table values describe those samples, not a current Internet-wide extension-header failure rate.
  • The experiment could estimate whether a drop occurred outside the destination AS, but path, hop and organizational ambiguity required best- and worst-case ranges. It could not prove filtering intent, vendor behavior or which operator should be blamed.

A packet can fail before the destination gets a vote

The operational problem in RFC 7872 is a problem of agency. A destination may deliberately choose IPv6 fragmentation or an extension header. Yet a network earlier on the path may discard the packet before that choice can be exercised. When that happens, the protocol feature is not merely unsupported at one endpoint. Its deployability has been constrained by a third party.

That proposition still matters. The measurements used to expose it, however, are historical. RFC 7872 was published as an Informational RFC in June 2016 and reports experiments made in August 2014, then repeated in June 2015 with similar results. It does not describe an always-on global observatory. It does not update itself whenever the RFC Editor or IETF Datatracker page changes. A percentage in its tables is therefore evidence about a dated experiment, not a baseline for a 2026 network.

The study started with two historical sources of domain names: the World IPv6 Launch list and Alexa's Top 1 Million. From each source it built three address sets: web servers reached through AAAA records, mail servers found through MX and then AAAA resolution, and authoritative name servers found through NS and then AAAA resolution. Duplicate addresses, non-global-unicast addresses and addresses classified as unreachable were removed.

Against those sets, the researchers sent three probe forms. DO8 carried an eight-byte Destination Options header padded with PadN. HBH8 carried an eight-byte Hop-by-Hop Options header, also padded with PadN. FH512 produced approximately two 512-byte IPv6 fragments. Every probe used TCP, and its destination port matched the service under test—for example, port 80 for the web set.

This construction is important because “extension headers were dropped” is already a compression. The study did not exhaust every option type, header order, chain length, packet size, transport, port, source region or policy. It observed three controlled constructions against defined address sets.

How to read the two numbers in each cell

The report gives a total observed drop rate and, in parentheses, a best-case / worst-case estimate of the share of those drops occurring in an AS other than the destination AS. The parenthetical values are conditional on a packet already having been dropped. They are not another packet-drop rate.

For the World IPv6 Launch-derived web set, for example, DO8 had an 11.88% observed drop rate. The range 17.60% / 20.80% means that, among the dropped DO8 packets, the estimated share discarded outside the destination AS lay between those attribution assumptions. HBH8 on the same set had a 40.70% drop rate and a 31.43% / 40.00% non-destination range. FH512 had a 30.51% drop rate and a much smaller 5.08% / 6.78% range.

The rest of the table resists a one-line slogan. In the World IPv6 Launch-derived sets, total drop rates ranged from 11.88% to 17.07% for DO8, 40.70% to 48.86% for HBH8, and 30.51% to 39.17% for FH512 across web, mail and name servers. In the Alexa-derived sets, DO8 ranged from 10.91% to 21.33%, HBH8 from 39.03% to 54.12%, and FH512 from 28.26% to 55.23%.

Attribution varied just as much. Among Alexa-derived web-server drops, the estimated non-destination share was 46.52% / 53.23% for DO8 and 53.64% / 61.43% for FH512. For Alexa-derived name-server HBH8 drops, it was 50.64% / 81.00%. By contrast, the corresponding FH512 range for the World IPv6 Launch mail set was only 2.91% / 12.73%.

Those contrasts are analytically useful. They show why one aggregate “extension-header drop rate” would erase the dimensions the experiment actually varied: source list, service class, header construction and inferred control location. They also prevent the opposite error. A high parenthetical value does not mean that the same percentage of all probes was dropped in transit. It is a percentage of the subset that had already failed.

The route to a drop is an inference

To localize failure, RFC 7872 compared an extension-header-enabled traceroute with an extension-header-free traceroute. It called the last responding hop in the enabled trace M and reasoned about the following hop, M+1. But whether M or M+1 is the dropping node depends on whether a device applies its filter before or after making a forwarding decision. The analysis assumes filtering before forwarding.

It also assumes the two traceroutes take the same path. The RFC explicitly acknowledges that they may not. Equal destination, close timing and similar packets do not guarantee identical routing, load-balancing selection or return behavior.

Even a correctly inferred hop does not automatically identify the controlling organization. A peering address can come from either peer. Address space at an exchange may be associated with the IXP rather than a participant. The operator of the apparent boundary may correspond to the AS mapped to M+1 or the next AS. One organization can operate several ASNs, while the study's model treats different ASNs as different organizations.

That is why the authors published a range. Under the best-case rule, ambiguous cases are assigned to the destination AS. Under the worst-case rule, they are assigned to another AS. The range does not hide a defective measurement. It exposes a real limit in turning packets, interfaces and routing records into organizational responsibility.

Observation is not motive

RFC 7872 is equally careful about cause. A dropped packet might reflect an explicit policy. It might instead result from an unsuitable factory default, a parsing limit, a slow-path protection mechanism, a bug or another implementation condition. The experiment cannot decide among them.

Later documents make plausible mechanisms easier to understand without solving that attribution. RFC 9098 describes why firewalls, middleboxes and routers may struggle with deep or variable parsing, resource consumption, evasion risks and slow-path processing. RFC 9288 turns some of those constraints into transit filtering advice, distinguishing what a device can inspect safely and how an operator might treat different headers. RFC 9673 later revised Hop-by-Hop processing procedures and emphasized bounded, configurable work.

These are mechanism and guidance layers. They do not prove why a 2014 probe failed. Nor does RFC 7045's forwarding guidance prove that a measured implementation conformed or failed to conform. RFC 8200 defines the protocol architecture; it is not a deployment survey.

The distinction matters in incident language. “This path did not return the expected response for this HBH8 probe” is an observation. “The loss likely begins near this boundary under these traceroute assumptions” is an inference. “Transit AS X intentionally blocks IPv6 extension headers” is an attribution of operator, cause and motive. RFC 7872 supports the first, qualifies the second and cannot establish the third.

A 2026 decision needs a 2026 experiment

The right way to use RFC 7872 today is to inherit its discipline, not its percentages. Start by specifying the feature to be deployed: exact header chain and order, option types, lengths, transport, ports, packet sizes and fragmentation behavior. Build a no-extension-header control with the same endpoints and timing. Send both from several authorized vantage points.

Record the probe bytes, timestamps, source and destination, responses, route observations and routing snapshots. Where the endpoint is controlled, capture packets and interface counters. Where a middle boundary is suspected, paired traceroutes are useful, but the report should preserve the path-equivalence and pre-/post-forwarding caveats rather than silently resolving them.

Segment the results by customer, peer, transit, exchange and destination path where the sample supports that distinction. Re-run after route or policy changes. Keep DO, HBH and fragmentation results separate. An apparent boundary should be shared with the relevant operator as packet evidence before it becomes a statement of responsibility.

The decision that follows should be narrow enough to be true: this construction worked or failed for this service, from these sources, across these paths, during this window. That finding can justify a deployment, fallback, exception or escalation. It cannot certify the whole Internet.