As per Relevance of the word encapsulate, we have this rfc below:
Network Working Group P.
Request for Comments: 1326
May 1992
Mutual Encapsulation Considered
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
This memo describes a packet explosion problem that can occur
mutual encapsulation of protocols (A encapsulates B and
encapsulates A).
The Current
In spite of international standardization efforts to the contrary,
are these days seeing a plethora of different protocols,
standard and proprietary, each designed to fill a technical
marketing niche. The end result is that they eventually butt
against each other and are expected to interwork in some fashion
One approach to this interworking is to encapsulate one
within another. This has resulted in cases of mutual encapsulation
where protocol A runs over protocol B in some cases, and protocol
runs over protocol A in other cases. For example, there exists
of both IP over AppleTalk and AppleTalk over IP. (The term
encapsulation comes from the paper by Shoch, Cohen, and Taft,
Mutual Encapsulation of Internetwork Protocols", Computer Networks 5,
North-Holland, 1981, 287-300. The problem identified in this RFC
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
with respect to the various internet protocols, such as IP, CLNP
AppleTalk, IPX, DECNET, and so on
The
The problem with mutual encapsulation is the following. Consider
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
receive packets with a header for protocol X). B(Y) uses a
Tsuchiya [Page 1]
RFC 1326 Encapsulation Dangerous May 1992
protocol of Y. Likewise, the right and left S(Y) stubs use
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
::::: Y, moving left to
Rx Router
S(Y) A stub network whose native protocol is protocol
B(X) A backbone network whose native protocol is protocol
FIGURE 1: MUTUAL
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
to the point where it reaches router Rc. Since B(Y) cannot
header X, Rc encapsulates the packet into a Y header with
destination address of Rd. When Rd receives the packet from B(Y),
strips off the Y header and forwards the X header packet to
S(X). The reverse situation exists for packets from right S(Y)
left S(Y).
In this example Rc and Rd treat B(Y) as a lower-level subnetwork
exactly the same way that an IP router currently treats an
as a lower-level subnetwork. Note that Rc considers Rd to be
Tsuchiya [Page 2]
RFC 1326 Encapsulation Dangerous May 1992
appropriate "exit router" for packets destined for right S(X), and
considers Ra to be the appropriate "exit router" for packets
for left S(Y).
Now, assume that somehow a routing loop forms such that routers
B(Y) think that Rd is reachable via Rb, Rb thinks that Rd
reachable via Re, and routers in B(X) think that Re is reachable
Rc. (This could result as a transient condition in the
algorithm if Rd and Re crashed at the same time.) When the
packet from left S(X) reaches Rc, it is encapsulated with Y and
to B(Y), which forwards it onto Rb. (The notation for this packet
Y, meaning that X in encapsulated in Y.)
When Rb receives Y from B(Y), it encapsulates the packet in an
header to get it to Re through B(X). Now the packet has
X>. In other words, the packet has two X encapsulates. When
receives X>, it again encapsulates the packet, resulting
Y>>. The packet is growing with each encapsulation
Now, if we assume that each successive encapsulation does
preserve the hop count information in the previous header, then
packet will never expire. Worse, the packet will eventually
the Maximum Transmission Unit (MTU) size, and will fragment.
fragment will continue around the loop, getting successively
until those fragments also fragment. The result is an
explosion in the number of looping packets
The explosion will persist until the links are saturated, and
links will remain saturated until the loop is broken. If the
packets dominate the link to the point where other packets, such
routing update packets or management packets, are thrown away,
the loop may not automatically break itself, thus requiring
intervention. Once the loop is broken, the packets will quickly
flushed from the network
Potential
The first potential fix that comes to mind is to always preserve
hop count information in the new header. Since hop count
is preserved in fragments, the explosion will not occur even if
fragmentation occurs before the hop count expires. Not all headers
however, have hop count information in them (for instance, X.25
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
Tsuchiya [Page 3]
RFC 1326 Encapsulation Dangerous May 1992
into the smaller range when necessary. This, however, might
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
does not preserve hop counts ("A Standard for the Transmission
Internet Packets Over AppleTalk Networks").
Another potential fix is to have routers peek into network
headers to see if the planned encapsulation already exists.
instance, in the example of Figure 1, when Rb receives Y, it
see what Y had encapsulated (for instance by looking at the
id field of X's header), notice that X has already been encapsulated
and throw away the packet. If the encapsulation loop involves
than two protocols, then the router may have to peek into
network layer headers. It would quit when it finally got to
transport layer header
There are several pitfalls with this approach. First, it is
possible that a network layer protocol is being encapsulated within
transport layer protocol, thus I suppose requiring that the
continue to peek even above the transport layer
Second, the router may not recognize one of the network
headers, thus preventing it from peeking any further. For instance
consider a loop involving three routers Rxy, Ryz, and Rzx, and
protocols X, Y, and Z (the subscripts on the routers R denote
protocols the router recognizes). After the first loop, Rxy
X>>. Since Rxy does not recognize Z, it cannot peek beyond
to discover the embedded Y header
Third, a router may be encrypting the packet that it sends to
peer, such as is done with Blacker routers. For instance, Rc
be encrypting packets that it encapsulates for Rd, expecting Rd
decrypt it. When Rb receives this packet (because of the loop),
cannot peek beyond the Y header
Finally, there may be situations where it is appropriate to
multiple instances of the same header. For instance, in the
mutual encapsulation of Figure 2, Ra will encapsulate Y in X to
it to Rd, but Rb will encapsulate X in Y to get it to Rc. In
case, it is appropriate for Rb to transmit a packet with two
headers
A third (somewhat hybrid) solution is to outlaw nested
encapsulation, employ both hop count preservation and header
where appropriate, and generally discourage the use of
encapsulation (or at least adopt the attitude that those who
Tsuchiya [Page 4]
RFC 1326 Encapsulation Dangerous May 1992
in mutual encapsulation deserve what they get).
+--------------------+
| |
| B(X) |
+------+ | +------+ | +------+
| | | | | | | |
| S(Y) |--Ra--+ Rb-| B(Y) |-Rc +--Rd--| S(Y) |
| | | | | | | |
+------+ | +------+ | +------+
| |
| |
+--------------------+
FIGURE 2: NESTED MUTUAL
Security
Security issues are not discussed in this memo
Author's
Paul
435 South St
MRE 2L-281
Morristown, NJ 07960
Phone: (908) 829-4484
EMail: tsuchiya@thumper.bellcore.
Tsuchiya [Page 5]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
