RFC 1326 (rfc1326) - Page 4 of 5


Mutual Encapsulation Considered Dangerous



Alternative Format: Original Text Document

< Previous
Next >


RFC 1326                Encapsulation Dangerous                 May 1992


   into the smaller range when necessary.  This, however, might often
   result in unnecessary black holes because of overly small hop counts.
   There are for instance many IP paths that are longer than 16 hops.

   It is worth noting that the current IP over AppleTalk Internet Draft
   does not preserve hop counts ("A Standard for the Transmission of
   Internet Packets Over AppleTalk Networks").

   Another potential fix is to have routers peek into network layer
   headers to see if the planned encapsulation already exists.  For
   instance, in the example of Figure 1, when Rb receives Y, it would
   see what Y had encapsulated (for instance by looking at the protocol
   id field of X's header), notice that X has already been encapsulated,
   and throw away the packet.  If the encapsulation loop involves more
   than two protocols, then the router may have to peek into successive
   network layer headers.  It would quit when it finally got to a
   transport layer header.

   There are several pitfalls with this approach.  First, it is always
   possible that a network layer protocol is being encapsulated within a
   transport layer protocol, thus I suppose requiring that the router
   continue to peek even above the transport layer.

   Second, the router may not recognize one of the network layer
   headers, thus preventing it from peeking any further.  For instance,
   consider a loop involving three routers Rxy, Ryz, and Rzx, and three
   protocols X, Y, and Z (the subscripts on the routers R denote which
   protocols the router recognizes).  After the first loop, Rxy receives
   X>>.  Since Rxy does not recognize Z, it cannot peek beyond Z
   to discover the embedded Y header.

   Third, a router may be encrypting the packet that it sends to its
   peer, such as is done with Blacker routers.  For instance, Rc might
   be encrypting packets that it encapsulates for Rd, expecting Rd to
   decrypt it.  When Rb receives this packet (because of the loop), it
   cannot peek beyond the Y header.

   Finally, there may be situations where it is appropriate to have
   multiple instances of the same header.  For instance, in the nested
   mutual encapsulation of Figure 2, Ra will encapsulate Y in X to get
   it to Rd, but Rb will encapsulate X in Y to get it to Rc.  In this
   case, it is appropriate for Rb to transmit a packet with two Y
   headers.

   A third (somewhat hybrid) solution is to outlaw nested mutual
   encapsulation, employ both hop count preservation and header peeking
   where appropriate, and generally discourage the use of mutual
   encapsulation (or at least adopt the attitude that those who engage



Tsuchiya


< Previous
Next >


Web Standards & Support:

Link to and support eLook.org Powered by LoadedWeb Web Hosting
Valid XHTML 1.0! Valid CSS! eLook.org FireFox Extensions