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
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
|
<pre>Network Working Group C. Perkins
Request for Comments: 2004 IBM
Category: Standards Track October 1996
<span class="h1">Minimal Encapsulation within IP</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram, with less
overhead than "conventional" IP encapsulation that adds a second IP
header to each encapsulated datagram. Encapsulation is suggested as
a means to alter the normal IP routing for datagrams, by delivering
them to an intermediate destination that would otherwise not be
selected by the (network part of the) IP Destination Address field in
the original IP header. Encapsulation may be serve a variety of
purposes, such as delivery of a datagram to a mobile node using
Mobile IP.
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies a method by which an IP datagram may be
encapsulated (carried as payload) within an IP datagram, with less
overhead than "conventional" IP encapsulation [<a href="#ref-4" title=""IP Encapsulation within IP"">4</a>] that adds a second
IP header to each encapsulated datagram. Encapsulation is suggested
as a means to alter the normal IP routing for datagrams, by
delivering them to an intermediate destination that would otherwise
not be selected by the (network part of the) IP Destination Address
field in the original IP header. The process of encapsulation and
decapsulation of a datagram is frequently referred to as "tunneling"
the datagram, and the encapsulator and decapsulator are then
considered to be the the "endpoints" of the tunnel; the encapsulator
node is refered to as the "entry point" of the tunnel, and the
decapsulator node is refered to as the "exit point" of the tunnel.
<span class="grey">Perkins Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2004">RFC 2004</a> Minimal Encapsulation for IP October 1996</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Motivation</span>
The Mobile IP working group has specified the use of encapsulation as
a way to deliver packets from a mobile node's "home network" to an
agent that can deliver datagrams locally by conventional means to the
mobile node at its current location away from home [<a href="#ref-5" title=""IP Mobility Support"">5</a>]. The use of
encapsulation may also be indicated whenever the source (or an
intermediate router) of an IP datagram must influence the route by
which a datagram is to be delivered to its ultimate destination.
Other possible applications of encapsulation include multicasting,
preferential billing, choice of routes with selected security
attributes, and general policy routing.
See [<a href="#ref-4" title=""IP Encapsulation within IP"">4</a>] for a discussion concerning the advantages of encapsulation
versus use of the IP loose source routing option. Using IP headers
to encapsulate IP datagrams requires the unnecessary duplication of
several fields within the inner IP header; it is possible to save
some additional space by specifying a new encapsulation mechanism
that eliminates the duplication. The scheme outlined here comes from
the Mobile IP Working Group (in earlier Internet Drafts), and is
similar to that which had been defined in [<a href="#ref-2" title="pages 2--11">2</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Minimal Encapsulation</span>
A minimal forwarding header is defined for datagrams which are not
fragmented prior to encapsulation. Use of this encapsulating method
is optional. Minimal encapsulation MUST NOT be used when an original
datagram is already fragmented, since there is no room in the minimal
forwarding header to store fragmentation information. To encapsulate
an IP datagram using minimal encapsulation, the minimal forwarding
header is inserted into the datagram, as follows:
+---------------------------+ +---------------------------+
| | | |
| IP Header | | Modified IP Header |
| | | |
+---------------------------+ ====> +---------------------------+
| | | Minimal Forwarding Header |
| | +---------------------------+
| IP Payload | | |
| | | |
| | | IP Payload |
+---------------------------+ | |
| |
+---------------------------+
<span class="grey">Perkins Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2004">RFC 2004</a> Minimal Encapsulation for IP October 1996</span>
The IP header of the original datagram is modified, and the minimal
forwarding header is inserted into the datagram after the IP header,
followed by the unmodified IP payload of the original datagram (e.g.,
transport header and transport data). No additional IP header is
added to the datagram.
In encapsulating the datagram, the original IP header [<a href="#ref-6" title=""Internet Protocol"">6</a>] is modified
as follows:
- The Protocol field in the IP header is replaced by protocol
number 55 for the minimal encapsulation protocol.
- The Destination Address field in the IP header is replaced by the
IP address of the exit point of the tunnel.
- If the encapsulator is not the original source of the datagram,
the Source Address field in the IP header is replaced by the IP
address of the encapsulator.
- The Total Length field in the IP header is incremented by the
size of the minimal forwarding header added to the datagram.
This incremental size is either 12 or 8 octets, depending on
whether or not the Original Source Address Present (S) bit is set
in the forwarding header.
- The Header Checksum field in the IP header is recomputed [<a href="#ref-6" title=""Internet Protocol"">6</a>] or
updated to account for the changes in the IP header described
here for encapsulation.
Note that unlike IP-in-IP encapsulation [<a href="#ref-4" title=""IP Encapsulation within IP"">4</a>], the Time to Live
(TTL) field in the IP header is not modified during encapsulation;
if the encapsulator is forwarding the datagram, it will decrement
the TTL as a result of doing normal IP forwarding. Also, since
the original TTL remains in the IP header after encapsulation,
hops taken by the datagram within the tunnel are visible, for
example, to "traceroute".
<span class="grey">Perkins Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2004">RFC 2004</a> Minimal Encapsulation for IP October 1996</span>
The format of the minimal forwarding header is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol |S| reserved | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Original Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: (if present) Original Source Address :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Protocol
Copied from the Protocol field in the original IP header.
Original Source Address Present (S)
0 The Original Source Address field is not present. The
length of the minimal tunneling header in this case is
8 octets.
1 The Original Source Address field is present. The
length of the minimal tunneling header in this case is
12 octets.
reserved
Sent as zero; ignored on reception.
Header Checksum
The 16-bit one's complement of the one's complement sum of all
16-bit words in the minimal forwarding header. For purposes of
computing the checksum, the value of the checksum field is 0.
The IP header and IP payload (after the minimal forwarding
header) are not included in this checksum computation.
Original Destination Address
Copied from the Destination Address field in the original IP
header.
Original Source Address
Copied from the Source Address field in the original IP header.
This field is present only if the Original Source Address
Present (S) bit is set.
<span class="grey">Perkins Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2004">RFC 2004</a> Minimal Encapsulation for IP October 1996</span>
When decapsulating a datagram, the fields in the minimal forwarding
header are restored to the IP header, and the forwarding header is
removed from the datagram. In addition, the Total Length field in
the IP header is decremented by the size of the minimal forwarding
header removed from the datagram, and the Header Checksum field in
the IP header is recomputed [<a href="#ref-6" title=""Internet Protocol"">6</a>] or updated to account for the changes
to the IP header described here for decapsulation.
The encapsulator may use existing IP mechanisms appropriate for
delivery of the encapsulated payload to the tunnel exit point. In
particular, use of IP options are allowed, and use of fragmentation
is allowed unless the "Don't Fragment" bit is set in the IP header.
This restriction on fragmentation is required so that nodes employing
Path MTU Discovery [<a href="#ref-3" title=""Path MTU Discovery"">3</a>] can obtain the information they seek.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Routing Failures</span>
The use of any encapsulation method for routing purposes brings with
it increased susceptibility to routing loops. To cut down the
danger, a router should follow the same procedures outlined in [<a href="#ref-4" title=""IP Encapsulation within IP"">4</a>].
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. ICMP Messages from within the Tunnel</span>
ICMP messages are to be handled as specified in [<a href="#ref-4" title=""IP Encapsulation within IP"">4</a>], including the
maintenance of tunnel "soft state".
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
Security considerations are not addressed in this document, but are
generally similar to those outlined in [<a href="#ref-4" title=""IP Encapsulation within IP"">4</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
The original text for much of <a href="#section-3">Section 3</a> was taken from the Mobile IP
draft [<a href="#ref-1" title=""IPv4 Mobility Support"">1</a>]. Thanks to David Johnson for improving consistency and
making many other improvements to the draft.
<span class="grey">Perkins Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2004">RFC 2004</a> Minimal Encapsulation for IP October 1996</span>
References
[<a id="ref-1">1</a>] Perkins, C., Editor, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22IPv4+Mobility+Support%22'>"IPv4 Mobility Support"</a>, Work in Progress,
May 1995.
[<a id="ref-2">2</a>] David B. Johnson. Scalable and Robust Internetwork Routing
for Mobile Hosts. In Proceedings of the 14th International
Conference on Distributed Computing Systems, pages 2--11, June
1994.
[<a id="ref-3">3</a>] Mogul, J., and S. Deering, "Path MTU Discovery", <a href="./rfc1191">RFC 1191</a>,
November 1990.
[<a id="ref-4">4</a>] Perkins, C., "IP Encapsulation within IP", <a href="./rfc2003">RFC 2003</a>,
October 1996.
[<a id="ref-5">5</a>] Perkins, C., Editor, "IP Mobility Support", <a href="./rfc2002">RFC 2002</a>,
October 1996.
[<a id="ref-6">6</a>] Postel, J., Editor, "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>,
September 1981.
Author's Address
Questions about this memo can be directed to:
Charles Perkins
Room H3-D34
T. J. Watson Research Center
IBM Corporation
30 Saw Mill River Rd.
Hawthorne, NY 10532
Work: +1-914-784-7350
Fax: +1-914-784-6205
EMail: perk@watson.ibm.com
The working group can be contacted via the current chair:
Jim Solomon
Motorola, Inc.
1301 E. Algonquin Rd.
Schaumburg, IL 60196
Work: +1-847-576-2753
EMail: solomon@comm.mot.com
Perkins Standards Track [Page 6]
</pre>
|
