summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1853.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1853.txt')
-rw-r--r--doc/rfc/rfc1853.txt451
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1853.txt b/doc/rfc/rfc1853.txt
new file mode 100644
index 0000000..39f5bb6
--- /dev/null
+++ b/doc/rfc/rfc1853.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+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
+
+
+
+
+
+Simpson Informational [Page 1]
+
+RFC 1853 IP Tunnelling October 1995
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson Informational [Page 2]
+
+RFC 1853 IP Tunnelling October 1995
+
+
+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).
+
+
+
+
+Simpson Informational [Page 3]
+
+RFC 1853 IP Tunnelling October 1995
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+Simpson Informational [Page 4]
+
+RFC 1853 IP Tunnelling October 1995
+
+
+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.
+
+
+
+
+
+
+Simpson Informational [Page 5]
+
+RFC 1853 IP Tunnelling October 1995
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson Informational [Page 6]
+
+RFC 1853 IP Tunnelling October 1995
+
+
+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.
+
+
+
+
+
+
+Simpson Informational [Page 7]
+
+RFC 1853 IP Tunnelling October 1995
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson Informational [Page 8]
+