As per Relevance of the word encapsulation, we have this rfc below:
Network Working Group W.
Request for Comments: 1853
Category: Informational October 1995
IP in IP
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
IESG Note
Note that this memo is an individual effort of the author.
document reflects a current informal practice in the internet.
is an effort underway within the IETF Mobile-IP Working Group
provide an appropriate proposed standard to address this issue
This document discusses implementation techniques for using
Protocol/Payload number 4 Encapsulation for tunneling with
Security and other protocols
Table of
1. Introduction .......................................... 2
2. Encapsulation ......................................... 3
3. Tunnel Management ..................................... 5
3.1 Tunnel MTU Discovery ............................ 5
3.2 Congestion ...................................... 6
3.3 Routing Failures ................................ 6
3.4 Other ICMP Messages ............................. 6
SECURITY CONSIDERATIONS ...................................... 7
REFERENCES ................................................... 7
ACKNOWLEDGEMENTS ............................................. 8
AUTHOR'S ADDRESS ............................................. 8
Simpson Informational [Page 1]
RFC 1853 IP Tunnelling October 1995
1.
The IP in IP encapsulation Protocol/Payload number 4 [RFC-1700]
long been used to bridge portions of the Internet which have
capabilities or policies. This document describes
techniques used for many years by the Amateur Packet Radio
for joining a large mobile network, and also by early
of IP Security protocols
Use of IP in IP encapsulation differs from later tunneling
(for example, protocol numbers 98 [RFC-1241], 94 [IDM91a], 53
[swIPe], and 47 [RFC-1701]) in that it does not insert its
special glue header between IP headers. Instead, the
unadorned IP Header is retained, and simply wrapped in
standard IP header
This information applies principally to encapsulation of IP
4. Other IP versions will be described in separate documents
Simpson Informational [Page 2]
RFC 1853 IP Tunnelling October 1995
2.
The encapsulation technique is fairly simple. An outer IP header
added before the original IP header. Between them are any
headers for the path, such as security headers specific to the
configuration
The outer IP header Source and Destination identify the "endpoints
of the tunnel. The inner IP header Source and Destination
the original sender and recipient of the datagram
Each header chains to the next using IP Protocol values [RFC-1700].
+---------------------------+
| Outer IP Header |
+---------------------------+
| Tunnel Headers |
+---------------------------+ +---------------------------+
| IP Header | | Inner IP Header |
+---------------------------+ ====> +---------------------------+
| | | |
| IP Payload | | IP Payload |
| | | |
+---------------------------+ +---------------------------+
The format of IP headers is described in [RFC-791].
Type Of Service copied from the inner IP header. Optionally
another TOS may be used between cooperating peers
This is in keeping with the transparency
that if the user was expecting a given level
service, then the tunnel should provide the
service. However, some tunnels may be
specifically to provide a different level of
as a matter of policy
Identification A new number is generated for each outer IP header
The encapsulated datagram may have already
fragmented, and another level of fragmentation
occur due to the tunnel encapsulation. These
fragments will be reassembled by the decapsulator
rather than the final destination
ignored (set to zero).
Simpson Informational [Page 3]
RFC 1853 IP Tunnelling October 1995
This unofficial flag has seen experimental use,
while it remains in the inner IP header, does
affect the tunnel
Don't Fragment copied from the inner IP header. This allows
originator to control the level of
tradeoffs. See "Tunnel MTU Discovery".
More Fragments set as required when fragmenting
The flag is not copied for the same reason that
separate Identification is used
Time To Live the default value specified in the most
"Assigned Numbers" [RFC-1700]. This ensures
long unanticipated tunnels do not interrupt the
of datagrams between endpoints
The inner TTL is decremented once
encapsulation, and is not affected by decapsulation
Protocol the next header; 4 for the inner IP header, when
intervening tunnel headers are in use
Source an IP address associated with the interface used
send the datagram
Destination an IP address of the tunnel decapsulator
Options not copied from the inner IP header. However,
options particular to the path MAY be added
Timestamp, Loose Source Route, Strict Source Route
and Record Route are deliberately hidden within
tunnel. Often, tunnels are constructed to
the inadequacies of these options
Any supported flavors of security options of
inner IP header MAY affect the choice of
options for the tunnel. It is not expected
there be a one-to-one mapping of such options to
options or security headers selected for the tunnel
Simpson Informational [Page 4]
RFC 1853 IP Tunnelling October 1995
3. Tunnel
It is possible that one of the routers along the tunnel
might encounter an error while processing the datagram, causing it
return an ICMP [RFC-792] error message to the encapsulator at the
Source of the tunnel. Unfortunately, ICMP only requires IP
to return 8 bytes (64 bits) of the datagram beyond the IP header
This is not enough to include the entire encapsulated header. Thus
it is not generally possible for an encapsulating router
immediately reflect an ICMP message from the interior of a
back to the originating host
However, by carefully maintaining "soft state" about its tunnels,
encapsulator can return accurate ICMP messages in most cases.
router SHOULD maintain at least the following soft state
about each tunnel
- Reachability of the end of the tunnel
- Congestion of the tunnel
- MTU of the tunnel
The router uses the ICMP messages it receives from the interior of
tunnel to update the soft state information for that tunnel.
subsequent datagrams arrive that would transit the tunnel, the
checks the soft state for the tunnel. If the datagram would
the state of the tunnel (such as the MTU is greater than the
MTU when Don't Fragment is set), the router sends an appropriate
error message back to the originator, but also forwards the
into the tunnel. Forwarding the datagram despite returning the
message ensures that changes in tunnel state will be learned
Using this technique, the ICMP error messages from
routers will not always match one-to-one with errors
within the tunnel, but they will accurately reflect the state of
network
3.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 (Type 3 Code 4) "Datagram Too Big" errors reported to
encapsulator. To support originating hosts which use
capability, all implementations MUST support Path MTU
[RFC-1191, RFC-1435] within their tunnels
Simpson Informational [Page 5]
RFC 1853 IP Tunnelling October 1995
As a benefit of Tunnel MTU Discovery, any fragmentation which
because of the size of the encapsulation header is done only
after encapsulation. This prevents more than one fragmentation of
single datagram, which improves processing efficiency of the
routers and tunnel decapsulator
3.2.
Tunnel soft state will collect indications of congestion, such as
ICMP (Type 4) Source Quench in datagrams from the
(tunnel peer). When forwarding another datagram into the tunnel
it is appropriate to send Source Quench messages to the originator
3.3. Routing
Because the TTL is reset each time that a datagram is encapsulated
routing loops within a tunnel are particularly dangerous when
arrive again at the encapsulator. If the IP Source matches any
its interfaces, an implementation MUST NOT further encapsulate
Instead, the datagram is forwarded normally
ICMP (Type 11) Time Exceeded messages report routing loops within
tunnel itself. ICMP (Type 3) Destination Unreachable messages
delivery failures to the decapsulator. This soft state MUST
reported to the originator as (Type 3 Code 0) Network Unreachable
3.4. Other ICMP
Most ICMP error messages are not relevant to the use of the tunnel
In particular, parameter problems are likely to be a result
misconfiguration of the encapsulator, and MUST NOT be reported to
originator
Simpson Informational [Page 6]
RFC 1853 IP Tunnelling October 1995
Security
Security issues are briefly discussed in this memo. The use
tunneling may obviate some older IP security options (labelling),
will better support newer IP Security headers
[IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-
protocols for mobile internetworking", Proceedings
SIGCOMM '91, ACM, September 1991.
[RFC-791]
Postel, J., "Internet Protocol", STD 5, RFC 791,
USC/Information Sciences Institute, September 1981.
[RFC-792]
Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, USC/Information Sciences Institute,
1981.
[RFC-1191]
Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
DECWRL, Stanford University, November 1990.
[RFC-1241]
Mills, D., and R. Woodburn, "A Scheme for an
Encapsulation Protocol: Version 1", UDEL, July 1991.
[RFC-1435]
Knowles, S., "IESG Advice from Experience with Path
Discovery", RFC 1435, FTP Software, March 1993.
[RFC-1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
1700, USC/Information Sciences Institute, October 1994.
[RFC-1701]
Hanks, S., Li, T., Farinacci, D., and P. Traina, "
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[swIPe] Ioannidis, J., and Blaze, M., "The Architecture
Implementation of Network-Layer Security Under Unix",
Usenix Security Symposium Proceedings, October 1993.
Simpson Informational [Page 7]
RFC 1853 IP Tunnelling October 1995
These implementation details of IP Tunneling are derived in
part from independent work in 1990 by Phil Karn and the TCP-
hams using KA9Q NOS
Special thanks to John Ioannidis (then of Columbia University)
inspiration and experimentation which began this most recent round
IP Mobility and IP Security development. Some of this text
derived from [IDM91a] and [swIPe].
The chaining of headers was also described in "Simple
Protocol", by Steve Deering (Xerox PARC).
The overall organization and some of this text was derived
[RFC-1241], by David Mills (U Delaware) and Robert Woodburn (SAIC).
Some of the text on tunnel soft state was derived from "IP
Encapsulation (IPAE)", by Robert E. Gilligan, Erik Nordmark, and
Hinden (all of Sun Microsystems).
Author's
Questions about this memo can also be directed to
William Allen
Computer Systems Consulting
1384
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.
bsimpson@MorningStar.
Simpson Informational [Page 8]
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
