Internet Engineering Task Force C. Perkins INTERNET DRAFT IBM 06 July 1995 Minimal Encapsulation within IP draft-ietf-minenc-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 06 January 1996 [Page i] Internet Draft Minimal Encapsulation for IP 06 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. See [4] for a discussion concerning the advantages of encapsulation versus source routing. Since using IP headers to encapsulate IP datagrams requires the unwarranted duplication of several fields within the inner IP header, it is possible to save some additional space by specifying a new encapsulation mechanism that eliminates the duplication. The scheme outlined in this protocol specification comes from the mobile-IP working group (in earlier Internet Drafts), and is similar to that outlined in [2]. 3. Minimal Encapsulation A minimal forwarding header is defined for datagrams which are not fragmented prior to encapsulating. Use of this encapsulating method is optional. Minimal encapsulation must not be used when an original datagram is already fragmented, since there is no room in the inner header to store fragmentation information. Perkins Expires 06 January 1996 [Page 1] Internet Draft Minimal Encapsulation for IP 06 July 1995 The minimal encapsulation process produces a datagram structured as shown below; the IP header of the original datagram is modified, then followed by the minimal forwarding header, followed by the unmodified IP payload of the original datagram. +---------------------------+ +---------------------------+ | IP Header | | Modified IP Header | +---------------------------+ ====> +---------------------------+ | | | Minimal Forwarding Header | | IP Payload | +---------------------------+ | | | | +---------------------------+ | IP Payload | | | +---------------------------+ Encapsulation is performed as follows. The protocol field in the IP header is replaced by protocol number 55 for the minimal encapsulation protocol. The destination field in the IP header is replaced by the care-of address of the mobile node. If the encapsulating agent is not the original source of the datagram, the source field in the IP header is replaced by the IP address of the encapsulating agent. When decapsulating a datagram, the fields in the forwarding header are restored to the IP header, and the forwarding header is removed from the datagram. The format of the minimal forwarding header is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protocol |S| reserved | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Original Destination Address : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Protocol Copied from the protocol field in the original IP header. Perkins Expires 06 January 1996 [Page 2] Internet Draft Minimal Encapsulation for IP 06 July 1995 S Source field present bit, which indicates that the Original Source Address field is present. 0 not present. 1 present. reserved Sent as zero; ignored on reception. Header Checksum The 16-bit one's complement of the one's complement sum of the encapsulation header. For computing the checksum, the checksum field is set to 0. Original Destination Address Copied from the destination field in the original IP header. Original Source Address Copied from the source field in the original IP header. Present only if the S-bit is set. The encapsulating agent is free to use 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 [3] can obtain the information they seek. 4. ICMP messages from within the tunnel The following discussion, included here for convenience, is the same as that in [4]. 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 Perkins Expires 06 January 1996 [Page 3] Internet Draft Minimal Encapsulation for IP 06 July 1995 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 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 Perkins Expires 06 January 1996 [Page 4] Internet Draft Minimal Encapsulation for IP 06 July 1995 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. 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. Perkins Expires 06 January 1996 [Page 5] Internet Draft Minimal Encapsulation for IP 06 July 1995 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 [5]. 5. Security Considerations Security considerations are not addressed in this document. 6. Acknowledgements The text for most 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] David B. Johnson. Scalable and Robust Internetwork Routing for Mobile Hosts. In Proceedings of the 14th International Conference on Distributed Computing Systems, pages 2--11, June 1994. [3] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, November 1990. [4] Charles Perkins. IP Encapsulation within IP. Internet Draft -- work in progress, July 1995. [5] J. Postel. Internet Control Message Protocol. RFC 792, September 1981. Author's Address Questions about this memo can be directed to: Charles Perkins Room J1-A25 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Perkins Expires 06 January 1996 [Page 6] Internet Draft Minimal Encapsulation for IP 06 July 1995 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 06 January 1996 [Page 7]