IP in IP Tunneling
Carrying one IP packet inside another so it can cross a network that could not take it.
Simpson, W., "IP in IP Tunneling", RFC 1853, DOI 10.17487/RFC1853, October 1995, <https://www.rfc-editor.org/info/rfc1853>.
@misc{rfc1853,
series = {Request for Comments},
number = 1853,
howpublished = {RFC 1853},
publisher = {RFC Editor},
doi = {10.17487/RFC1853},
url = {https://www.rfc-editor.org/info/rfc1853},
author = {W. Simpson},
title = {{IP in IP Tunneling}},
pagetotal = 8,
year = 1995,
month = oct,
} RFC text
Contents
Network Working Group W. Simpson
Request for Comments: 1853 Daydreamer
Category: Informational October 1995
IP in IP Tunneling
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
IESG Note:
Note that this memo is an individual effort of the author. This
document reflects a current informal practice in the internet. There
is an effort underway within the IETF Mobile-IP Working Group to
provide an appropriate proposed standard to address this issue.
Abstract
This document discusses implementation techniques for using IP
Protocol/Payload number 4 Encapsulation for tunneling with IP
Security and other protocols.
Table of Contents
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
1. Introduction
The IP in IP encapsulation Protocol/Payload number 4 [RFC-1700] has
long been used to bridge portions of the Internet which have disjoint
capabilities or policies. This document describes implementation
techniques used for many years by the Amateur Packet Radio network
for joining a large mobile network, and also by early implementations
of IP Security protocols.
Use of IP in IP encapsulation differs from later tunneling techniques
(for example, protocol numbers 98 [RFC-1241], 94 [IDM91a], 53
[swIPe], and 47 [RFC-1701]) in that it does not insert its own
special glue header between IP headers. Instead, the original
unadorned IP Header is retained, and simply wrapped in another
standard IP header.
This information applies principally to encapsulation of IP version
4. Other IP versions will be described in separate documents.
2. Encapsulation
The encapsulation technique is fairly simple. An outer IP header is
added before the original IP header. Between them are any other
headers for the path, such as security headers specific to the tunnel
configuration.
The outer IP header Source and Destination identify the "endpoints"
of the tunnel. The inner IP header Source and Destination identify
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 principle
that if the user was expecting a given level of
service, then the tunnel should provide the same
service. However, some tunnels may be constructed
specifically to provide a different level of service
as a matter of policy.
Identification A new number is generated for each outer IP header.
The encapsulated datagram may have already been
fragmented, and another level of fragmentation may
occur due to the tunnel encapsulation. These tunnel
fragments will be reassembled by the decapsulator,
rather than the final destination.
Reserved
ignored (set to zero).
This unofficial flag has seen experimental use, and
while it remains in the inner IP header, does not
affect the tunnel.
Don't Fragment copied from the inner IP header. This allows the
originator to control the level of performance
tradeoffs. See "Tunnel MTU Discovery".
More Fragments set as required when fragmenting.
The flag is not copied for the same reason that a
separate Identification is used.
Time To Live the default value specified in the most recent
"Assigned Numbers" [RFC-1700]. This ensures that
long unanticipated tunnels do not interrupt the flow
of datagrams between endpoints.
The inner TTL is decremented once before
encapsulation, and is not affected by decapsulation.
Protocol the next header; 4 for the inner IP header, when no
intervening tunnel headers are in use.
Source an IP address associated with the interface used to
send the datagram.
Destination an IP address of the tunnel decapsulator.
Options not copied from the inner IP header. However, new
options particular to the path MAY be added.
Timestamp, Loose Source Route, Strict Source Route,
and Record Route are deliberately hidden within the
tunnel. Often, tunnels are constructed to overcome
the inadequacies of these options.
Any supported flavors of security options of the
inner IP header MAY affect the choice of security
options for the tunnel. It is not expected that
there be a one-to-one mapping of such options to the
options or security headers selected for the tunnel.
3. Tunnel Management
It is possible that one of the routers along the tunnel interior
might encounter an error while processing the datagram, causing it to
return an ICMP [RFC-792] error message to the encapsulator at the IP
Source of the tunnel. Unfortunately, ICMP only requires IP routers
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 to
immediately reflect an ICMP message from the interior of a tunnel
back to the originating host.
However, by carefully maintaining "soft state" about its tunnels, the
encapsulator can return accurate ICMP messages in most cases. The
router SHOULD maintain at least the following soft state information
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 a
tunnel to update the soft state information for that tunnel. When
subsequent datagrams arrive that would transit the tunnel, the router
checks the soft state for the tunnel. If the datagram would violate
the state of the tunnel (such as the MTU is greater than the tunnel
MTU when Don't Fragment is set), the router sends an appropriate ICMP
error message back to the originator, but also forwards the datagram
into the tunnel. Forwarding the datagram despite returning the error
message ensures that changes in tunnel state will be learned.
Using this technique, the ICMP error messages from encapsulating
routers will not always match one-to-one with errors encountered
within the tunnel, but they will accurately reflect the state of the
network.
3.1. Tunnel MTU Discovery
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
from ICMP (Type 3 Code 4) "Datagram Too Big" errors reported to the
encapsulator. To support originating hosts which use this
capability, all implementations MUST support Path MTU Discovery
[RFC-1191, RFC-1435] within their tunnels.
As a benefit of Tunnel MTU Discovery, any fragmentation which occurs
because of the size of the encapsulation header is done only once
after encapsulation. This prevents more than one fragmentation of a
single datagram, which improves processing efficiency of the path
routers and tunnel decapsulator.
3.2. Congestion
Tunnel soft state will collect indications of congestion, such as an
ICMP (Type 4) Source Quench in datagrams from the decapsulator
(tunnel peer). When forwarding another datagram into the tunnel,
it is appropriate to send Source Quench messages to the originator.
3.3. Routing Failures
Because the TTL is reset each time that a datagram is encapsulated,
routing loops within a tunnel are particularly dangerous when they
arrive again at the encapsulator. If the IP Source matches any of
its interfaces, an implementation MUST NOT further encapsulate.
Instead, the datagram is forwarded normally.
ICMP (Type 11) Time Exceeded messages report routing loops within the
tunnel itself. ICMP (Type 3) Destination Unreachable messages report
delivery failures to the decapsulator. This soft state MUST be
reported to the originator as (Type 3 Code 0) Network Unreachable.
3.4. Other ICMP Messages
Most ICMP error messages are not relevant to the use of the tunnel.
In particular, parameter problems are likely to be a result of
misconfiguration of the encapsulator, and MUST NOT be reported to the
originator.
Security Considerations
Security issues are briefly discussed in this memo. The use of
tunneling may obviate some older IP security options (labelling), but
will better support newer IP Security headers.
References
[IDM91a] Ioannidis, J., Duchamp, D., Maguire, G., "IP-based
protocols for mobile internetworking", Proceedings of
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, September
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 Internet
Encapsulation Protocol: Version 1", UDEL, July 1991.
[RFC-1435]
Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, FTP Software, March 1993.
[RFC-1700]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/Information Sciences Institute, October 1994.
[RFC-1701]
Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[swIPe] Ioannidis, J., and Blaze, M., "The Architecture and
Implementation of Network-Layer Security Under Unix", Fourth
Usenix Security Symposium Proceedings, October 1993.
Acknowledgements
These implementation details of IP Tunneling are derived in large
part from independent work in 1990 by Phil Karn and the TCP-Group
hams using KA9Q NOS.
Special thanks to John Ioannidis (then of Columbia University) for
inspiration and experimentation which began this most recent round of
IP Mobility and IP Security development. Some of this text was
derived from [IDM91a] and [swIPe].
The chaining of headers was also described in "Simple Internet
Protocol", by Steve Deering (Xerox PARC).
The overall organization and some of this text was derived from
[RFC-1241], by David Mills (U Delaware) and Robert Woodburn (SAIC).
Some of the text on tunnel soft state was derived from "IP Address
Encapsulation (IPAE)", by Robert E. Gilligan, Erik Nordmark, and Bob
Hinden (all of Sun Microsystems).
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
ISO Plain Language
On this page
§1Introduction
IP in IP encapsulation, IP protocol number 4, has long been used to bridge parts of the Internet that have different capabilities or policies. This memo describes implementation techniques used for many years by the Amateur Packet Radio network for joining a large mobile network, and also by early implementations of IP Security protocols.
IP in IP differs from later tunneling techniques, such as protocol numbers 98, 94, 53 and 47, because it does not insert a special header of its own between the two IP headers. The original, unadorned IP header is kept and simply wrapped in another standard IP header. The information here applies principally to encapsulation of IP version 4; other IP versions are described in separate documents.
This memo describes a way to send a packet across a network that would not normally carry it. The packet keeps its own address information, and a second header carries it across.
§2Encapsulation and the Outer Header
The technique is simple. An outer IP header is added before the original IP header, and between the two there may be other headers for the path, such as security headers specific to the tunnel configuration. The outer header's source and destination identify the endpoints of the tunnel, the two routers that carry the traffic. The inner header's source and destination identify the original sender and recipient. Each header chains to the next using IP protocol values, and the outer header uses 4 when the inner header is IP and no other tunnel headers are in use.
The outer header's fields are set by rules. Type of Service is copied from the inner header, or another value may be used between cooperating peers, so that a tunnel does not silently change the service level the user asked for; the memo calls this the transparency principle. The Identification field gets a new number for each outer header, because the encapsulated datagram may already have been fragmented and the tunnel may fragment it again, and the tunnel fragments are reassembled by the decapsulator rather than the final destination. The Reserved field is ignored and set to zero. The Don't Fragment flag is copied from the inner header, which lets the originator control the trade-off between performance and fragmentation. The More Fragments flag is set as required when fragmenting and is not copied, for the same reason a separate Identification is used.
Time To Live in the outer header takes the default value from the most recent Assigned Numbers document, so that a long tunnel that was not anticipated does not interrupt the flow of datagrams between the endpoints. The inner time to live is decremented once before encapsulation and is not affected by decapsulation. The outer Source is an IP address associated with the interface used to send the datagram, and the outer Destination is the address of the tunnel decapsulator. Options are not copied from the inner header, though new options for the path may be added. Timestamp, Loose Source Route, Strict Source Route and Record Route are deliberately hidden inside the tunnel, and tunnels are often built to overcome the inadequacies of those options.
Each field in the outer header is set in a fixed way. Some fields are copied from the original header, some get a fresh value, and the source and destination name the two ends of the tunnel.
+---------------------------+
| Outer IP Header |
+---------------------------+
| Tunnel Headers |
+---------------------------+
| Inner IP Header |
+---------------------------+
| IP Payload |
+---------------------------+§3Tunnel Management and Soft State
One of the routers inside the tunnel may hit an error while processing a datagram and send an ICMP error back to the encapsulator, the router where the tunnel begins. ICMP only requires routers to return 8 bytes, 64 bits, of the datagram beyond the IP header, which is not enough to include the whole encapsulated header. So the encapsulator generally cannot pass an ICMP message from inside the tunnel straight back to the host that sent the datagram.
The way round this is to keep soft state about each tunnel. The memo says a router should maintain at least three things: whether the end of the tunnel is reachable, whether the tunnel is congested, and the maximum transmission unit of the tunnel. ICMP messages arriving from inside the tunnel update that state. When a later datagram would break the tunnel's state, for example because its size exceeds the tunnel's maximum transmission unit while the Don't Fragment flag is set, the router sends the matching ICMP error to the originator but also forwards the datagram into the tunnel. Forwarding the datagram anyway is what lets the router learn that the tunnel state has changed.
The result is that ICMP messages from the encapsulating router do not match one for one with errors inside the tunnel, but they do reflect the state of the network accurately. Most ICMP error messages are not relevant to a tunnel. Parameter problems in particular are likely to come from a misconfigured encapsulator and must not be reported to the originator.
Errors inside a tunnel cannot be passed straight back to the original sender, because the error message carries too little of the packet. So the router at the tunnel entrance keeps a record of the tunnel's health and sends its own error message based on that record.
- DATAGRAM
- DATAGRAM IN THE OUTER HEADER
- ICMP ERROROnly 8 bytes of the datagram beyond the IP header come back.
- ICMP ERROR FROM THE TUNNEL'S SOFT STATEThe datagram is forwarded into the tunnel anyway, so the state stays current.
§3.1Tunnel MTU Discovery
When the originator sets the Don't Fragment bit and it is copied into the outer IP header, the proper maximum transmission unit of the tunnel is learned from ICMP Type 3 Code 4, Datagram Too Big, errors reported to the encapsulator. To support originating hosts that use this capability, all implementations must support Path MTU Discovery within their tunnels.
The method has a second benefit. Any fragmentation caused by the size of the encapsulation header is done only once, after encapsulation. This prevents a single datagram from being fragmented more than once, which improves the processing efficiency of the routers on the path and of the tunnel decapsulator.
The tunnel learns its size limit from the same kind of error message that ordinary IP uses. Working this way means the packet is split into fragments only one time.
§3.2Congestion
The tunnel's soft state collects signs of congestion, such as an ICMP Type 4 Source Quench in a datagram from the decapsulator, the router at the far end of the tunnel. When the encapsulator forwards another datagram into the tunnel, it is appropriate to send Source Quench messages to the originator as well.
When the tunnel is congested, the router at its entrance passes that on to the original sender with a Source Quench message, the same one an ordinary router sends.
§3.3Routing Failures
Because the time to live is reset every time a datagram is encapsulated, a routing loop inside a tunnel is especially dangerous when the datagram arrives back at the encapsulator. If the IP source of the datagram matches any of the encapsulator's own interfaces, an implementation must not encapsulate it again; the datagram is forwarded normally instead.
ICMP Type 11 Time Exceeded messages report routing loops inside the tunnel. ICMP Type 3 Destination Unreachable messages report delivery failures to the decapsulator, and that soft state must be reported to the originator as Type 3 Code 0 Network Unreachable.
A packet that loops inside a tunnel must not be wrapped again when it comes back to the tunnel entrance. The entrance router sends the original sender a network-unreachable message instead.