draft-ietf-mobileip-ip4inip4-02.txt   draft-ietf-mobileip-ip4inip4-03.txt 
Internet Engineering Task Force C. Perkins Internet Engineering Task Force C. Perkins
INTERNET DRAFT IBM INTERNET DRAFT IBM
10 May 1996 31 May 1996
IP Encapsulation within IP IP Encapsulation within IP
draft-ietf-mobileip-ip4inip4-02.txt 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 is a submission by the Mobile IP Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted Internet Engineering Task Force (IETF). Comments should be submitted
to the mobile-ip@SmallWorks.com mailing list. to the mobile-ip@SmallWorks.COM mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft. Internet Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its Working Groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet-Drafts.
Internet Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months, and may be updated, replaced, or obsoleted by other documents and may be updated, replaced, or obsoleted by other documents at
at any time. It is not appropriate to use Internet Drafts as any time. It is inappropriate to use Internet-Drafts as reference
reference material, or to cite them other than as a ``working draft'' material or to cite them other than as "work in progress."
or ``work in progress.''
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the internet-drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
Rim). 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 encapsulated (carried as payload) within an IP datagram. be 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
which would not be otherwise selected by the (network part of the) that would otherwise not be selected by the (network part of the) IP
IP destination field. This may be done for any of a variety of Destination Address field in the original IP header. Encapsulation
reasons, but is particular useful for adherence to the mobile-IP may serve a variety of purposes, such as delivery of a datagram to a
specification. 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 encapsulated (carried as payload) within an IP datagram. be 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
which would not be otherwise selected based the (network part of the) would otherwise not be selected based on the (network part of the)
IP destination field. The process of encapsulation and decapsulation IP Destination Address field in the original IP header. Once the
a datagram is frequently referred to as "tunneling" the datagram, and encapsulated datagram arrives at this intermediate destination node,
the encapsulator and decapsulator are then considered to be the the it is decapsulated, yielding the original IP datagram, which is then
delivered to the destination indicated by the original Destination
Address field. This use 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
"endpoints" of the tunnel. "endpoints" of the tunnel.
In the most general encapsulation case we have In the most general tunneling case we have
source ---> encapsulator --------> decapsulator ---> destination source ---> encapsulator --------> decapsulator ---> destination
with these being separate machines. There may in general be multiple with the source, encapsulator, decapsulator, and destination being
source-destination pairs using the same tunnel. separate nodes. The encapsulator node is considered the "entry
point" of the tunnel, and the decapsulator node is considered
the "exit point" of the tunnel. There in general may be multiple
source-destination pairs using the same tunnel between the
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 a way to deliver datagrams from a mobile host's "home network" as a way to deliver datagrams from a mobile node's "home network" to
to an agent which can deliver datagrams to the mobile host by an agent that can deliver datagrams locally by conventional means
conventional means [7]. The use of encapsulation may also be to the mobile node at its current location away from home [8]. The
desirable whenever the source (or an intermediate router) of an use of encapsulation may also be desirable whenever the source (or
IP datagram must influence the route by which a datagram is to be an intermediate router) of an IP datagram must influence the route
delivered to its ultimate destination. Other possible applications by which a datagram is to be delivered to its ultimate destination.
include preferential billing, choice of routes with selected security Other possible applications of encapsulation include multicasting,
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 source routing techniques It is generally true that encapsulation and the IP loose source
can be used in similar ways to affect the routing of a datagram, but routing option [10] can be used in similar ways to affect the routing
there are several technical reasons to prefer encapsulation: of a datagram, but there are several technical reasons to prefer
encapsulation:
- There are unsolved security problems associated with the use of - There are unsolved security problems associated with the use of
source routing. the IP source routing options.
- Current internet routers exhibit performance problems when - Current Internet routers exhibit performance problems when
forwarding datagrams which use the IP source routing option. forwarding datagrams that contain IP options, including the IP
source routing options.
- Too many internet hosts process source routing options - Many current Internet nodes process IP source routing options
incorrectly. incorrectly.
- Firewalls may exclude source-routed datagrams. - Firewalls may exclude IP source-routed datagrams.
- Insertion of an IP source route option may complicate the - Insertion of an IP source route option may complicate the
processing of authentication information by the source and/or processing of authentication information by the source and/or
destination of a datagram, depending on how the authentication is destination of a datagram, depending on how the authentication is
specified to be performed. specified to be performed.
- It is considered impolite for intermediate routers to make - It is considered impolite for intermediate routers to make
modifications to datagrams which they did not originate. modifications to datagrams which they did not originate.
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 longer 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 tunnel endpoint for the encapsulated datagram can decapsulate the node at the tunnel exit point can decapsulate the datagram.
the datagram.
Since the majority of internet hosts today do not perform well Since the majority of Internet nodes today do not perform well
when IP loose source route options are used, the second technical when 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
An outer IP header is inserted before the datagram's IP header: To encapsulate an IP datagram using IP in IP encapsulation, an outer
IP header [10] is inserted before the datagram's existing IP header,
as follows:
+---------------------------+ +---------------------------+
| |
| Outer IP Header | | Outer IP Header |
| |
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header | | IP Header | | IP Header |
| | | |
+---------------------------+ ====> +---------------------------+ +---------------------------+ ====> +---------------------------+
| | | | | | | |
| | | |
| IP Payload | | IP Payload | | IP Payload | | IP Payload |
| | | | | | | |
| | | |
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
The format of the IP header is described in RFC 791[9]. The outer The outer IP header Source Address and Destination Address identify
IP header source and destination addresses identify the "endpoints" the "endpoints" of the tunnel. The inner IP header Source Address
of the tunnel. The inner IP header source and destination addresses and Destination Addresses identify the original sender and recipient
identify the sender and recipient of the datagram. The inner IP of the datagram, respectively. The inner IP header is not changed
header is not changed by the node which encapsulates it, except by the encapsulator, except to decrement the TTL as noted below, and
to decrement the TTL before delivery. The inner header remains remains unchanged during its delivery to the tunnel exit point. No
unchanged during its delivery to the tunnel endpoint. No change change to IP options in the inner header occurs during delivery of
to IP options in the inner header occurs during delivery of the the encapsulated datagram through the tunnel. If need be, other
encapsulated datagram through the tunnel. If need be, other protocol protocol headers such as the IP Authentication header [1] may be
headers such as the IP Authentication header [1] may be inserted inserted between the outer IP header and the inner IP header. Note
between the outer IP header and the inner IP header (also see that the security options of the inner IP header MAY affect the
section 6.3). choice of security options for the encapsulating (outer) IP header.
3.1. IP Header Fields and Handling 3.1. IP Header Fields and Handling
The fields in the outer IP header are set by the encapsulator as
follows:
Version Version
4 4
IHL IHL
The Internet Header Length measures the length (in bytes) of The Internet Header Length (IHL) is the length of the outer IP
the outer IP header exclusive of its payload, but including any header measured in 32-bit words [10].
options which the encapsulating agent may insert.
TOS TOS
The type of service is copied from the inner IP header. The Type of Service (TOS) is copied from the inner IP header.
Total Length Total Length
The length measures the length of the outer IP header along The Total Length measures the length of the entire encapsulated
with its payload, that is to say (typically) the inner IP IP datagram, including the outer IP header, the inner IP
header and the original datagram. header, and its payload.
Identification, Flags, Fragment Offset Identification, Flags, Fragment Offset
These three fields are set in accordance with the procedures These three fields are set as specified in [10]. However, if
specified in [9]. The "Don't Fragment" bit in the outer IP the "Don't Fragment" bit is set in the inner IP header, it MUST
header is copied from the corresponding flag in the inner IP be set in the outer IP header; if the "Don't Fragment" bit is
header. not set in the inner IP header, it MAY be set in the outer IP
header, as described in Section 5.1.
Time to Live Time to Live
The Time To Live (TTL) field in the outer IP header is set to a The Time To Live (TTL) field in the outer IP header is set to a
value appropriate for delivery of the encapsulated datagram to value appropriate for delivery of the encapsulated datagram to
the tunnel endpoint. the tunnel exit point.
Protocol Protocol
The protocol field in the outer IP header is set to protocol 4
number 4 for the encapsulation protocol.
Header Checksum Header Checksum
The Header Checksum is computed over the length (in bytes) of The Internet Header checksum [10] of the outer IP header.
the outer IP header exclusive of its payload, but including any
options which the encapsulating endpoint may insert.
Source Address Source Address
The IP address of the encapsulating agent, that is, the tunnel The IP address of the encapsulator, that is, the tunnel entry
starting point. point.
Destination Address Destination Address
The IP address of the decapsulating agent, that is, the tunnel The IP address of the decapsulator, that is, the tunnel exit
completion point. point.
Options Options
not copied from the inner IP header. However, new options Any options present in the inner IP header are in general NOT
particular to the path MAY be added. In particular, any copied to the outer IP header. However, new options specific
supported flavors of security options of the inner IP header to the tunnel path MAY be added. In particular, any supported
MAY affect the choice of security options for the tunnel. It types of security options of the inner IP header MAY affect the
is not expected that there be a one-to-one mapping of such choice of security options for the outer header. It is not
options to the options or security headers selected for the expected that there be a one-to-one mapping of such options to
tunnel. the options or security headers selected for the tunnel.
The inner TTL is decremented by one. If the resulting TTL is When encapsulating a datagram, the TTL in the inner IP header
0, the datagram is not tunneled. An encapsulating agent MUST is decremented by one if the tunneling is being done as part of
NOT encapsulate a datagram with TTL = 0 for delivery to a tunnel forwarding the datagram; otherwise, the inner header TTL is not
endpoint. The TTL is not changed when decapsulating. If, after changed during encapsulation. If the resulting TTL in the inner IP
decapsulation, the inner datagram has TTL zero, a tunnel endpoint header is 0, the datagram is discarded and an ICMP Time Exceeded
MUST discard the datagram. If the decapsulator forwards the datagram message SHOULD be returned to the sender. An encapsulator MUST NOT
to some network interface, it will decrement the TTL as a result of encapsulate a datagram with TTL = 0.
doing normal IP forwarding. See also subsection 4.4.
The encapsulating agent is free to use any existing IP mechanisms The TTL in the inner IP header is not changed when decapsulating.
appropriate for delivery of the encapsulated payload to the tunnel If, after decapsulation, the inner datagram has TTL = 0, the
endpoint. In particular, this means that use of IP options and decapsulator MUST discard the datagram. If, after decapsulation, the
fragmentation are allowed, unless the "Don't Fragment" bit is set in decapsulator forwards the datagram to one of its network interfaces,
the inner IP header. This is required so that hosts employing Path it will decrement the TTL as a result of doing normal IP forwarding.
MTU discovery [6] can obtain the information they seek. See also Section 4.4.
The encapsulator may use any existing IP mechanisms appropriate for
delivery of the encapsulated payload to the tunnel exit point. In
particular, use of IP options is allowed, and use of fragmentation
is allowed unless the "Don't Fragment" bit is set in the inner IP
header. This restriction on fragmentation is required so that nodes
employing Path MTU Discovery [7] can obtain the information they
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 cause datagrams to arrive again at the encapsulator. If the they cause datagrams to arrive again at the encapsulator. Suppose
IP Source matches any of its interfaces, an implementation MUST a datagram arrives at a router for forwarding, and the router
NOT further encapsulate. If the IP Source matches the tunnel determines that the datagram has to be encapsulated before further
destination, an implementation SHOULD NOT further encapsulate. See delivery. Then:
also subsection 4.4.
4. ICMP messages from within the tunnel - 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
tunnel the datagram; instead, the datagram SHOULD be discarded.
After an encapsulated datagram has been sent, the encapsulating - If the IP Source Address of the datagram matches the IP address
agent may receive an ICMP [8] message from any intermediate router of the tunnel destination (the tunnel exit point is typically
within the tunnel, except for the tunnel endpoint. The action taken chosen by the router based on the Destination Address in the
by the encapsulating agent depends on the type of ICMP message datagram's IP header), the router MUST NOT tunnel the datagram;
received. When the received message contains enough information, the instead, the datagram SHOULD be discarded.
encapsulating agent may use the incoming message to create a similar
ICMP message, to be sent to the originator of the inner IP datagram. See also Section 4.4.
This process will be referred to as "relaying" the ICMP message to
the source of the original unencapsulated datagram. Relaying an ICMP 4. ICMP Messages from within the Tunnel
message requires that the encapsulator must strip off the outer IP
header which it receives from the sender of the ICMP message. For After an encapsulated datagram has been sent, the encapsulator may
cases where the received message does not contain enough data, see receive an ICMP [9] message from any intermediate router within the
section 5. tunnel other than the tunnel exit point. The action taken by the
encapsulator depends on the type of ICMP message received. When the
received message contains enough information, the encapsulator MAY
use the incoming message to create a similar ICMP message, to be sent
to the originator of the original unencapsulated IP datagram (the
original sender). This process will be referred to as "relaying" the
ICMP message from the tunnel.
ICMP messages indicating an error in processing a datagram include a
copy of (a portion of) the datagram causing the error. Relaying an
ICMP message requires that the encapsulator strip off the outer IP
header from this returned copy of the original datagram. For cases
in which the received ICMP message does not contain enough data to
relay the message, see Section 5.
4.1. Destination Unreachable (Type 3) 4.1. Destination Unreachable (Type 3)
Destination Unreachable messages are handled depending upon their ICMP Destination Unreachable messages are handled by the encapsulator
type. The model suggested here allows the tunnel to "extend" a depending upon their Code field. The model suggested here allows
network to include non-local (e.g., mobile) hosts. Thus, if the the tunnel to "extend" a network to include non-local (e.g., mobile)
original destination in the unencapsulated datagram is on the same nodes. Thus, if the original destination in the unencapsulated
network as the encapsulating agent, certain Destination Unreachable datagram is on the same network as the encapsulator, certain
codes may be modified to conform to the suggested model. Destination Unreachable Code values may be modified to conform to the
suggested model.
Network Unreachable (Code 0) Network Unreachable (Code 0)
A Destination Unreachable message may be returned to An ICMP Destination Unreachable message SHOULD be returned
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 unencapsulated datagram is on the same network as the
the encapsulating agent, the newly generated Destination encapsulator, the newly generated Destination Unreachable
Unreachable message sent by the encapsulating agent MAY have message sent by the encapsulator MAY have Code 1 (Host
code 1 (Host Unreachable), since presumably the datagram Unreachable), since presumably the datagram arrived at the
arrived to the correct network and the encapsulating agent is correct network and the encapsulator is trying to create the
trying to create the appearance that the original destination appearance that the original destination is local to that
is local even if it's not. Otherwise, the encapsulating agent network even if it is not. Otherwise, if the encapsulator
must return a Destination Unreachable with code 0 message to returns a Destination Unreachable message, the Code field MUST
the original sender. be set to 0 (Network Unreachable).
Host Unreachable (Code 1) Host Unreachable (Code 1)
The encapsulating agent must relay Host Unreachable messages to The encapsulator SHOULD relay Host Unreachable messages to the
the source of the original unencapsulated datagram. sender of the original unencapsulated datagram, if possible.
Protocol Unreachable (Code 2) Protocol Unreachable (Code 2)
When the encapsulating agent receives a Protocol Unreachable When the encapsulator receives an ICMP Protocol Unreachable
ICMP message, it should send a Destination Unreachable message message, it SHOULD send a Destination Unreachable message with
with code 0 or 1 (see the discussion for code 0) to the sender Code 0 or 1 (see the discussion for Code 0) to the sender of
of the original unencapsulated datagram. Since the original the original unencapsulated datagram. Since the original
sender might only rarely use protocol 4, it would be usually be sender did not use protocol 4 in sending the datagram, it would
meaningless to return code 2 to that sender. be meaningless to return Code 2 to that sender.
Port Unreachable (Code 3) Port Unreachable (Code 3)
This code should never be received by the encapsulating This Code should never be received by the encapsulator, since
agent, since the outer IP header does not refer to any port the outer IP header does not refer to any port number. It MUST
number. It must not be relayed to the source of the original NOT be relayed to the sender of the original unencapsulated
unencapsulated datagram. datagram.
Datagram Too Big (Code 4) Datagram Too Big (Code 4)
The encapsulating agent must relay Datagram Too Big messages to The encapsulator MUST relay ICMP Datagram Too Big messages to
the source of the original unencapsulated datagram. the sender of the original unencapsulated datagram.
Source Route Failed (Code 5) Source Route Failed (Code 5)
This code should be treated by the encapsulating agent This Code SHOULD be handled by the encapsulator itself.
itself. It must not be relayed to the source of the original It MUST NOT be relayed to the sender of the original
unencapsulated datagram. unencapsulated datagram.
4.2. Source Quench (Type 4) 4.2. Source Quench (Type 4)
The encapsulating agent SHOULD NOT relay Source Quench messages to The encapsulator SHOULD NOT relay ICMP Source Quench messages to the
the source of the original unencapsulated datagram, but instead sender of the original unencapsulated datagram, but instead SHOULD
activate whatever congestion control mechanisms it implements to 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 encapsulating agent may act on the Redirect message if it is The encapsulator MAY handle the ICMP Redirect messages itself.
possible, but it should not relay the Redirect back to the source of It MUST NOT not relay the Redirect to the sender of the original
the datagram which was encapsulated. unencapsulated datagram.
4.4. Time Exceeded (Type 11) 4.4. Time Exceeded (Type 11)
ICMP Time Exceeded messages report routing loops within the tunnel ICMP Time Exceeded messages report (presumed) routing loops
itself. Reception of Time Exceeded messages by the encapsulator MUST within the tunnel itself. Reception of Time Exceeded messages by
be reported to the originator as Host Unreachable (Type 3 Code 1). the encapsulator MUST be reported to the sender of the original
Host Unreachable is preferable to Network Unreachable; since the unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host
datagram was handled by the encapsulator, and the encapsulator is Unreachable is preferable to Network Unreachable; since the datagram
often considered to be on the same network as the destination address was handled by the encapsulator, and the encapsulator is often
in the original unencapsulated datagram, the datagram is considered considered to be on the same network as the destination address in
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
host within that network. node within that network.
4.5. Parameter Problem (Type 12) 4.5. Parameter Problem (Type 12)
If the parameter problem points to a field copied from the original If the Parameter Problem message points to a field copied from the
unencapsulated datagram, the encapsulating agent may relay the ICMP original unencapsulated datagram, the encapsulator MAY relay the
message to the source; otherwise, if the problem occurs with an IP ICMP message to the sender of the original unencapsulated datagram;
option inserted by the encapsulating agent, then the encapsulating otherwise, if the problem occurs with an IP option inserted by
agent must not relay the ICMP message to the source. Note that an the encapsulator, then the encapsulator MUST NOT relay the ICMP
encapsulating agent following prevalent current practice will never message to the original sender. Note that an encapsulator following
insert any IP options into the encapsulated datagram, except possibly prevalent current practice will never insert any IP options into the
for security reasons. encapsulated datagram, except possibly for security reasons.
4.6. Other 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
as specified in [8]. by the encapsulator as specified in [9].
5. Tunnel Management 5. Tunnel Management
Unfortunately, ICMP only requires IP routers to return 8 bytes (64 Unfortunately, ICMP only requires IP routers to return 8 octets
bits) of the datagram beyond the IP header. This is not enough to (64 bits) of the datagram beyond the IP header. This is not enough
include the encapsulated header, so it is not always possible for the to include a copy of the encapsulated (inner) IP header, so it is not
home agent to immediately reflect the ICMP message from the interior always possible for the encapsulator to relay the ICMP message from
of a tunnel back to the originating host. the interior of a tunnel back to the original sender.
However, by carefully maintaining "soft state" about its tunnels, However, by carefully maintaining "soft state" about tunnels into
the encapsulating router can return accurate ICMP messages in most which it sends, the encapsulator can return accurate ICMP messages to
cases. The router SHOULD maintain at least the following soft state the original sender in most cases. The encapsulator SHOULD maintain
information about each tunnel: at least the following soft state information about each tunnel:
- MTU of the tunnel (subsection 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 router uses the ICMP messages it receives from the interior of a The encapsulator uses the ICMP messages it receives from the interior
tunnel to update the soft state information for that tunnel. ICMP of a tunnel to update the soft state information for that tunnel.
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 router checks the soft state for the tunnel. If the datagram the encapsulator checks the soft state for the tunnel. If the
would violate the state of the tunnel (such as, the TTL is less than datagram would violate the state of the tunnel (for example, the TTL
the tunnel TTL) the router sends an ICMP error message back to the of the new datagram is less than the tunnel "soft state" TTL) the
source, but also forwards the datagram into the tunnel. encapsulator sends an ICMP error message back to the sender of the
original datagram, but also encapsulates the datagram and forwards it
into the tunnel.
Using this technique, the ICMP error messages sent by encapsulating Using this technique, the ICMP error messages sent by the
routers will not always match up one-to-one with errors encountered encapsulator will not always match up one-to-one with errors
within the tunnel, but they will accurately reflect the state of the encountered within the tunnel, but they will accurately reflect 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 When the Don't Fragment bit is set by the originator and copied into
into the outer IP header, the proper MTU of the tunnel will the outer IP header, the proper MTU of the tunnel will be learned
be learned from ICMP (Type 3 Code 4) "Datagram Too Big" errors from ICMP Datagram Too Big (Type 3, Code 4) messages reported to
reported to the encapsulator. To support originating hosts the encapsulator. To support sending nodes which use Path MTU
which use this capability, all implementations MUST support Path Discovery, all encapsulator implementations MUST support Path MTU
MTU Discovery [5, 6] within their tunnels. In this particular Discovery [5, 7] soft state within their tunnels. In this particular
application there are several advantages: application, there are several advantages:
- As a benefit of Tunnel MTU Discovery, any fragmentation which - As a benefit of Path MTU Discovery within the tunnel, any
occurs because of the size of the encapsulation header is fragmentation which occurs because of the size of the
performed only once after encapsulation. This prevents multiple encapsulation header is performed only once after encapsulation.
fragmentation of a single datagram, which improves processing This prevents multiple fragmentation of a single datagram, which
efficiency of the path routers and tunnel decapsulator. improves processing efficiency of the decapsulator and the
routers within the tunnel.
- If the source of the unencapsulated datagram is doing MTU - If the source of the unencapsulated datagram is doing Path MTU
discovery then it is desirable for the encapsulator to know the Discovery, then it is desirable for the encapsulator to know
MTU to the decapsulator. If it doesn't know the MTU then it the MTU of the tunnel. Any ICMP Datagram Too Big messages from
can transfer the DF bit to the outer datagram; however, if that within the tunnel are returned to the encapsulator, and as noted
triggers ICMP Datagram Too Big from within the tunnel (and hence in Section 5, it is not always possible for the encapsulator to
returned to the encapsulator) the encapsulator cannot always relay ICMP messages to the source of the original unencapsulated
return a correct ICMP response to the source unless it has kept datagram. By maintaining "soft state" about the MTU of the
state information about recently sent datagrams. If the tunnel tunnel, the encapsulator can return correct ICMP Datagram Too Big
MTU is returned to the source by the encapsulator in a Datagram messages to the original sender of the unencapsulated datagram to
Too Big message, the MTU that is conveyed SHOULD be the MTU of support its own Path MTU Discovery. In this case, the MTU that
the tunnel minus the size of the encapsulating IP header. This is conveyed to the original sender by the encapsulator SHOULD
will avoid fragmentation of the original IP datagram by the be the MTU of the tunnel minus the size of the encapsulating
encapsulator, something that is otherwise certain to occur. IP header. This will avoid fragmentation of the original IP
datagram by the encapsulator.
- If the source is not doing MTU discovery it is still desirable - If the source of the original unencapsulated datagram is
for the encapsulator to know the MTU to the decapsulator. In not doing Path MTU Discovery, it is still desirable for the
particular it is much better to fragment the inner datagram than encapsulator to know the MTU of the tunnel. In particular, it is
to allow the outer datagram to be fragmented. Fragmenting the much better to fragment the original datagram when encapsulating,
inner datagram can be done without special buffer requirements than to allow the encapsulated datagram to be fragmented.
and without the need to keep state in the decapsulator. Fragmenting the original datagram can be done by the encapsulator
By contrast if the outer datagram is fragmented then the without special buffer requirements and without the need to
decapsulator needs to keep state and buffer space on behalf of keep reassembly state in the decapsulator. By contrast, if
the destination. the encapsulated datagram is fragmented, then the decapsulator
must reassemble the fragmented (encapsulated) datagram before
decapsulating it, requiring reassembly state and buffer space
within the decapsulator.
The encapsulator SHOULD in normal circumstances do MTU discovery Thus, the encapsulator SHOULD normally do Path MTU Discovery,
and try to send datagrams with the DF bit set. However there are requiring it to send all datagrams into the tunnel with the "Don't
problems with this approach. When the source sets the DF bit it can Fragment" bit set in the outer IP header. However there are
react quickly to resend the information if it gets a ICMP Datagram problems with this approach. When the original sender sets the
Too Big. When the encapsulator gets a ICMP Datagram Too Big, but the "Don't Fragment" bit, the sender can react quickly to any returned
source had not set the DF bit, then there is nothing sensible that ICMP Datagram Too Big error message by retransmitting the original
the encapsulator can do to let the source know. The encapsulator MAY datagram. On the other hand, suppose that the encapsulator receives
keep a copy of the sent datagram whenever it tries increasing the MTU an ICMP Datagram Too Big message from within the tunnel. In that
- this will allow it to resend the datagram fragmented if it gets a case, if the original sender of the unencapsulated datagram had
datagram too big response. Alternatively the encapsulator MAY be not set the "Don't Fragment" bit, there is nothing sensible that
configured for certain classes of input to not set the DF bit when the encapsulator can do to let the original sender know of the
the source has not set the DF bit. error. The encapsulator MAY keep a copy of the sent datagram
whenever it tries increasing the tunnel MTU, in order to allow it
to fragment and resend the datagram if it gets a Datagram Too Big
response. Alternatively the encapsulator MAY be configured for
certain types of datagrams not to set the "Don't Fragment" bit when
the original sender of the unencapsulated datagram has not set the
"Don't Fragment" bit.
5.2. Congestion 5.2. Congestion
Tunnel soft state will collect indications of congestion, such as An encapsulator might receive indications of congestion from the
an ICMP (Type 4) Source Quench or a Congestion Experienced flag in tunnel, for example, by receiving ICMP Source Quench messages from
datagrams from the decapsulator (tunnel peer). When forwarding nodes within the tunnel. In addition, certain link layers and
another datagram into the tunnel, it is appropriate to use approved various protocols not related to the Internet suite of protocols
means for controlling congestion [3]; Source Quench messages SHOULD might provide such indications in the form of a Congestion
NOT be sent to the originator. Experienced [6] flag. The encapsulator SHOULD reflect conditions of
congestion in its "soft state" for the tunnel, and when subsequently
forwarding datagrams into the tunnel, the encapsulator SHOULD use
appropriate means for controlling congestion [3]; However, the
encapsulator SHOULD NOT send ICMP Source Quench messages to the
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,
For this reason care needs to be taken in the implementation and and care needs to be taken in the implementation and deployment of
deployment. IP encapsulation. For example, IP encapsulation makes it difficult
for border routers to filter datagrams based on header fields. In
Assume an organization has good physical control of a secure subset particular, the original values of the Source Address, Destination
of its network. Assume that the routers connecting that secure Address, and Protocol fields in the IP header, and the port numbers
network do not allow in datagrams with source addresses belonging to used in any transport header within the datagram, are not located
interfaces on that secure network. In that situation it is possible in their normal positions within the datagram after encapsulation.
to safely deploy protocols within that network which depend on the Since any IP datagram can be encapsulated and passed through a
source address of datagrams for authentication purposes. tunnel, such filtering border routers need to carefully examine all
datagrams.
Networks with physical security can still be used to run protocols
which are convenient, but which have implementation or protocol bugs
which would make them dangerous to use if external sources have
access to the protocol. The external sources can be excluded using
router datagram filtering.
IP encapsulation protocols may allow datagrams to bypass the checks
in the border routers. There are two cases to consider:
- The case where the people controlling the border routers are
trying to protect inner machines from themselves.
- The case where the inner machine is looking after its own
defense.
An uncooperative inner machine cannot be protected by the border
router except by barring all packets to that machine. There is
nothing to stop encapsulated IP coming in to that inner machine in
otherwise harmless datagrams such as port 53 UDP datagrams (i.e.,
apparently DNS datagrams). So there is a strong case for placing
the security controls at the host rather than the router. However,
in situations where the administrative control of the inner machine
is cooperative but lacks thoroughness or competence, security can be
enhanced by also putting protection in the border routers.
6.1. Router Considerations 6.1. Router Considerations
Routers need to be aware of IP encapsulation protocols so they can Routers need to be aware of IP encapsulation protocols in order
correctly filter incoming datagrams. to correctly filter incoming datagrams. It is desirable that
such filtering be integrated with IP authentication [1]. Where IP
Beyond that it is desirable that filtering be integrated with IP authentication is used, encapsulated packets might be allowed to
authentication [1]. In the case of IP encapsulation this can have enter an organization when the encapsulating (outer) packet or the
2 forms: Encapsulation might be allowed (in some cases) as long encapsulated (inner) packet is sent by an authenticated, trusted
as the encapsulating datagrams authentically come from an expected source. Encapuslated packets containing no such authentication
encapsulator. Alternatively encapsulation might be allowed if the represent a potentially large security risk.
encapsulated datagrams have authentication.
Data which is encapsulated and encrypted [2] may also pose a problem. IP datagrams which are encapsulated and encrypted [2] might also
In this case the router can only filter the datagram if it knows pose a problem for filtering routers. In this case, the router can
the security association. To allow this sort of encryption in filter the datagram only if it shares the security association used
environments where all packets need to be filtered (or at least for the encryption. To allow this sort of encryption in environments
accounted for) a mechanism must be in place for the receiving host in which all packets need to be filtered (or at least accounted for),
to securely communicate the association to the border router. This a mechanism must be in place for the receiving node to securely
might, more rarely, also apply to the association used for outgoing communicate the security association to the border router. This
datagrams. might, more rarely, also apply to the security association used for
outgoing datagrams.
6.2. Host Considerations 6.2. Host Considerations
Receiving IP encapsulation software SHOULD classify incoming Host implementations that are capable of receiving encapsulated IP
datagrams and only allow datagrams fitting one of the following datagrams SHOULD admit only those datagrams fitting into one or more
categories: of the following categories:
- The protocol is harmless: source address based authentication is - The protocol is harmless: source address-based authentication is
not needed. not needed.
- The datagram can be trusted because of trust in the authentically - The encapsulating (outer) datagram comes from an authentically
identified encapsulating host. That authentic identification identified, trusted source. The authenticity of the source could
could come from physical security plus border router be established by relying on physical security in addition to
configuration but is more likely to come from AH authentication. border router configuration, but is more likely to come from use
of the IP Authentication header [1].
- The inner datagram has AH authentication.
Some or all of this checking could be done in border routers rather - The encapuslated (inner) datagram includes an IP Authentication
than the receiving host but it is better if border router checks are header.
used as backup rather than being the only check.
6.3. Using Security Options - The encapsulated (inner) datagram is addressed to a network
interface belonging to the decapsulator, or to a node with which
the decapsulator has entered into a special relationship for
delivering such encapsulated datagrams.
The security options of the inner IP header MAY affect the choice of Some or all of this checking could be done in border routers rather
security options for the encapsulating IP header. than the receiving node, but it is better if border router checks are
used as backup, rather than being the only check.
7. Acknowledgements 7. Acknowledgements
Parts of sections 3 and 5 of this document were taken from sections Parts of Sections 3 and 5 of this document were taken from portions
(authored by Bill Simpson) of earlier versions of the mobile-IP (authored by Bill Simpson) of earlier versions of the Mobile IP
Internet Draft [7]. Good ideas have also been included from RFC Internet Draft [8]. The original text for section 6 (Security
1853 [10], also authored by Bill Simpson. "Security Considerations" Considerations) was contributed by Bob Smart. Good ideas have also
(section 6) was largely contributed by Bob Smart. Thanks also to been included from RFC 1853 [11], also authored by Bill Simpson.
Anders Klemets for finding mistakes and suggesting many improvements Thanks also to Anders Klemets for finding mistakes and suggesting
to the draft. improvements to the draft. Finally, thanks to David Johnson for
going over the draft with a fine-toothed comb, finding mistakes,
improving consistency, and making many other improvements to the
draft.
References References
[1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
[2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, [2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827,
August 1995. August 1995.
[3] F. Baker, Editor. Requirements for IP Version 4 Routers. RFC [3] F. Baker, 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] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP
Interoperability and Transition Mechanism. Internet Draft -- Interoperability and Transition Mechanism. Internet Draft --
work in progress, March 1994. work in progress, March 1994.
[5] S. Knowles. IESG Advice from Experience with Path MTU [5] S. Knowles. IESG Advice from Experience with Path MTU
Discovery. RFC 1435, March 1993. Discovery. RFC 1435, March 1993.
[6] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, [6] A. Mankin and K. Ramakrishnan. Gateway Congestion Control
Survey. RFC 1254, August 1991.
[7] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191,
November 1990. November 1990.
[7] C. Perkins, Editor. ietf-draft-mobileip-protocol-16.txt - work [8] C. Perkins, Editor. IPv4 Mobility Support.
in progress. IPv4 Mobility Support, April 1996. ietf-draft-mobileip-protocol-17.txt (work in progress), May 1996.
[8] J. B. Postel, Editor. Internet Control Message Protocol. RFC [9] J. B. Postel, Editor. Internet Control Message Protocol. RFC
792, September 1981. 792, September 1981.
[9] J. B. Postel, Editor. Internet Protocol. RFC 791, September [10] J. B. Postel, Editor. Internet Protocol. RFC 791, September
1981. 1981.
[10] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995. [11] W. Simpson. 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 E-mail: perk@watson.ibm.com
The working group can be contacted via the current chairs: The working group can be contacted via the current chair:
Jim Solomon Tony Li Jim Solomon
Motorola, Inc. cisco systems Motorola, Inc.
1301 E. Algonquin Rd. 170 W. Tasman Dr. 1301 E. Algonquin Rd.
Schaumburg, IL 60196 San Jose, CA 95134 Schaumburg, IL 60196
Work: +1-847-576-2753 Work: +1-408-526-8186 Work: +1-847-576-2753
E-mail: solomon@comm.mot.com E-mail: tli@cisco.com E-mail: solomon@comm.mot.com
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/