RFC 1326 (rfc1326) - Page 1 of 5

Mutual Encapsulation Considered Dangerous

Alternative Format: Original Text Document
Next >
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
Next >