Mutual Encapsulation Considered Dangerous
RFC 1326

Document Type RFC - Informational (May 1992; No errata)
Was draft-tsuchiya-encap (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1326 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        P. Tsuchiya
Request for Comments: 1326                                      Bellcore
                                                                May 1992

               Mutual Encapsulation Considered Dangerous

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   This memo describes a packet explosion problem that can occur with
   mutual encapsulation of protocols (A encapsulates B and B
   encapsulates A).

The Current Environment

   In spite of international standardization efforts to the contrary, we
   are these days seeing a plethora of different protocols, both
   standard and proprietary, each designed to fill a technical or
   marketing niche.  The end result is that they eventually butt up
   against each other and are expected to interwork in some fashion.

   One approach to this interworking is to encapsulate one protocol
   within another.  This has resulted in cases of mutual encapsulation,
   where protocol A runs over protocol B in some cases, and protocol B
   runs over protocol A in other cases.  For example, there exists cases
   of both IP over AppleTalk and AppleTalk over IP.  (The term mutual
   encapsulation comes from the paper by Shoch, Cohen, and Taft, called
   Mutual Encapsulation of Internetwork Protocols", Computer Networks 5,
   North-Holland, 1981, 287-300.  The problem identified in this RFC is
   not mentioned in the Shoch et. al. paper.)

   If there are not already other instances of mutual encapsulation,
   there will likely be more in the future.  This is particularly true
   with respect to the various internet protocols, such as IP, CLNP,
   AppleTalk, IPX, DECNET, and so on.

The Problem

   The problem with mutual encapsulation is the following.  Consider the
   topology shown in Figure 1.  We see two backbones and four stubs.
   Backbone B(X) uses a native protocol of X (that is, it expects to
   receive packets with a header for protocol X).  B(Y) uses a native

Tsuchiya                                                        [Page 1]
RFC 1326                Encapsulation Dangerous                 May 1992

   protocol of Y.  Likewise, the right and left S(Y) stubs use protocol
   Y, and the right and left S(X) stubs use protocol X.

          :::  :::::          :::::   :::          :::
 +------+ :Y   :X:Y  +------+ :X:Y    :Y  +------+ :Y   +------+
 |      | :::  ::::: |      | :::::   ::: |      | :::  |      |
 | S(Y) |-----Ra-----|      |-------Rb----|      |------| S(Y) |
 |      |            |      |             |      |      |      |
 +------+            |      |             |      |      +------+
                     | B(X) |             | B(Y) |
                     |      |             |      |
                :::  |      | :::   ::::: |      | :::::  :::
       +------+  X:  |      |  X:    X:Y: |      |  X:Y:   X: +------+
       |      | :::  |      | :::   ::::: |      | :::::  ::: |      |
       | S(X) |------|      |-----Rc------|      |------Rd----| S(X) |
       |      |      |      |             |      |            |      |
       +------+      |      |-----Re------|      |            +------+
                     +------+             +------+

   LEGEND:

        :::::
         X:Y:  A packet with protocol X encapsulated in protocol
        :::::  Y, moving left to right

           Rx  Router x

         S(Y)  A stub network whose native protocol is protocol Y

         B(X)  A backbone network whose native protocol is protocol X

             FIGURE 1:  MUTUAL ENCAPSULATION

   Figure 1 shows how packets would travel from left S(X) to right S(X),
   and from right S(Y) to left S(Y).  Consider a packet from left S(X)
   to right S(X).  The packet from left S(X) has just a header of X up
   to the point where it reaches router Rc.  Since B(Y) cannot forward
   header X, Rc encapsulates the packet into a Y header with a
   destination address of Rd.  When Rd receives the packet from B(Y), it
   strips off the Y header and forwards the X header packet to right
   S(X).  The reverse situation exists for packets from right S(Y) to
   left S(Y).

   In this example Rc and Rd treat B(Y) as a lower-level subnetwork in
   exactly the same way that an IP router currently treats an Ethernet
   as a lower-level subnetwork.  Note that Rc considers Rd to be the

Tsuchiya                                                        [Page 2]
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
Show full document text