summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1326.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1326.txt')
-rw-r--r--doc/rfc/rfc1326.txt283
1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc1326.txt b/doc/rfc/rfc1326.txt
new file mode 100644
index 0000000..a086b39
--- /dev/null
+++ b/doc/rfc/rfc1326.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+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
+ Rc. (This could result as a transient condition in the routing
+ algorithm if Rd and Re crashed at the same time.) When the initial
+ packet from left S(X) reaches Rc, it is encapsulated with Y and sent
+ to B(Y), which forwards it onto Rb. (The notation for this packet is
+ Y<X>, meaning that X in encapsulated in Y.)
+
+ When Rb receives Y<X> from B(Y), it encapsulates the packet in an X
+ header to get it to Re through B(X). Now the packet has headers
+ X<Y<X>>. In other words, the packet has two X encapsulates. When Rc
+ receives X<Y<X>>, it again encapsulates the packet, resulting in
+ Y<X<Y<X>>>. The packet is growing with each encapsulation.
+
+ Now, if we assume that each successive encapsulation does not
+ preserve the hop count information in the previous header, then the
+ packet will never expire. Worse, the packet will eventually reach
+ the Maximum Transmission Unit (MTU) size, and will fragment. Each
+ fragment will continue around the loop, getting successively larger
+ until those fragments also fragment. The result is an exponential
+ explosion in the number of looping packets!
+
+ The explosion will persist until the links are saturated, and the
+ links will remain saturated until the loop is broken. If the looping
+ packets dominate the link to the point where other packets, such as
+ routing update packets or management packets, are thrown away, then
+ the loop may not automatically break itself, thus requiring manual
+ intervention. Once the loop is broken, the packets will quickly be
+ flushed from the network.
+
+Potential Fixes
+
+ The first potential fix that comes to mind is to always preserve the
+ hop count information in the new header. Since hop count information
+ is preserved in fragments, the explosion will not occur even if some
+ fragmentation occurs before the hop count expires. Not all headers,
+ however, have hop count information in them (for instance, X.25 and
+ 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 fit
+
+
+
+Tsuchiya [Page 3]
+
+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<X>, 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<Z<Y<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<Y> 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 [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 ENCAPSULATION
+
+Security Considerations
+
+ Security issues are not discussed in this memo.
+
+Author's Address
+
+ Paul Tsuchiya
+ Bellcore
+ 435 South St.
+ MRE 2L-281
+ Morristown, NJ 07960
+
+ Phone: (908) 829-4484
+ EMail: tsuchiya@thumper.bellcore.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Tsuchiya [Page 5]
+ \ No newline at end of file