RFC 1326 (rfc1326) - Page 3 of 5

Mutual Encapsulation Considered Dangerous

RFC 1326                Encapsulation Dangerous                 May 1992


   appropriate "exit router" for packets destined for right S(X), and Rb
   considers Ra to be the appropriate "exit router" for packets destined
   for left S(Y).

   Now, assume that somehow a routing loop forms such that routers in
   B(Y) think that Rd is reachable via Rb, Rb thinks that Rd is
   reachable via Re, and routers in B(X) think that Re is reachable via
   Rc.  (This could result as a transient condition in the routing
   algorithm if Rd and Re crashed at the same time.) When the initial
   packet from left S(X) reaches Rc, it is encapsulated with Y and sent
   to B(Y), which forwards it onto Rb.  (The notation for this packet is
   Y, meaning that X in encapsulated in Y.)

   When Rb receives Y from B(Y), it encapsulates the packet in an X
   header to get it to Re through B(X).  Now the packet has headers
   X>.  In other words, the packet has two X encapsulates.  When Rc
   receives X>, it again encapsulates the packet, resulting in
   Y>>.  The packet is growing with each encapsulation.

   Now, if we assume that each successive encapsulation does not
   preserve the hop count information in the previous header, then the
   packet will never expire.  Worse, the packet will eventually reach
   the Maximum Transmission Unit (MTU) size, and will fragment.  Each
   fragment will continue around the loop, getting successively larger
   until those fragments also fragment.  The result is an exponential
   explosion in the number of looping packets!

   The explosion will persist until the links are saturated, and the
   links will remain saturated until the loop is broken.  If the looping
   packets dominate the link to the point where other packets, such as
   routing update packets or management packets, are thrown away, then
   the loop may not automatically break itself, thus requiring manual
   intervention.  Once the loop is broken, the packets will quickly be
   flushed from the network.

Potential Fixes

   The first potential fix that comes to mind is to always preserve the
   hop count information in the new header.  Since hop count information
   is preserved in fragments, the explosion will not occur even if some
   fragmentation occurs before the hop count expires.  Not all headers,
   however, have hop count information in them (for instance, X.25 and
   SMDS).

   And the hop counts ranges for different protocols are different,
   making direct translation not always possible.  For instance,
   AppleTalk has a maximum hop count of 16, whereas IP has up to 256.
   One could define a mapping whereby the hop count is lowered to fit



Tsuchiya