| Related sites for http://www.faqs.org/rfcs/rfc1853.html |
| ContentBox A suite of solutions targeted for any project scope and budget. Offers advanced functionalities such as automated workflows, collaboration, multilingual CM, and multi-websites management. | | Caledonian_Cables Manufacturer of coax, microphone, telephone, control, belden, elastomeric, power, LAN, fiber and railway cables. Located in UK, USA, Singapore, China, Hong Kong. | | Openwave Email server software for medium to large ISPs and telecommunication providers. | | USA_Computing_Olympiad_(USACO) USACO supports pre-college computing around the world through computer programming competitions and training materials. Site contains details about current and previous competitions, alumni, training, | | Electronic_Design_Automation_and_Test_(EDA&T)_Expo One of the largest design automation shows in the Asia-Pacific region. The next EDA&T Expo will be held in Shanghai, April 8-9, 2002; and in Beijing, April 11-12, 2002. | | MacPIC PIC Development System for Macintosh includes PIC disassembler, by MacRobotics. [Shareware] | | Biological_Sequence_Analysis__Probabilistic_Models_of_Proteins_and_Nucleic_Acids_ by R. Durbin, S.R. Eddy, A. Krogh, G.J. Mitchison. Focus is mainly on machine learning methods for alignment, phylogeny, and RNA structure analysis. | | Rhodes_University Department of Computer Science. Research specialties are distributed multimedia and virtual reality. | | Official_Perl_FAQ The official frequently asked questions about Perl, as taken from the perldoc manpages. | | rFaith_net Provides free websites to Christian churches to help establish community within the church. Sites are templated. Password protected discussion boards are provided. | | RFC_0140 Agenda for the May NWG Meeting. S.D. Crocker. May 1971. | | Windows_XP_Help_and_Tips Computer help for Windows XP users. Topics include Tweak UI, printers, account management, Remote Desktop Connection, Media Player, and Internet Explorer. | | MIT_Kerberos_Consortium Created to establish Kerberos as a universal authentication platform for the world's computer networks. Includes news and events, details of sponsors and those involved, and membership information. | | TicaTK A GUI toolkit for Web applications based on Javascript (client side) and PHP (server side). It provides an OO PHP API which allows complex Web interface creation and management. [Open source, GPL] | | Smooth_animation_using_DHTML Taking an in-depth look at cross-browser cross-platform DHTML performance using a simple animation test. Full description of the tests as well as source code, all tests are also available. | | Connecticut_Software_Consortium Provides design and custom software services. | | WIT Offers consulting, marketing, and design services. | | Kerkhof,_Todd_A_ This Macintosh business solutions specialist also offers hosting, site design, graphics, and interactivity. | | KeyboardControl_SDK Allows custom Win32 applications to expand control over the Windows environment by adding the ability to filter out any keystroke or combination keystroke including PrintScreen, Alt+Tab, Alt+F4, Ctrl+ | | NegotiateAuth Aims to create a plugin for the Mozilla-based browsers supporting the HTTP Negotiate authentication method. |
|
RFC 1853 (rfc1853) - IP in IP Tunneling@import 'http://faqs.org/abstracts/css/default.css';@import 'http://faqs.org/search.css';function erfc(s){document.write("[ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ]Alternate Formats: rfc1853.txt | rfc1853.txt.pdfRFC 1853 - IP in IP TunnelingSearch the Archives  Display RFC by number RFC1853 - IP in IP TunnelingNetwork Working Group W. SimpsonRequest for Comments: 1853 DaydreamerCategory: Informational October 1995 IP in IP TunnelingStatus 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 ............................................. 81. 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 Previous: RFC 1852 - IP Authentication using Keyed SHA Next: RFC 1854 - SMTP Service Extension for Command Pipelining [ RFC Index | RFC Search | Usenet FAQs | Web FAQs | Documents | Cities ] © 2008 FAQS.ORG. All rights reserved. |
|
