draft-ietf-mobileip-ip4inip4-03.txt   rfc2003.txt 
Internet Engineering Task Force C. Perkins
INTERNET DRAFT IBM Network Working Group C. Perkins
31 May 1996 Request for Comment: 2003 IBM
Category: Standards Track October 1996
IP Encapsulation within IP IP Encapsulation within IP
draft-ietf-mobileip-ip4inip4-03.txt
Status of This Memo Status of This Memo
This document is a submission by the Mobile IP Working Group of the This document specifies an Internet standards track protocol for the
Internet Engineering Task Force (IETF). Comments should be submitted Internet community, and requests discussion and suggestions for
to the mobile-ip@SmallWorks.COM mailing list. improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
Distribution of this memo is unlimited. and status of this protocol. Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Abstract Abstract
This document specifies a method by which an IP datagram may This document specifies a method by which an IP datagram may be
be encapsulated (carried as payload) within an IP datagram. encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to alter the normal IP routing Encapsulation is suggested as a means to alter the normal IP routing
for datagrams, by delivering them to an intermediate destination for datagrams, by delivering them to an intermediate destination that
that would otherwise not be selected by the (network part of the) IP would otherwise not be selected by the (network part of the) IP
Destination Address field in the original IP header. Encapsulation Destination Address field in the original IP header. Encapsulation
may serve a variety of purposes, such as delivery of a datagram to a may serve a variety of purposes, such as delivery of a datagram to a
mobile node using Mobile IP. mobile node using Mobile IP.
1. Introduction 1. Introduction
This document specifies a method by which an IP datagram may This document specifies a method by which an IP datagram may be
be encapsulated (carried as payload) within an IP datagram. encapsulated (carried as payload) within an IP datagram.
Encapsulation is suggested as a means to alter the normal IP routing Encapsulation is suggested as a means to alter the normal IP routing
for datagrams, by delivering them to an intermediate destination that for datagrams, by delivering them to an intermediate destination that
would otherwise not be selected based on the (network part of the) would otherwise not be selected based on the (network part of the) IP
IP Destination Address field in the original IP header. Once the Destination Address field in the original IP header. Once the
encapsulated datagram arrives at this intermediate destination node, encapsulated datagram arrives at this intermediate destination node,
it is decapsulated, yielding the original IP datagram, which is then it is decapsulated, yielding the original IP datagram, which is then
delivered to the destination indicated by the original Destination delivered to the destination indicated by the original Destination
Address field. This use of encapsulation and decapsulation of a Address field. This use of encapsulation and decapsulation of a
datagram is frequently referred to as "tunneling" the datagram, and datagram is frequently referred to as "tunneling" the datagram, and
the encapsulator and decapsulator are then considered to be the the encapsulator and decapsulator are then considered to be the
"endpoints" of the tunnel. "endpoints" of the tunnel.
In the most general tunneling case we have In the most general tunneling case we have
source ---> encapsulator --------> decapsulator ---> destination source ---> encapsulator --------> decapsulator ---> destination
with the source, encapsulator, decapsulator, and destination being with the source, encapsulator, decapsulator, and destination being
separate nodes. The encapsulator node is considered the "entry separate nodes. The encapsulator node is considered the "entry
point" of the tunnel, and the decapsulator node is considered point" of the tunnel, and the decapsulator node is considered the
the "exit point" of the tunnel. There in general may be multiple "exit point" of the tunnel. There in general may be multiple
source-destination pairs using the same tunnel between the source-destination pairs using the same tunnel between the
encapsulator and decapsulator. encapsulator and decapsulator.
2. Motivation 2. Motivation
The Mobile IP working group has specified the use of encapsulation The Mobile IP working group has specified the use of encapsulation as
as a way to deliver datagrams from a mobile node's "home network" to a way to deliver datagrams from a mobile node's "home network" to an
an agent that can deliver datagrams locally by conventional means agent that can deliver datagrams locally by conventional means to the
to the mobile node at its current location away from home [8]. The mobile node at its current location away from home [8]. The use of
use of encapsulation may also be desirable whenever the source (or encapsulation may also be desirable whenever the source (or an
an intermediate router) of an IP datagram must influence the route intermediate router) of an IP datagram must influence the route by
by which a datagram is to be delivered to its ultimate destination. which a datagram is to be delivered to its ultimate destination.
Other possible applications of encapsulation include multicasting, Other possible applications of encapsulation include multicasting,
preferential billing, choice of routes with selected security preferential billing, choice of routes with selected security
attributes, and general policy routing. attributes, and general policy routing.
It is generally true that encapsulation and the IP loose source It is generally true that encapsulation and the IP loose source
routing option [10] can be used in similar ways to affect the routing routing option [10] can be used in similar ways to affect the routing
of a datagram, but there are several technical reasons to prefer of a datagram, but there are several technical reasons to prefer
encapsulation: encapsulation:
- There are unsolved security problems associated with the use of - There are unsolved security problems associated with the use of
skipping to change at page 2, line 31 skipping to change at page 3, line 8
These technical advantages must be weighed against the disadvantages These technical advantages must be weighed against the disadvantages
posed by the use of encapsulation: posed by the use of encapsulation:
- Encapsulated datagrams typically are larger than source routed - Encapsulated datagrams typically are larger than source routed
datagrams. datagrams.
- Encapsulation cannot be used unless it is known in advance that - Encapsulation cannot be used unless it is known in advance that
the node at the tunnel exit point can decapsulate the datagram. the node at the tunnel exit point can decapsulate the datagram.
Since the majority of Internet nodes today do not perform well Since the majority of Internet nodes today do not perform well when
when IP loose source route options are used, the second technical IP loose source route options are used, the second technical
disadvantage of encapsulation is not as serious as it might seem at disadvantage of encapsulation is not as serious as it might seem at
first. first.
3. IP in IP Encapsulation 3. IP in IP Encapsulation
To encapsulate an IP datagram using IP in IP encapsulation, an outer To encapsulate an IP datagram using IP in IP encapsulation, an outer
IP header [10] is inserted before the datagram's existing IP header, IP header [10] is inserted before the datagram's existing IP header,
as follows: as follows:
+---------------------------+ +---------------------------+
skipping to change at page 3, line 30 skipping to change at page 3, line 38
| | | | | | | |
| | | | | | | |
| IP Payload | | IP Payload | | IP Payload | | IP Payload |
| | | | | | | |
| | | | | | | |
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
The outer IP header Source Address and Destination Address identify The outer IP header Source Address and Destination Address identify
the "endpoints" of the tunnel. The inner IP header Source Address the "endpoints" of the tunnel. The inner IP header Source Address
and Destination Addresses identify the original sender and recipient and Destination Addresses identify the original sender and recipient
of the datagram, respectively. The inner IP header is not changed of the datagram, respectively. The inner IP header is not changed by
by the encapsulator, except to decrement the TTL as noted below, and the encapsulator, except to decrement the TTL as noted below, and
remains unchanged during its delivery to the tunnel exit point. No remains unchanged during its delivery to the tunnel exit point. No
change to IP options in the inner header occurs during delivery of change to IP options in the inner header occurs during delivery of
the encapsulated datagram through the tunnel. If need be, other the encapsulated datagram through the tunnel. If need be, other
protocol headers such as the IP Authentication header [1] may be protocol headers such as the IP Authentication header [1] may be
inserted between the outer IP header and the inner IP header. Note inserted between the outer IP header and the inner IP header. Note
that the security options of the inner IP header MAY affect the that the security options of the inner IP header MAY affect the
choice of security options for the encapsulating (outer) IP header. choice of security options for the encapsulating (outer) IP header.
3.1. IP Header Fields and Handling 3.1. IP Header Fields and Handling
skipping to change at page 5, line 15 skipping to change at page 5, line 25
Options Options
Any options present in the inner IP header are in general NOT Any options present in the inner IP header are in general NOT
copied to the outer IP header. However, new options specific copied to the outer IP header. However, new options specific
to the tunnel path MAY be added. In particular, any supported to the tunnel path MAY be added. In particular, any supported
types of security options of the inner IP header MAY affect the types of security options of the inner IP header MAY affect the
choice of security options for the outer header. It is not choice of security options for the outer header. It is not
expected that there be a one-to-one mapping of such options to expected that there be a one-to-one mapping of such options to
the options or security headers selected for the tunnel. the options or security headers selected for the tunnel.
When encapsulating a datagram, the TTL in the inner IP header When encapsulating a datagram, the TTL in the inner IP header is
is decremented by one if the tunneling is being done as part of decremented by one if the tunneling is being done as part of
forwarding the datagram; otherwise, the inner header TTL is not forwarding the datagram; otherwise, the inner header TTL is not
changed during encapsulation. If the resulting TTL in the inner IP changed during encapsulation. If the resulting TTL in the inner IP
header is 0, the datagram is discarded and an ICMP Time Exceeded header is 0, the datagram is discarded and an ICMP Time Exceeded
message SHOULD be returned to the sender. An encapsulator MUST NOT message SHOULD be returned to the sender. An encapsulator MUST NOT
encapsulate a datagram with TTL = 0. encapsulate a datagram with TTL = 0.
The TTL in the inner IP header is not changed when decapsulating. The TTL in the inner IP header is not changed when decapsulating.
If, after decapsulation, the inner datagram has TTL = 0, the If, after decapsulation, the inner datagram has TTL = 0, the
decapsulator MUST discard the datagram. If, after decapsulation, the decapsulator MUST discard the datagram. If, after decapsulation, the
decapsulator forwards the datagram to one of its network interfaces, decapsulator forwards the datagram to one of its network interfaces,
it will decrement the TTL as a result of doing normal IP forwarding. it will decrement the TTL as a result of doing normal IP forwarding.
See also Section 4.4. See also Section 4.4.
The encapsulator may use any existing IP mechanisms appropriate for The encapsulator may use any existing IP mechanisms appropriate for
delivery of the encapsulated payload to the tunnel exit point. In delivery of the encapsulated payload to the tunnel exit point. In
particular, use of IP options is allowed, and use of fragmentation particular, use of IP options is allowed, and use of fragmentation is
is allowed unless the "Don't Fragment" bit is set in the inner IP allowed unless the "Don't Fragment" bit is set in the inner IP
header. This restriction on fragmentation is required so that nodes header. This restriction on fragmentation is required so that nodes
employing Path MTU Discovery [7] can obtain the information they employing Path MTU Discovery [7] can obtain the information they
seek. seek.
3.2. Routing Failures 3.2. Routing Failures
Routing loops within a tunnel are particularly dangerous when Routing loops within a tunnel are particularly dangerous when they
they cause datagrams to arrive again at the encapsulator. Suppose cause datagrams to arrive again at the encapsulator. Suppose a
a datagram arrives at a router for forwarding, and the router datagram arrives at a router for forwarding, and the router
determines that the datagram has to be encapsulated before further determines that the datagram has to be encapsulated before further
delivery. Then: delivery. Then:
- If the IP Source Address of the datagram matches the router's own - If the IP Source Address of the datagram matches the router's own
IP address on any of its network interfaces, the router MUST NOT IP address on any of its network interfaces, the router MUST NOT
tunnel the datagram; instead, the datagram SHOULD be discarded. tunnel the datagram; instead, the datagram SHOULD be discarded.
- If the IP Source Address of the datagram matches the IP address - If the IP Source Address of the datagram matches the IP address
of the tunnel destination (the tunnel exit point is typically of the tunnel destination (the tunnel exit point is typically
chosen by the router based on the Destination Address in the chosen by the router based on the Destination Address in the
skipping to change at page 6, line 32 skipping to change at page 6, line 41
ICMP messages indicating an error in processing a datagram include a ICMP messages indicating an error in processing a datagram include a
copy of (a portion of) the datagram causing the error. Relaying an copy of (a portion of) the datagram causing the error. Relaying an
ICMP message requires that the encapsulator strip off the outer IP ICMP message requires that the encapsulator strip off the outer IP
header from this returned copy of the original datagram. For cases header from this returned copy of the original datagram. For cases
in which the received ICMP message does not contain enough data to in which the received ICMP message does not contain enough data to
relay the message, see Section 5. relay the message, see Section 5.
4.1. Destination Unreachable (Type 3) 4.1. Destination Unreachable (Type 3)
ICMP Destination Unreachable messages are handled by the encapsulator ICMP Destination Unreachable messages are handled by the encapsulator
depending upon their Code field. The model suggested here allows depending upon their Code field. The model suggested here allows the
the tunnel to "extend" a network to include non-local (e.g., mobile) tunnel to "extend" a network to include non-local (e.g., mobile)
nodes. Thus, if the original destination in the unencapsulated nodes. Thus, if the original destination in the unencapsulated
datagram is on the same network as the encapsulator, certain datagram is on the same network as the encapsulator, certain
Destination Unreachable Code values may be modified to conform to the Destination Unreachable Code values may be modified to conform to the
suggested model. suggested model.
Network Unreachable (Code 0) Network Unreachable (Code 0)
An ICMP Destination Unreachable message SHOULD be returned An ICMP Destination Unreachable message SHOULD be returned
to the original sender. If the original destination in to the original sender. If the original destination in
the unencapsulated datagram is on the same network as the the unencapsulated datagram is on the same network as the
skipping to change at page 8, line 7 skipping to change at page 8, line 14
4.2. Source Quench (Type 4) 4.2. Source Quench (Type 4)
The encapsulator SHOULD NOT relay ICMP Source Quench messages to the The encapsulator SHOULD NOT relay ICMP Source Quench messages to the
sender of the original unencapsulated datagram, but instead SHOULD sender of the original unencapsulated datagram, but instead SHOULD
activate whatever congestion control mechanisms it implements to help activate whatever congestion control mechanisms it implements to help
alleviate the congestion detected within the tunnel. alleviate the congestion detected within the tunnel.
4.3. Redirect (Type 5) 4.3. Redirect (Type 5)
The encapsulator MAY handle the ICMP Redirect messages itself. The encapsulator MAY handle the ICMP Redirect messages itself. It
It MUST NOT not relay the Redirect to the sender of the original MUST NOT not relay the Redirect to the sender of the original
unencapsulated datagram. unencapsulated datagram.
4.4. Time Exceeded (Type 11) 4.4. Time Exceeded (Type 11)
ICMP Time Exceeded messages report (presumed) routing loops ICMP Time Exceeded messages report (presumed) routing loops within
within the tunnel itself. Reception of Time Exceeded messages by the tunnel itself. Reception of Time Exceeded messages by the
the encapsulator MUST be reported to the sender of the original encapsulator MUST be reported to the sender of the original
unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host
Unreachable is preferable to Network Unreachable; since the datagram Unreachable is preferable to Network Unreachable; since the datagram
was handled by the encapsulator, and the encapsulator is often was handled by the encapsulator, and the encapsulator is often
considered to be on the same network as the destination address in considered to be on the same network as the destination address in
the original unencapsulated datagram, then the datagram is considered the original unencapsulated datagram, then the datagram is considered
to have reached the correct network, but not the correct destination to have reached the correct network, but not the correct destination
node within that network. node within that network.
4.5. Parameter Problem (Type 12) 4.5. Parameter Problem (Type 12)
If the Parameter Problem message points to a field copied from the If the Parameter Problem message points to a field copied from the
original unencapsulated datagram, the encapsulator MAY relay the original unencapsulated datagram, the encapsulator MAY relay the ICMP
ICMP message to the sender of the original unencapsulated datagram; message to the sender of the original unencapsulated datagram;
otherwise, if the problem occurs with an IP option inserted by otherwise, if the problem occurs with an IP option inserted by the
the encapsulator, then the encapsulator MUST NOT relay the ICMP encapsulator, then the encapsulator MUST NOT relay the ICMP message
message to the original sender. Note that an encapsulator following to the original sender. Note that an encapsulator following
prevalent current practice will never insert any IP options into the prevalent current practice will never insert any IP options into the
encapsulated datagram, except possibly for security reasons. encapsulated datagram, except possibly for security reasons.
4.6. Other ICMP Messages 4.6. Other ICMP Messages
Other ICMP messages are not related to the encapsulation operations Other ICMP messages are not related to the encapsulation operations
described within this protocol specification, and should be acted on described within this protocol specification, and should be acted on
by the encapsulator as specified in [9]. by the encapsulator as specified in [9].
5. Tunnel Management 5. Tunnel Management
Unfortunately, ICMP only requires IP routers to return 8 octets Unfortunately, ICMP only requires IP routers to return 8 octets (64
(64 bits) of the datagram beyond the IP header. This is not enough bits) of the datagram beyond the IP header. This is not enough to
to include a copy of the encapsulated (inner) IP header, so it is not include a copy of the encapsulated (inner) IP header, so it is not
always possible for the encapsulator to relay the ICMP message from always possible for the encapsulator to relay the ICMP message from
the interior of a tunnel back to the original sender. the interior of a tunnel back to the original sender. However, by
carefully maintaining "soft state" about tunnels into which it sends,
However, by carefully maintaining "soft state" about tunnels into the encapsulator can return accurate ICMP messages to the original
which it sends, the encapsulator can return accurate ICMP messages to sender in most cases. The encapsulator SHOULD maintain at least the
the original sender in most cases. The encapsulator SHOULD maintain following soft state information about each tunnel:
at least the following soft state information about each tunnel:
- MTU of the tunnel (Section 5.1) - MTU of the tunnel (Section 5.1)
- TTL (path length) of the tunnel - TTL (path length) of the tunnel
- Reachability of the end of the tunnel - Reachability of the end of the tunnel
The encapsulator uses the ICMP messages it receives from the interior The encapsulator uses the ICMP messages it receives from the interior
of a tunnel to update the soft state information for that tunnel. of a tunnel to update the soft state information for that tunnel.
ICMP errors that could be received from one of the routers along the ICMP errors that could be received from one of the routers along the
tunnel interior include: tunnel interior include:
- Datagram Too Big - Datagram Too Big
- Time Exceeded - Time Exceeded
- Destination Unreachable - Destination Unreachable
- Source Quench - Source Quench
When subsequent datagrams arrive that would transit the tunnel, When subsequent datagrams arrive that would transit the tunnel, the
the encapsulator checks the soft state for the tunnel. If the encapsulator checks the soft state for the tunnel. If the datagram
datagram would violate the state of the tunnel (for example, the TTL would violate the state of the tunnel (for example, the TTL of the
of the new datagram is less than the tunnel "soft state" TTL) the new datagram is less than the tunnel "soft state" TTL) the
encapsulator sends an ICMP error message back to the sender of the encapsulator sends an ICMP error message back to the sender of the
original datagram, but also encapsulates the datagram and forwards it original datagram, but also encapsulates the datagram and forwards it
into the tunnel. into the tunnel.
Using this technique, the ICMP error messages sent by the Using this technique, the ICMP error messages sent by the
encapsulator will not always match up one-to-one with errors encapsulator will not always match up one-to-one with errors
encountered within the tunnel, but they will accurately reflect the encountered within the tunnel, but they will accurately reflect the
state of the network. state of the network.
Tunnel soft state was originally developed for the IP Address Tunnel soft state was originally developed for the IP Address
Encapsulation (IPAE) specification [4]. Encapsulation (IPAE) specification [4].
5.1. Tunnel MTU Discovery 5.1. Tunnel MTU Discovery
When the Don't Fragment bit is set by the originator and copied into When the Don't Fragment bit is set by the originator and copied into
the outer IP header, the proper MTU of the tunnel will be learned the outer IP header, the proper MTU of the tunnel will be learned
from ICMP Datagram Too Big (Type 3, Code 4) messages reported to from ICMP Datagram Too Big (Type 3, Code 4) messages reported to the
the encapsulator. To support sending nodes which use Path MTU encapsulator. To support sending nodes which use Path MTU Discovery,
Discovery, all encapsulator implementations MUST support Path MTU all encapsulator implementations MUST support Path MTU Discovery [5,
Discovery [5, 7] soft state within their tunnels. In this particular 7] soft state within their tunnels. In this particular application,
application, there are several advantages: there are several advantages:
- As a benefit of Path MTU Discovery within the tunnel, any - As a benefit of Path MTU Discovery within the tunnel, any
fragmentation which occurs because of the size of the fragmentation which occurs because of the size of the
encapsulation header is performed only once after encapsulation. encapsulation header is performed only once after encapsulation.
This prevents multiple fragmentation of a single datagram, which This prevents multiple fragmentation of a single datagram, which
improves processing efficiency of the decapsulator and the improves processing efficiency of the decapsulator and the
routers within the tunnel. routers within the tunnel.
- If the source of the unencapsulated datagram is doing Path MTU - If the source of the unencapsulated datagram is doing Path MTU
Discovery, then it is desirable for the encapsulator to know Discovery, then it is desirable for the encapsulator to know
skipping to change at page 10, line 39 skipping to change at page 10, line 45
Fragmenting the original datagram can be done by the encapsulator Fragmenting the original datagram can be done by the encapsulator
without special buffer requirements and without the need to without special buffer requirements and without the need to
keep reassembly state in the decapsulator. By contrast, if keep reassembly state in the decapsulator. By contrast, if
the encapsulated datagram is fragmented, then the decapsulator the encapsulated datagram is fragmented, then the decapsulator
must reassemble the fragmented (encapsulated) datagram before must reassemble the fragmented (encapsulated) datagram before
decapsulating it, requiring reassembly state and buffer space decapsulating it, requiring reassembly state and buffer space
within the decapsulator. within the decapsulator.
Thus, the encapsulator SHOULD normally do Path MTU Discovery, Thus, the encapsulator SHOULD normally do Path MTU Discovery,
requiring it to send all datagrams into the tunnel with the "Don't requiring it to send all datagrams into the tunnel with the "Don't
Fragment" bit set in the outer IP header. However there are Fragment" bit set in the outer IP header. However there are problems
problems with this approach. When the original sender sets the with this approach. When the original sender sets the "Don't
"Don't Fragment" bit, the sender can react quickly to any returned Fragment" bit, the sender can react quickly to any returned ICMP
ICMP Datagram Too Big error message by retransmitting the original Datagram Too Big error message by retransmitting the original
datagram. On the other hand, suppose that the encapsulator receives datagram. On the other hand, suppose that the encapsulator receives
an ICMP Datagram Too Big message from within the tunnel. In that an ICMP Datagram Too Big message from within the tunnel. In that
case, if the original sender of the unencapsulated datagram had case, if the original sender of the unencapsulated datagram had not
not set the "Don't Fragment" bit, there is nothing sensible that set the "Don't Fragment" bit, there is nothing sensible that the
the encapsulator can do to let the original sender know of the encapsulator can do to let the original sender know of the error.
error. The encapsulator MAY keep a copy of the sent datagram The encapsulator MAY keep a copy of the sent datagram whenever it
whenever it tries increasing the tunnel MTU, in order to allow it tries increasing the tunnel MTU, in order to allow it to fragment and
to fragment and resend the datagram if it gets a Datagram Too Big resend the datagram if it gets a Datagram Too Big response.
response. Alternatively the encapsulator MAY be configured for Alternatively the encapsulator MAY be configured for certain types of
certain types of datagrams not to set the "Don't Fragment" bit when datagrams not to set the "Don't Fragment" bit when the original
the original sender of the unencapsulated datagram has not set the sender of the unencapsulated datagram has not set the "Don't
"Don't Fragment" bit. Fragment" bit.
5.2. Congestion 5.2. Congestion
An encapsulator might receive indications of congestion from the An encapsulator might receive indications of congestion from the
tunnel, for example, by receiving ICMP Source Quench messages from tunnel, for example, by receiving ICMP Source Quench messages from
nodes within the tunnel. In addition, certain link layers and nodes within the tunnel. In addition, certain link layers and
various protocols not related to the Internet suite of protocols various protocols not related to the Internet suite of protocols
might provide such indications in the form of a Congestion might provide such indications in the form of a Congestion
Experienced [6] flag. The encapsulator SHOULD reflect conditions of Experienced [6] flag. The encapsulator SHOULD reflect conditions of
congestion in its "soft state" for the tunnel, and when subsequently congestion in its "soft state" for the tunnel, and when subsequently
forwarding datagrams into the tunnel, the encapsulator SHOULD use forwarding datagrams into the tunnel, the encapsulator SHOULD use
appropriate means for controlling congestion [3]; However, the appropriate means for controlling congestion [3]; However, the
encapsulator SHOULD NOT send ICMP Source Quench messages to the encapsulator SHOULD NOT send ICMP Source Quench messages to the
original sender of the unencapsulated datagram. original sender of the unencapsulated datagram.
6. Security Considerations 6. Security Considerations
IP encapsulation potentially reduces the security of the Internet, IP encapsulation potentially reduces the security of the Internet,
and care needs to be taken in the implementation and deployment of and care needs to be taken in the implementation and deployment of IP
IP encapsulation. For example, IP encapsulation makes it difficult encapsulation. For example, IP encapsulation makes it difficult for
for border routers to filter datagrams based on header fields. In border routers to filter datagrams based on header fields. In
particular, the original values of the Source Address, Destination particular, the original values of the Source Address, Destination
Address, and Protocol fields in the IP header, and the port numbers Address, and Protocol fields in the IP header, and the port numbers
used in any transport header within the datagram, are not located used in any transport header within the datagram, are not located in
in their normal positions within the datagram after encapsulation. their normal positions within the datagram after encapsulation.
Since any IP datagram can be encapsulated and passed through a Since any IP datagram can be encapsulated and passed through a
tunnel, such filtering border routers need to carefully examine all tunnel, such filtering border routers need to carefully examine all
datagrams. datagrams.
6.1. Router Considerations 6.1. Router Considerations
Routers need to be aware of IP encapsulation protocols in order Routers need to be aware of IP encapsulation protocols in order to
to correctly filter incoming datagrams. It is desirable that correctly filter incoming datagrams. It is desirable that such
such filtering be integrated with IP authentication [1]. Where IP filtering be integrated with IP authentication [1]. Where IP
authentication is used, encapsulated packets might be allowed to authentication is used, encapsulated packets might be allowed to
enter an organization when the encapsulating (outer) packet or the enter an organization when the encapsulating (outer) packet or the
encapsulated (inner) packet is sent by an authenticated, trusted encapsulated (inner) packet is sent by an authenticated, trusted
source. Encapuslated packets containing no such authentication source. Encapuslated packets containing no such authentication
represent a potentially large security risk. represent a potentially large security risk.
IP datagrams which are encapsulated and encrypted [2] might also IP datagrams which are encapsulated and encrypted [2] might also pose
pose a problem for filtering routers. In this case, the router can a problem for filtering routers. In this case, the router can filter
filter the datagram only if it shares the security association used the datagram only if it shares the security association used for the
for the encryption. To allow this sort of encryption in environments encryption. To allow this sort of encryption in environments in
in which all packets need to be filtered (or at least accounted for), which all packets need to be filtered (or at least accounted for), a
a mechanism must be in place for the receiving node to securely mechanism must be in place for the receiving node to securely
communicate the security association to the border router. This communicate the security association to the border router. This
might, more rarely, also apply to the security association used for might, more rarely, also apply to the security association used for
outgoing datagrams. outgoing datagrams.
6.2. Host Considerations 6.2. Host Considerations
Host implementations that are capable of receiving encapsulated IP Host implementations that are capable of receiving encapsulated IP
datagrams SHOULD admit only those datagrams fitting into one or more datagrams SHOULD admit only those datagrams fitting into one or more
of the following categories: of the following categories:
skipping to change at page 13, line 20 skipping to change at page 13, line 20
Considerations) was contributed by Bob Smart. Good ideas have also Considerations) was contributed by Bob Smart. Good ideas have also
been included from RFC 1853 [11], also authored by Bill Simpson. been included from RFC 1853 [11], also authored by Bill Simpson.
Thanks also to Anders Klemets for finding mistakes and suggesting Thanks also to Anders Klemets for finding mistakes and suggesting
improvements to the draft. Finally, thanks to David Johnson for improvements to the draft. Finally, thanks to David Johnson for
going over the draft with a fine-toothed comb, finding mistakes, going over the draft with a fine-toothed comb, finding mistakes,
improving consistency, and making many other improvements to the improving consistency, and making many other improvements to the
draft. draft.
References References
[1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, [2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
August 1995. August 1995.
[3] F. Baker, Editor. Requirements for IP Version 4 Routers. RFC [3] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC
1812, June 1995. 1812, June 1995.
[4] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP [4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The SIPP
Interoperability and Transition Mechanism. Internet Draft -- Interoperability and Transition Mechanism", Work in Progress.
work in progress, March 1994.
[5] S. Knowles. IESG Advice from Experience with Path MTU [5] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery. RFC 1435, March 1993. Discovery", RFC 1435, March 1993.
[6] A. Mankin and K. Ramakrishnan. Gateway Congestion Control [6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion Control
Survey. RFC 1254, August 1991. Survey", RFC 1254, August 1991.
[7] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, [7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990. November 1990.
[8] C. Perkins, Editor. IPv4 Mobility Support. [8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
ietf-draft-mobileip-protocol-17.txt (work in progress), May 1996. October 1996.
[9] J. B. Postel, Editor. Internet Control Message Protocol. RFC [9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,
792, September 1981. RFC 792, September 1981.
[10] J. B. Postel, Editor. Internet Protocol. RFC 791, September [10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
1981. September 1981.
[11] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995. [11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
Author's Address Author's Address
Questions about this memo can be directed to: Questions about this memo can be directed to:
Charles Perkins Charles Perkins
Room H3-D34 Room H3-D34
T. J. Watson Research Center T. J. Watson Research Center
IBM Corporation IBM Corporation
30 Saw Mill River Rd. 30 Saw Mill River Rd.
Hawthorne, NY 10532 Hawthorne, NY 10532
Work: +1-914-784-7350 Work: +1-914-784-7350
Fax: +1-914-784-6205 Fax: +1-914-784-6205
E-mail: perk@watson.ibm.com EMail: perk@watson.ibm.com
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
Jim Solomon Jim Solomon
Motorola, Inc. Motorola, Inc.
1301 E. Algonquin Rd. 1301 E. Algonquin Rd.
Schaumburg, IL 60196 Schaumburg, IL 60196
Work: +1-847-576-2753 Work: +1-847-576-2753
E-mail: solomon@comm.mot.com EMail: solomon@comm.mot.com
 End of changes. 43 change blocks. 
145 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/