Summary
- TED used tunnel relays and IPv6 Extension Header processing to schedule low-rate traffic sent over 4.2 seconds into a burst: more than 34,000 packets reached a controlled receiver within 250 milliseconds.
- The paper reports 1,909,440 hosts that met its tests during scans from June 2025 to January 2026. The count depends on protocol, source validation and timing conditions; it is not a live census.
The striking number in Le Gai’s paper is 180×. The useful question is what the multiplier measures. In the USENIX Security 2026 experiment, it compares the peak packet-reception rate inside a 20-millisecond window with the average rate sent over the full accumulation period. It is a clock trick in the network, not a byte-amplification ratio.
The team sent 35,029 packets uniformly across 4.2 seconds, about 8,340 packets per second. More than 34,000 arrived at a controlled receiver in one quarter-second. The tunnel paths did the scheduling: nested forwarding and Extension Header handling created different delays, then the sender timed packets so those paths converged.
That makes the tunnel endpoint the important control surface. A tunnel wraps one packet inside another; a permissive endpoint may decide where to forward from the outer header while carrying a complex inner packet onward. If it admits untrusted peers, accepts spoofed inner sources and leaves nested headers untouched, it can provide both relay capacity and delay. A border policy that checks only the envelope is checking the easiest part.
The researchers’ exposure estimate is large, but bounded. From June 2025 through January 2026 they ran 44 scans; each covered about 3.7 billion IPv4 addresses and 20 million IPv6 Hitlist addresses. The cumulative 1,909,440 hosts spanned six tunnel types. In the experiment, the authors used six controlled dual-stack servers in China, Japan, Germany and the United States. They explicitly did not target live operational services.
One standards point needs tighter wording. The paper says RFC 8200 expects Extension Headers to be processed only at the destination. RFC 8200’s text allows Hop-by-Hop options to be examined along the path and says nodes are expected to do so only when explicitly configured; RFC 9673 updates those procedures. That distinction does not remove the tunnel problem. It puts the question where operators can act: which tunnel peers are admitted, what inner source addresses are authorized, and what happens to nested headers after decapsulation.
The authors recommend source-address validation, authenticated tunnel peers, limits on nested encapsulation and deeper inspection. These controls have a cost: a blanket drop rule can also break legitimate encapsulated traffic. Operators need a measured allowlist and logs that show which protocol, peer and header depth triggered a decision.
The paper’s scan ends in January 2026. A repeat scan after those controls are deployed would show how much of the measured exposure remains. Until then, 1.9 million is a dated research result, while the operational task is to find which endpoints still accept traffic they cannot safely forward.
Sources: USENIX proceedings page · USENIX Security 2026 paper · RFC 8200 · RFC 9673 · RFC 2473
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





