File: rfc1326.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (283 lines) | stat: -rw-r--r-- 11,277 bytes parent folder | download | duplicates (5)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
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]