Browse Prior Art Database

Mutual Encapsulation Considered Dangerous (RFC1326)

IP.com Disclosure Number: IPCOM000002148D
Original Publication Date: 1992-May-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 5 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

P. Tsuchiya: AUTHOR

Related Documents

10.17487/RFC1326: DOI

Abstract

This memo describes a packet explosion problem that can occur with mutual encapsulation of protocols (A encapsulates B and B encapsulates A). This memo provides information for the Internet community. It does not specify an Internet standard.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 35% of the total text.

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 head...

Processing...
Loading...