As per Relevance of the word encapsulate, we have this rfc below:
Network Working Group C.
Request for Comment: 2003
Category: Standards Track October 1996
IP Encapsulation within
Status of This
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
This document specifies a method by which an IP datagram may
encapsulated (carried as payload) within an IP datagram
Encapsulation is suggested as a means to alter the normal IP
for datagrams, by delivering them to an intermediate destination
would otherwise not be selected by the (network part of the)
Destination Address field in the original IP header.
may serve a variety of purposes, such as delivery of a datagram to
mobile node using Mobile IP
1.
This document specifies a method by which an IP datagram may
encapsulated (carried as payload) within an IP datagram
Encapsulation is suggested as a means to alter the normal IP
for datagrams, by delivering them to an intermediate destination
would otherwise not be selected based on the (network part of the)
Destination Address field in the original IP header. Once
encapsulated datagram arrives at this intermediate destination node
it is decapsulated, yielding the original IP datagram, which is
delivered to the destination indicated by the original
Address field. This use of encapsulation and decapsulation of
datagram is frequently referred to as "tunneling" the datagram,
the encapsulator and decapsulator are then considered to be
"endpoints" of the tunnel
In the most general tunneling case we
source ---> encapsulator --------> decapsulator --->
with the source, encapsulator, decapsulator, and destination
separate nodes. The encapsulator node is considered the "
Perkins Standards Track [Page 1]
RFC 2003 IP-within-IP October 1996
point" of the tunnel, and the decapsulator node is considered
"exit point" of the tunnel. There in general may be
source-destination pairs using the same tunnel between
encapsulator and decapsulator
2.
The Mobile IP working group has specified the use of encapsulation
a way to deliver datagrams from a mobile node's "home network" to
agent that can deliver datagrams locally by conventional means to
mobile node at its current location away from home [8]. The use
encapsulation may also be desirable whenever the source (or
intermediate router) of an IP datagram must influence the route
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
attributes, and general policy routing
It is generally true that encapsulation and the IP loose
routing option [10] can be used in similar ways to affect the
of a datagram, but there are several technical reasons to
encapsulation
- There are unsolved security problems associated with the use
the IP source routing options
- Current Internet routers exhibit performance problems
forwarding datagrams that contain IP options, including the
source routing options
- Many current Internet nodes process IP source routing
incorrectly
- Firewalls may exclude IP source-routed datagrams
- Insertion of an IP source route option may complicate
processing of authentication information by the source and/
destination of a datagram, depending on how the authentication
specified to be performed
- It is considered impolite for intermediate routers to
modifications to datagrams which they did not originate
These technical advantages must be weighed against the
posed by the use of encapsulation
- Encapsulated datagrams typically are larger than source
datagrams
Perkins Standards Track [Page 2]
RFC 2003 IP-within-IP October 1996
- Encapsulation cannot be used unless it is known in advance
the node at the tunnel exit point can decapsulate the datagram
Since the majority of Internet nodes today do not perform well
IP loose source route options are used, the second
disadvantage of encapsulation is not as serious as it might seem
first
3. IP in IP
To encapsulate an IP datagram using IP in IP encapsulation, an
IP header [10] is inserted before the datagram's existing IP header
as follows
+---------------------------+
| |
| Outer IP Header |
| |
+---------------------------+ +---------------------------+
| | | |
| IP Header | | IP Header |
| | | |
+---------------------------+ ====> +---------------------------+
| | | |
| | | |
| IP Payload | | IP Payload |
| | | |
| | | |
+---------------------------+ +---------------------------+
The outer IP header Source Address and Destination Address
the "endpoints" of the tunnel. The inner IP header Source
and Destination Addresses identify the original sender and
of the datagram, respectively. The inner IP header is not changed
the encapsulator, except to decrement the TTL as noted below,
remains unchanged during its delivery to the tunnel exit point.
change to IP options in the inner header occurs during delivery
the encapsulated datagram through the tunnel. If need be,
protocol headers such as the IP Authentication header [1] may
inserted between the outer IP header and the inner IP header.
that the security options of the inner IP header MAY affect
choice of security options for the encapsulating (outer) IP header
Perkins Standards Track [Page 3]
RFC 2003 IP-within-IP October 1996
3.1. IP Header Fields and
The fields in the outer IP header are set by the encapsulator
follows
4
The Internet Header Length (IHL) is the length of the outer
header measured in 32-bit words [10].
The Type of Service (TOS) is copied from the inner IP header
Total
The Total Length measures the length of the entire
IP datagram, including the outer IP header, the inner
header, and its payload
Identification, Flags, Fragment
These three fields are set as specified in [10]. However,
the "Don't Fragment" bit is set in the inner IP header, it
be set in the outer IP header; if the "Don't Fragment" bit
not set in the inner IP header, it MAY be set in the outer
header, as described in Section 5.1.
Time to
The Time To Live (TTL) field in the outer IP header is set to
value appropriate for delivery of the encapsulated datagram
the tunnel exit point
4
Header
The Internet Header checksum [10] of the outer IP header
Perkins Standards Track [Page 4]
RFC 2003 IP-within-IP October 1996
Source
The IP address of the encapsulator, that is, the tunnel
point
Destination
The IP address of the decapsulator, that is, the tunnel
point
Any options present in the inner IP header are in general
copied to the outer IP header. However, new options
to the tunnel path MAY be added. In particular, any
types of security options of the inner IP header MAY affect
choice of security options for the outer header. It is
expected that there be a one-to-one mapping of such options
the options or security headers selected for the tunnel
When encapsulating a datagram, the TTL in the inner IP header
decremented by one if the tunneling is being done as part
forwarding the datagram; otherwise, the inner header TTL is
changed during encapsulation. If the resulting TTL in the inner
header is 0, the datagram is discarded and an ICMP Time
message SHOULD be returned to the sender. An encapsulator MUST
encapsulate a datagram with TTL = 0.
The TTL in the inner IP header is not changed when decapsulating
If, after decapsulation, the inner datagram has TTL = 0,
decapsulator MUST discard the datagram. If, after decapsulation,
decapsulator forwards the datagram to one of its network interfaces
it will decrement the TTL as a result of doing normal IP forwarding
See also Section 4.4.
The encapsulator may use any existing IP mechanisms appropriate
delivery of the encapsulated payload to the tunnel exit point.
particular, use of IP options is allowed, and use of fragmentation
allowed unless the "Don't Fragment" bit is set in the inner
header. This restriction on fragmentation is required so that
employing Path MTU Discovery [7] can obtain the information
seek
3.2. Routing
Routing loops within a tunnel are particularly dangerous when
cause datagrams to arrive again at the encapsulator. Suppose
datagram arrives at a router for forwarding, and the
Perkins Standards Track [Page 5]
RFC 2003 IP-within-IP October 1996
determines that the datagram has to be encapsulated before
delivery. Then
- If the IP Source Address of the datagram matches the router's
IP address on any of its network interfaces, the router MUST
tunnel the datagram; instead, the datagram SHOULD be discarded
- If the IP Source Address of the datagram matches the IP
of the tunnel destination (the tunnel exit point is
chosen by the router based on the Destination Address in
datagram's IP header), the router MUST NOT tunnel the datagram
instead, the datagram SHOULD be discarded
See also Section 4.4.
4. ICMP Messages from within the
After an encapsulated datagram has been sent, the encapsulator
receive an ICMP [9] message from any intermediate router within
tunnel other than the tunnel exit point. The action taken by
encapsulator depends on the type of ICMP message received. When
received message contains enough information, the encapsulator
use the incoming message to create a similar ICMP message, to be
to the originator of the original unencapsulated IP datagram (
original sender). This process will be referred to as "relaying"
ICMP message from the tunnel
ICMP messages indicating an error in processing a datagram include
copy of (a portion of) the datagram causing the error. Relaying
ICMP message requires that the encapsulator strip off the outer
header from this returned copy of the original datagram. For
in which the received ICMP message does not contain enough data
relay the message, see Section 5.
4.1. Destination Unreachable (Type 3)
ICMP Destination Unreachable messages are handled by the
depending upon their Code field. The model suggested here allows
tunnel to "extend" a network to include non-local (e.g., mobile
nodes. Thus, if the original destination in the
datagram is on the same network as the encapsulator,
Destination Unreachable Code values may be modified to conform to
suggested model
Perkins Standards Track [Page 6]
RFC 2003 IP-within-IP October 1996
Network Unreachable (Code 0)
An ICMP Destination Unreachable message SHOULD be
to the original sender. If the original destination
the unencapsulated datagram is on the same network as
encapsulator, the newly generated Destination
message sent by the encapsulator MAY have Code 1 (
Unreachable), since presumably the datagram arrived at
correct network and the encapsulator is trying to create
appearance that the original destination is local to
network even if it is not. Otherwise, if the
returns a Destination Unreachable message, the Code field
be set to 0 (Network Unreachable).
Host Unreachable (Code 1)
The encapsulator SHOULD relay Host Unreachable messages to
sender of the original unencapsulated datagram, if possible
Protocol Unreachable (Code 2)
When the encapsulator receives an ICMP Protocol
message, it SHOULD send a Destination Unreachable message
Code 0 or 1 (see the discussion for Code 0) to the sender
the original unencapsulated datagram. Since the
sender did not use protocol 4 in sending the datagram, it
be meaningless to return Code 2 to that sender
Port Unreachable (Code 3)
This Code should never be received by the encapsulator,
the outer IP header does not refer to any port number. It
NOT be relayed to the sender of the original
datagram
Datagram Too Big (Code 4)
The encapsulator MUST relay ICMP Datagram Too Big messages
the sender of the original unencapsulated datagram
Source Route Failed (Code 5)
This Code SHOULD be handled by the encapsulator itself
It MUST NOT be relayed to the sender of the
unencapsulated datagram
Perkins Standards Track [Page 7]
RFC 2003 IP-within-IP October 1996
4.2. Source Quench (Type 4)
The encapsulator SHOULD NOT relay ICMP Source Quench messages to
sender of the original unencapsulated datagram, but instead
activate whatever congestion control mechanisms it implements to
alleviate the congestion detected within the tunnel
4.3. Redirect (Type 5)
The encapsulator MAY handle the ICMP Redirect messages itself.
MUST NOT not relay the Redirect to the sender of the
unencapsulated datagram
4.4. Time Exceeded (Type 11)
ICMP Time Exceeded messages report (presumed) routing loops
the tunnel itself. Reception of Time Exceeded messages by
encapsulator MUST be reported to the sender of the
unencapsulated datagram as Host Unreachable (Type 3, Code 1).
Unreachable is preferable to Network Unreachable; since the
was handled by the encapsulator, and the encapsulator is
considered to be on the same network as the destination address
the original unencapsulated datagram, then the datagram is
to have reached the correct network, but not the correct
node within that network
4.5. Parameter Problem (Type 12)
If the Parameter Problem message points to a field copied from
original unencapsulated datagram, the encapsulator MAY relay the
message to the sender of the original unencapsulated datagram
otherwise, if the problem occurs with an IP option inserted by
encapsulator, then the encapsulator MUST NOT relay the ICMP
to the original sender. Note that an encapsulator
prevalent current practice will never insert any IP options into
encapsulated datagram, except possibly for security reasons
4.6. Other ICMP
Other ICMP messages are not related to the encapsulation
described within this protocol specification, and should be acted
by the encapsulator as specified in [9].
Perkins Standards Track [Page 8]
RFC 2003 IP-within-IP October 1996
5. Tunnel
Unfortunately, ICMP only requires IP routers to return 8 octets (64
bits) of the datagram beyond the IP header. This is not enough
include a copy of the encapsulated (inner) IP header, so it is
always possible for the encapsulator to relay the ICMP message
the interior of a tunnel back to the original sender. However,
carefully maintaining "soft state" about tunnels into which it sends
the encapsulator can return accurate ICMP messages to the
sender in most cases. The encapsulator SHOULD maintain at least
following soft state information about each tunnel
- MTU of the tunnel (Section 5.1)
- TTL (path length) of the
- Reachability of the end of the
The encapsulator uses the ICMP messages it receives from the
of a tunnel to update the soft state information for that tunnel
ICMP errors that could be received from one of the routers along
tunnel interior include
- Datagram Too
- Time
- Destination
- Source
When subsequent datagrams arrive that would transit the tunnel,
encapsulator checks the soft state for the tunnel. If the
would violate the state of the tunnel (for example, the TTL of
new datagram is less than the tunnel "soft state" TTL)
encapsulator sends an ICMP error message back to the sender of
original datagram, but also encapsulates the datagram and forwards
into the tunnel
Using this technique, the ICMP error messages sent by
encapsulator will not always match up one-to-one with
encountered within the tunnel, but they will accurately reflect
state of the network
Tunnel soft state was originally developed for the IP
Encapsulation (IPAE) specification [4].
5.1. Tunnel MTU
When the Don't Fragment bit is set by the originator and copied
the outer IP header, the proper MTU of the tunnel will be
from ICMP Datagram Too Big (Type 3, Code 4) messages reported to
encapsulator. To support sending nodes which use Path MTU Discovery
Perkins Standards Track [Page 9]
RFC 2003 IP-within-IP October 1996
all encapsulator implementations MUST support Path MTU Discovery [5,
7] soft state within their tunnels. In this particular application
there are several advantages
- As a benefit of Path MTU Discovery within the tunnel,
fragmentation which occurs because of the size of
encapsulation header is performed only once after encapsulation
This prevents multiple fragmentation of a single datagram,
improves processing efficiency of the decapsulator and
routers within the tunnel
- If the source of the unencapsulated datagram is doing Path
Discovery, then it is desirable for the encapsulator to
the MTU of the tunnel. Any ICMP Datagram Too Big messages
within the tunnel are returned to the encapsulator, and as
in Section 5, it is not always possible for the encapsulator
relay ICMP messages to the source of the original
datagram. By maintaining "soft state" about the MTU of
tunnel, the encapsulator can return correct ICMP Datagram Too
messages to the original sender of the unencapsulated datagram
support its own Path MTU Discovery. In this case, the MTU
is conveyed to the original sender by the encapsulator
be the MTU of the tunnel minus the size of the
IP header. This will avoid fragmentation of the original
datagram by the encapsulator
- If the source of the original unencapsulated datagram
not doing Path MTU Discovery, it is still desirable for
encapsulator to know the MTU of the tunnel. In particular, it
much better to fragment the original datagram when encapsulating
than to allow the encapsulated datagram to be fragmented
Fragmenting the original datagram can be done by the
without special buffer requirements and without the need
keep reassembly state in the decapsulator. By contrast,
the encapsulated datagram is fragmented, then the
must reassemble the fragmented (encapsulated) datagram
decapsulating it, requiring reassembly state and buffer
within the decapsulator
Thus, the encapsulator SHOULD normally do Path MTU Discovery
requiring it to send all datagrams into the tunnel with the "Don'
Fragment" bit set in the outer IP header. However there are
with this approach. When the original sender sets the "Don'
Fragment" bit, the sender can react quickly to any returned
Datagram Too Big error message by retransmitting the
datagram. On the other hand, suppose that the encapsulator
an ICMP Datagram Too Big message from within the tunnel. In
case, if the original sender of the unencapsulated datagram had
Perkins Standards Track [Page 10]
RFC 2003 IP-within-IP October 1996
set the "Don't Fragment" bit, there is nothing sensible that
encapsulator can do to let the original sender know of the error
The encapsulator MAY keep a copy of the sent datagram whenever
tries increasing the tunnel MTU, in order to allow it to fragment
resend the datagram if it gets a Datagram Too Big response
Alternatively the encapsulator MAY be configured for certain types
datagrams not to set the "Don't Fragment" bit when the
sender of the unencapsulated datagram has not set the "Don'
Fragment" bit
5.2.
An encapsulator might receive indications of congestion from
tunnel, for example, by receiving ICMP Source Quench messages
nodes within the tunnel. In addition, certain link layers
various protocols not related to the Internet suite of
might provide such indications in the form of a
Experienced [6] flag. The encapsulator SHOULD reflect conditions
congestion in its "soft state" for the tunnel, and when
forwarding datagrams into the tunnel, the encapsulator SHOULD
appropriate means for controlling congestion [3]; However,
encapsulator SHOULD NOT send ICMP Source Quench messages to
original sender of the unencapsulated datagram
6. Security
IP encapsulation potentially reduces the security of the Internet
and care needs to be taken in the implementation and deployment of
encapsulation. For example, IP encapsulation makes it difficult
border routers to filter datagrams based on header fields.
particular, the original values of the Source Address,
Address, and Protocol fields in the IP header, and the port
used in any transport header within the datagram, are not located
their normal positions within the datagram after encapsulation
Since any IP datagram can be encapsulated and passed through
tunnel, such filtering border routers need to carefully examine
datagrams
6.1. Router
Routers need to be aware of IP encapsulation protocols in order
correctly filter incoming datagrams. It is desirable that
filtering be integrated with IP authentication [1]. Where
authentication is used, encapsulated packets might be allowed
enter an organization when the encapsulating (outer) packet or
encapsulated (inner) packet is sent by an authenticated,
source. Encapuslated packets containing no such
represent a potentially large security risk
Perkins Standards Track [Page 11]
RFC 2003 IP-within-IP October 1996
IP datagrams which are encapsulated and encrypted [2] might also
a problem for filtering routers. In this case, the router can
the datagram only if it shares the security association used for
encryption. To allow this sort of encryption in environments
which all packets need to be filtered (or at least accounted for),
mechanism must be in place for the receiving node to
communicate the security association to the border router.
might, more rarely, also apply to the security association used
outgoing datagrams
6.2. Host
Host implementations that are capable of receiving encapsulated
datagrams SHOULD admit only those datagrams fitting into one or
of the following categories
- The protocol is harmless: source address-based authentication
not needed
- The encapsulating (outer) datagram comes from an
identified, trusted source. The authenticity of the source
be established by relying on physical security in addition
border router configuration, but is more likely to come from
of the IP Authentication header [1].
- The encapuslated (inner) datagram includes an IP
header
- The encapsulated (inner) datagram is addressed to a
interface belonging to the decapsulator, or to a node with
the decapsulator has entered into a special relationship
delivering such encapsulated datagrams
Some or all of this checking could be done in border routers
than the receiving node, but it is better if border router checks
used as backup, rather than being the only check
Perkins Standards Track [Page 12]
RFC 2003 IP-within-IP October 1996
7.
Parts of Sections 3 and 5 of this document were taken from
(authored by Bill Simpson) of earlier versions of the Mobile
Internet Draft [8]. The original text for section 6 (
Considerations) was contributed by Bob Smart. Good ideas have
been included from RFC 1853 [11], also authored by Bill Simpson
Thanks also to Anders Klemets for finding mistakes and
improvements to the draft. Finally, thanks to David Johnson
going over the draft with a fine-toothed comb, finding mistakes
improving consistency, and making many other improvements to
draft
[1] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[2] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
August 1995.
[3] Baker, F., Editor, "Requirements for IP Version 4 Routers",
1812, June 1995.
[4] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: The
Interoperability and Transition Mechanism", Work in Progress
[5] Knowles, S., "IESG Advice from Experience with Path
Discovery", RFC 1435, March 1993.
[6] Mankin, A., and K. Ramakrishnan, "Gateway Congestion
Survey", RFC 1254, August 1991.
[7] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[8] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[9] Postel, J., Editor, "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[10] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791,
September 1981.
[11] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995.
Perkins Standards Track [Page 13]
RFC 2003 IP-within-IP October 1996
Author's
Questions about this memo can be directed to
Charles
Room H3-D34
T. J. Watson Research
IBM
30 Saw Mill River Rd
Hawthorne, NY 10532
Work: +1-914-784-7350
Fax: +1-914-784-6205
EMail: perk@watson.ibm.
The working group can be contacted via the current chair
Jim
Motorola, Inc
1301 E. Algonquin Rd
Schaumburg, IL 60196
Work: +1-847-576-2753
EMail: solomon@comm.mot.
Perkins Standards Track [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
