From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1853.txt | 451 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 451 insertions(+) create mode 100644 doc/rfc/rfc1853.txt (limited to 'doc/rfc/rfc1853.txt') 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] + -- cgit v1.2.3