Summary

  • RFC 1326 described a routing loop in which protocol X was wrapped in Y, then the still-wrapped packet was wrapped in X again. Each local action was intelligible; their composition was unbounded.
  • If a new outer header did not preserve the earlier hop count, the packet gained a fresh apparent lifetime. Header growth eventually caused fragmentation, and the fragments could repeat the same cycle.
  • Preserving hop counts, inspecting inner headers and forbidding nested mutual encapsulation each covered part of the problem. The durable design requirement was a limit that survived every boundary.

The gateway did exactly what its link required

Start with the useful case. A packet written in protocol X must cross a backbone whose native language is Y. The entry router adds a Y header addressed to an exit router. The Y network carries the wrapped packet. At the exit, the Y header is removed and the original X packet continues. Encapsulation changes the route without asking every network in between to understand the inner protocol.

RFC 1326 did not object to that ordinary sequence. Its target was mutual encapsulation: X crossing Y in one part of an internetwork while Y crossed X elsewhere. In 1992 the memo pointed to IP over AppleTalk and AppleTalk over IP, and expected more combinations as IP, CLNP, IPX, DECNET and proprietary systems met. Heterogeneity made wrappers practical. It also made their composition harder to reason about.

The document's example placed X and Y backbones side by side, with routers translating access to each. Now let a transient routing loop form. The X packet reaches a border and becomes Y<X>. Instead of reaching the Y-side exit, the route carries it to a gateway that needs X for the next segment. That gateway does not remove Y; it adds X, producing X<Y<X>>. The packet returns to the first kind of border and receives another Y shell: Y<X<Y<X>>>.

No step needs a malicious packet or an absurd device. Each gateway sees a payload that cannot cross its local backbone natively and supplies the wrapper its segment understands. Local correctness is the engine of the global error.

A counter buried inside an envelope cannot end the envelope's journey

Ordinary forwarding loops are expected to expire. A hop counter is reduced as a packet moves, and the packet is discarded when the budget reaches zero. RFC 1326 isolated the condition that defeats that expectation: successive encapsulations do not preserve the hop-count information in the previous header.

The old counter has not necessarily disappeared. It may still sit intact inside the packet. But the forwarding network now reads the fresh outer header. If every new wrapper brings a fresh outer budget, the value that should prove cumulative travel no longer measures cumulative travel. The packet has several clocks, and the active clock is repeatedly replaced.

This is a precise evidence boundary. An outer hop count proves how far the current wrapper has travelled. It does not prove how many tunnel boundaries the underlying packet has entered. A packet observed with a non-zero outer value may already have circulated many times. Reading the visible field as the history of the whole object confuses the current envelope with the thing being carried.

The problem was sharper across unlike protocols because their lifetimes were not uniform. RFC 1326 noted that some headers, including X.25 and SMDS, did not carry hop counts. Others used different ranges. AppleTalk allowed at most 16 hops while IP could express up to 256. A direct translation into the smaller range might stop the loop, but it could also create a black hole for a legitimate path longer than 16 hops. There was no neutral arithmetic that preserved every protocol's meaning.

Growth became multiplication at the MTU

Every wrapper increases packet length. For a while the failure is linear: one more header each time around the loop. The Maximum Transmission Unit changes its character. When the enlarged packet no longer fits a link, it fragments. Each fragment keeps circulating, receives more headers, reaches another size boundary and may fragment again.

RFC 1326 called the result an exponential explosion in the number of looping packets. The phrase describes the recurrence, not a bomb and not an intrusion. One circulating object becomes several; the several revisit the same transformation; each descendant remains eligible to produce more descendants.

The most consequential passage comes after the growth. The looping packets can saturate the links. If they crowd out routing updates or management packets, the network may discard the very messages that would let its control systems discover and correct the route. The failure does not merely consume capacity. It can remove the feedback required for automatic recovery, leaving an operator to intervene.

RFC 1326 also bounded the end of the story. Once the loop is broken, the packets should flush quickly. That is a mechanism-level expectation, not a report of a named incident, duration or restored service. The RFC described what could happen. It did not document who experienced it.

Looking deeper did not produce omniscience

The memo considered three families of response. The first was to preserve hop count through every encapsulation. That supplies the desired monotonic quantity when both protocols have compatible fields. It becomes ambiguous when one has no counter or when the ranges differ.

The second was header peeking. Before adding X around Y<X>, a router could inspect the layers, notice that X already existed and discard the packet. Yet inspection stopped wherever knowledge stopped. A network protocol might be carried inside a transport protocol. An unknown header might conceal the deeper stack. Encryption could make inner structure unreadable. And repeated appearances of the same protocol were not always erroneous: RFC 1326 constructed a legitimate nested path with two Y headers.

The inspector therefore had a bounded claim. It could say which recognizable layers it observed. It could not infer that an unreadable remainder contained a loop, or that a repeated wrapper was automatically invalid. More visibility improved a local decision without creating authority over meanings it could not see.

The third response was deliberately untidy: discourage mutual encapsulation, outlaw nested mutual encapsulation, preserve counters and inspect headers where appropriate. The 1992 memo offered a warning and design space, not a universal interoperable algorithm. That modest status matters. RFC 1326 was Informational, not an Internet Standard, and its security section said security issues were not discussed. The architectural risk should not be rewritten into evidence of a cyberattack.

Later specifications separated forwarding life from nesting life

RFC 2003 later specified IP within IP. When tunnelling forms part of forwarding, the encapsulator decrements the inner IP TTL once; it must not encapsulate a datagram whose TTL is zero. It also rejects defined cases where the packet source matches the encapsulator itself or the tunnel destination. These rules make particular IP loops less permissive. They do not prove every mixed-protocol tunnel graph safe.

RFC 2473 made the missing dimension explicit for IPv6 tunnelling. It distinguished the original packet's hop limit from a Tunnel Encapsulation Limit. The first accounts for forwarding of the original packet. The second is reduced at every nested encapsulation. A value of zero means the packet cannot enter another tunnel before leaving the current one.

That is more than a larger counter. It is a counter attached to the right event. A hop limit answers how much forwarding life remains in one layer. An encapsulation limit answers how many more wrappers the composed object may acquire. The two values refuse to let one observation masquerade as the other.

RFC 2473 retained the fragmentation warning: nesting can force fragmentation, and fragmenting an already fragmented tunnel packet doubles the fragments. Later engineering did not erase RFC 1326's insight. It gave the insight a more explicit invariant.

Sources

These sources establish document status, described mechanisms and later protocol responses. They establish no actual 1992 explosion, current tunnel, malicious actor, vendor defect, deployment rate, outage, loss or successful repair.