HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 05:25:13 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 07 Jul 1995 22:00:00 GMT ETag: "30497a-3ade-2ffdae60" Accept-Ranges: bytes Content-Length: 15070 Connection: close Content-Type: text/plain Internet Engineering Task Force C. Perkins INTERNET DRAFT IBM 05 July 1995 IP Encapsulation within IP draft-ietf-mobileip-ip4inip4-00.txt Status of This Memo This document is a submission by the Mobile-IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@tadpole.com mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months, and may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. Encapsulation is suggested as a means to effect "re-addressing" datagrams (i.e, delivering them to an intermediate destination other than that specified in the IP destination field) for any of a variety of reasons, but particularly those useful for adherence to the mobile-IP specification. Perkins Expires 05 January 1996 [Page i] Internet Draft IP-within-IP 05 July 1995 1. Introduction This document specifies a method by which an IP datagram may be encapsulated (carried as payload) within an IP datagram. Encapsulation is suggested as a means to effect "re-addressing" datagrams -- that is, delivering them to an intermediate destination other than that specified in the IP destination field. The process of encapsulation and decapsulation a datagram is frequently referred to as "tunneling" the datagram, and the encapsulator and decapsulator are then considered to be the the "endpoints" of the tunnel. 2. Motivation The mobile-IP working group has specified the use of encapsulation as a way to deliver packets from a mobile host's "home network" to an agent which can deliver packets to the mobile host by conventional means [1]. The use of encapsulation may also be desirable whenever the source (or an intermediate router) of an IP datagram must influence the route by which a datagram is to be delivered to its ultimate destination. Other possible applications include preferential billing, choice of routes with selected security attributes, and general policy routing. It is generally true that encapsulation and source routing techniques can both be used to re-address datagrams whenever that is necessary, but there are several technical reasons to prefer encapsulation: - There are unsolved security problems associated with the use of source routing. - Current internet routers exhibit performance problems when forwarding packets which use the IP source routing option. - Too many internet hosts process source routing options incorrectly. - Firewalls may exclude source-routed packets. - Insertion of an IP source route option may complicate the processing of authentication information by the source and/or destination of a datagram, depending on how the authentication is specified to be performed. - It is considered impolite for intermediate routers to make modifications to the packets which they did not originate. Perkins Expires 05 January 1996 [Page 1] Internet Draft IP-within-IP 05 July 1995 These technical advantages must be weighed against the disadvantages posed by the use of encapsulation: - Encapsulated packets typically are longer than source routed packets. - Encapsulation cannot be used unless it is known in advance that the tunnel endpoint for the encapsulated datagram can decapsulate the packet. Since the majority of internet hosts today do not perform well when IP loose source route options are used, the second technical disadvantage of encapsulation is not as serious as it might seem at first. 3. IP in IP Encapsulation An outer IP header is inserted before the datagram's IP header: +---------------------------+ | Outer IP Header | +---------------------------+ +---------------------------+ | IP Header | | IP Header | +---------------------------+ ====> +---------------------------+ | | | | | IP Payload | | IP Payload | | | | | +---------------------------+ +---------------------------+ The format of the IP header is described in RFC 791[4]. The outer IP header source and destination addresses identify the "endpoints" of the tunnel. The inner IP header source and destination addresses identify the sender and recipient of the datagram. The inner IP header is not changed by the node which encapsulates it inside the outer IP header, and the inner header remains unchanged during its delivery to the tunnel endpoint. No change to IP options in the inner header occurs during delivery of the encapsulated packet through the tunnel. Perkins Expires 05 January 1996 [Page 2] Internet Draft IP-within-IP 05 July 1995 Version 4 IHL The Internet Header Length measures the length (in bytes) of the outer IP header exclusive of its payload, but including any options which the encapsulating agent may insert. TOS The type of service is copied from the inner IP header. Total Length The length measures the length of the outer IP header along with its payload, that is to say the inner IP header and the original datagram. Identification Flags Fragment Offset These three fields are set in accordance with the procedures specified in [4]. The "Don't Fragment" bit in the outer IP header is copied from the corresponding flag in the inner IP header. Time to Live The Time To Live (TTL) field in the outer IP header is set to be the same as the original datagram. Protocol The protocol field in the outer IP header is set to protocol number 4 for the encapsulation protocol. Header Checksum The Header Checksum is computed over the length (in bytes) of the outer IP header exclusive of its payload, but including any options which the encapsulating endpoint may insert. Perkins Expires 05 January 1996 [Page 3] Internet Draft IP-within-IP 05 July 1995 Source Address The IP address of the encapsulating agent, that is, the tunnel starting point. Destination Address The IP address of the decapsulating agent, that is, the tunnel completion point. When decapsulating, the outer TTL minus one is inserted into the inner IP TTL. Thus, hops are counted, but the actual routers interior to the tunnel are not identified. This provides loop protection. The encapsulating agent is free to use any existing IP mechanisms appropriate for delivery of the encapsulated payload to the tunnel endpoint. In particular, this means that use of IP options and fragmentation are allowed, unless the "Don't Fragment" bit is set in the inner IP header. This is required so that hosts employing Path MTU discovery [2] can obtain the information they seek. 4. ICMP messages from within the tunnel After an encapsulated datagram has been sent, the encapsulating agent may receive an ICMP message from any intermediate router within the tunnel, except for the tunnel endpoint. The action taken by the encapsulating agent depends on the type of ICMP message received. In many cases, the encapsulating agent will use the incoming message to create a similar ICMP message, which then is sent to the originator of the inner IP datagram. This process will be referred to as "relaying" the ICMP message to the source of the original uncapsulated datagram. 4.1. Destination Unreachable Destination Unreachable messages are handled depending upon their type. The model suggested here allows the tunnel to "extend" a network to include non-local (e.g, mobile) hosts. Thus, if the original destination in the unencapsulated datagram is on the same network as the encapsulating agent, certain Destination Unreachable codes may be modified to conform to the suggested model. Code 0 A Destination Unreachable message may be returned to the original sender. If the original destination in Perkins Expires 05 January 1996 [Page 4] Internet Draft IP-within-IP 05 July 1995 the unencapsulated datagram is on the same network as the encapsulating agent, the newly generated Destination Unreachable message sent by the encapsulating agent can have type 1, since presumably the packet arrived to the correct network and the encapsulating agent is trying to create the appearance that the original destination is local even if it's not. Otherwise, the encapsulating agent must return a Destination Unreachable with code 0 message to the original sender. Code 1 The encapsulating agent must relay Destination Unreachable messages of code 1 (host unreachable) to the source of the original unencapsulated datagram. Code 2 When the encapsulating agent receives a Destination Unreachable ICMP message with code 2 (protocol unreachable) it should send a Destination Unreachable message with code 0 or 1 (see the discussion for code 0) to the sender of the original unencapsulated datagram. Since the original sender did not necessarily use protocol 4, it would be meaningless to return code 2 to that sender. Code 3 This code (port unreachable) should never be received by the encapsulating agent, since the outer IP header does not refer to any port number. It must not be relayed to the source of the original unencapsulated datagram. Code 4 The encapsulating agent must relay Destination Unreachable messages of code 4 (fragmentation needed and DF set) to the source of the original unencapsulated datagram. Code 5 This code (source route failed) should be treated by the encapsulating agent itself. It must not be relayed to the source of the original unencapsulated datagram. Perkins Expires 05 January 1996 [Page 5] Internet Draft IP-within-IP 05 July 1995 4.2. Time Exceeded The encapsulating agent may relay Time Exceeded messages to the source of the original unencapsulated datagram. 4.3. Parameter Problem If the parameter problem points to a field copied from the original unencapsulated datagram, the encapsulating agent may relay the ICMP message to the source; otherwise, if the problem occurs with an IP option inserted by the encapsulating agent, then the encapsulating agent must not relay the ICMP message to the source. Note that an encapsulating agent following prevalent current practice will never insert any IP options into the encapsulated datagram. 4.4. Redirect The encapsulating agent may act on the Redirect message if it is possible, but it should not relay the Redirect back to the source of the datagram which was encapsulated. Acting upon the Redirect message would require that the encapsulating agent maintain storage for encapsulated packets, and this may be an unpopular design choice for many purposes. 4.5. Source Quench The encapsulating agent may relay Source Quench messages to the source of the original unencapsulated datagram. 4.6. Other messages Other ICMP messages are not related to the encapsulation operations described within this protocol specification, and should be acted on as specified in [3]. 5. Security Considerations Security considerations are not addressed in this document. Perkins Expires 05 January 1996 [Page 6] Internet Draft IP-within-IP 05 July 1995 6. Acknowledgements The text for parts of section 3 was taken from the mobile-IP draft([1]). References [1] IETF Mobile-IP Working Group. IPv4 Mobility Support. ietf-draft-mobileip-protocol-10.txt -- work in progress, May 1995. [2] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, November 1990. [3] J. Postel. Internet Control Message Protocol. RFC 792, September 1981. [4] J. Postel. Internet Protocol. RFC 791, September 1981. Author's Address Questions about this memo can also be directed to: Charles Perkins Room J1-A25 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1-914-784-7350 Fax: +1-914-784-7007 E-mail: perk@watson.ibm.com The working group can be contacted via the current chairs: Jim Solomon Tony Li Motorola, Inc. cisco systems 1301 E. Algonquin Rd. 170 W. Tasman Dr. Schaumburg, IL 60196 San Jose, CA 95134 Work: +1-708-576-2753 Work: +1-408-526-8186 E-mail: solomon@comm.mot.com E-mail: tli@cisco.com Perkins Expires 05 January 1996 [Page 7]