HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 05:25:16 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 14 May 1996 22:00:00 GMT ETag: "30497c-6f79-31990260" Accept-Ranges: bytes Content-Length: 28537 Connection: close Content-Type: text/plain Internet Engineering Task Force C. Perkins INTERNET DRAFT IBM 10 May 1996 IP Encapsulation within IP draft-ietf-mobileip-ip4inip4-02.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@SmallWorks.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 alter the normal IP routing for datagrams, by delivering them to an intermediate destination which would not be otherwise selected by the (network part of the) IP destination field. This may be done for any of a variety of reasons, but is particular useful for adherence to the mobile-IP specification. Perkins Expires 10 November 1996 [Page i] Internet Draft IP-within-IP 10 May 1996 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 alter the normal IP routing for datagrams, by delivering them to an intermediate destination which would not be otherwise selected based the (network part of 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. In the most general encapsulation case we have source ---> encapsulator --------> decapsulator ---> destination with these being separate machines. There may in general be multiple source-destination pairs using the same tunnel. 2. Motivation The mobile-IP working group has specified the use of encapsulation as a way to deliver datagrams from a mobile host's "home network" to an agent which can deliver datagrams to the mobile host by conventional means [7]. 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 be used in similar ways to affect the routing of a datagram, 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 datagrams which use the IP source routing option. - Too many internet hosts process source routing options incorrectly. - Firewalls may exclude source-routed datagrams. Perkins Expires 10 November 1996 [Page 1] Internet Draft IP-within-IP 10 May 1996 - 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 datagrams which they did not originate. These technical advantages must be weighed against the disadvantages posed by the use of encapsulation: - Encapsulated datagrams typically are longer than source routed datagrams. - Encapsulation cannot be used unless it is known in advance that the tunnel endpoint for the encapsulated datagram can decapsulate the datagram. 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[9]. 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, except to decrement the TTL before delivery. 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 datagram through the tunnel. If need be, other protocol headers such as the IP Authentication header [1] may be inserted Perkins Expires 10 November 1996 [Page 2] Internet Draft IP-within-IP 10 May 1996 between the outer IP header and the inner IP header (also see section 6.3). 3.1. IP Header Fields and Handling 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 (typically) the inner IP header and the original datagram. Identification, Flags, Fragment Offset These three fields are set in accordance with the procedures specified in [9]. 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 a value appropriate for delivery of the encapsulated datagram to the tunnel endpoint. Protocol The protocol field in the outer IP header is set to protocol number 4 for the encapsulation protocol. Perkins Expires 10 November 1996 [Page 3] Internet Draft IP-within-IP 10 May 1996 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. 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. Options not copied from the inner IP header. However, new options particular to the path MAY be added. In particular, 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. The inner TTL is decremented by one. If the resulting TTL is 0, the datagram is not tunneled. An encapsulating agent MUST NOT encapsulate a datagram with TTL = 0 for delivery to a tunnel endpoint. The TTL is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL zero, a tunnel endpoint MUST discard the datagram. If the decapsulator forwards the datagram to some network interface, it will decrement the TTL as a result of doing normal IP forwarding. See also subsection 4.4. 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 [6] can obtain the information they seek. 3.2. Routing Failures Routing loops within a tunnel are particularly dangerous when they cause datagrams to arrive again at the encapsulator. If the IP Source matches any of its interfaces, an implementation MUST Perkins Expires 10 November 1996 [Page 4] Internet Draft IP-within-IP 10 May 1996 NOT further encapsulate. If the IP Source matches the tunnel destination, an implementation SHOULD NOT further encapsulate. See also subsection 4.4. 4. ICMP messages from within the tunnel After an encapsulated datagram has been sent, the encapsulating agent may receive an ICMP [8] 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. When the received message contains enough information, the encapsulating agent may use the incoming message to create a similar ICMP message, to be 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 unencapsulated datagram. Relaying an ICMP message requires that the encapsulator must strip off the outer IP header which it receives from the sender of the ICMP message. For cases where the received message does not contain enough data, see section 5. 4.1. Destination Unreachable (Type 3) 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. Network Unreachable (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 MAY have code 1 (Host Unreachable), since presumably the datagram 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. Perkins Expires 10 November 1996 [Page 5] Internet Draft IP-within-IP 10 May 1996 Host Unreachable (Code 1) The encapsulating agent must relay Host Unreachable messages to the source of the original unencapsulated datagram. Protocol Unreachable (Code 2) When the encapsulating agent receives a Protocol Unreachable ICMP message, 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 might only rarely use protocol 4, it would be usually be meaningless to return code 2 to that sender. Port Unreachable (Code 3) This code 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. Datagram Too Big (Code 4) The encapsulating agent must relay Datagram Too Big messages to the source of the original unencapsulated datagram. Source Route Failed (Code 5) This code should be treated by the encapsulating agent itself. It must not be relayed to the source of the original unencapsulated datagram. 4.2. Source Quench (Type 4) The encapsulating agent SHOULD NOT relay Source Quench messages to the source of the original unencapsulated datagram, but instead activate whatever congestion control mechanisms it implements to alleviate the congestion detected within the tunnel. 4.3. Redirect (Type 5) 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. Perkins Expires 10 November 1996 [Page 6] Internet Draft IP-within-IP 10 May 1996 4.4. Time Exceeded (Type 11) ICMP Time Exceeded messages report routing loops within the tunnel itself. Reception of Time Exceeded messages by the encapsulator MUST be reported to the originator as Host Unreachable (Type 3 Code 1). Host Unreachable is preferable to Network Unreachable; since the datagram was handled by the encapsulator, and the encapsulator is often considered to be on the same network as the destination address in the original unencapsulated datagram, the datagram is considered to have reached the correct network, but not the correct destination host within that network. 4.5. Parameter Problem (Type 12) 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, except possibly for security reasons. 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 [8]. 5. Tunnel Management 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 encapsulated header, so it is not always possible for the home agent to immediately reflect the ICMP message from the interior of a tunnel back to the originating host. However, by carefully maintaining "soft state" about its tunnels, the encapsulating router can return accurate ICMP messages in most Perkins Expires 10 November 1996 [Page 7] Internet Draft IP-within-IP 10 May 1996 cases. The router SHOULD maintain at least the following soft state information about each tunnel: - MTU of the tunnel (subsection 5.1) - TTL (path length) of the tunnel - Reachability of the end 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. ICMP errors that could be received from one of the routers along the tunnel interior include: - Datagram Too Big - Time Exceeded - Destination Unreachable - Source Quench 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 TTL is less than the tunnel TTL) the router sends an ICMP error message back to the source, but also forwards the datagram into the tunnel. Using this technique, the ICMP error messages sent by encapsulating routers will not always match up one-to-one with errors encountered within the tunnel, but they will accurately reflect the state of the network. Tunnel soft state was originally developed for the IP address encapsulation (IPAE) specification [4]. 5.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 [5, 6] within their tunnels. In this particular application there are several advantages: - As a benefit of Tunnel MTU Discovery, any fragmentation which occurs because of the size of the encapsulation header is performed only once after encapsulation. This prevents multiple fragmentation of a single datagram, which improves processing efficiency of the path routers and tunnel decapsulator. Perkins Expires 10 November 1996 [Page 8] Internet Draft IP-within-IP 10 May 1996 - If the source of the unencapsulated datagram is doing MTU discovery then it is desirable for the encapsulator to know the MTU to the decapsulator. If it doesn't know the MTU then it can transfer the DF bit to the outer datagram; however, if that triggers ICMP Datagram Too Big from within the tunnel (and hence returned to the encapsulator) the encapsulator cannot always return a correct ICMP response to the source unless it has kept state information about recently sent datagrams. If the tunnel MTU is returned to the source by the encapsulator in a Datagram Too Big message, the MTU that is conveyed SHOULD be the MTU of the tunnel minus the size of the encapsulating IP header. This will avoid fragmentation of the original IP datagram by the encapsulator, something that is otherwise certain to occur. - If the source is not doing MTU discovery it is still desirable for the encapsulator to know the MTU to the decapsulator. In particular it is much better to fragment the inner datagram than to allow the outer datagram to be fragmented. Fragmenting the inner datagram can be done without special buffer requirements and without the need to keep state in the decapsulator. By contrast if the outer datagram is fragmented then the decapsulator needs to keep state and buffer space on behalf of the destination. The encapsulator SHOULD in normal circumstances do MTU discovery and try to send datagrams with the DF bit set. However there are problems with this approach. When the source sets the DF bit it can react quickly to resend the information if it gets a ICMP Datagram Too Big. When the encapsulator gets a ICMP Datagram Too Big, but the source had not set the DF bit, then there is nothing sensible that the encapsulator can do to let the source know. The encapsulator MAY keep a copy of the sent datagram whenever it tries increasing the MTU - this will allow it to resend the datagram fragmented if it gets a datagram too big response. Alternatively the encapsulator MAY be configured for certain classes of input to not set the DF bit when the source has not set the DF bit. 5.2. Congestion Tunnel soft state will collect indications of congestion, such as an ICMP (Type 4) Source Quench or a Congestion Experienced flag in datagrams from the decapsulator (tunnel peer). When forwarding another datagram into the tunnel, it is appropriate to use approved means for controlling congestion [3]; Source Quench messages SHOULD NOT be sent to the originator. Perkins Expires 10 November 1996 [Page 9] Internet Draft IP-within-IP 10 May 1996 6. Security Considerations IP encapsulation potentially reduces the security of the Internet. For this reason care needs to be taken in the implementation and deployment. Assume an organization has good physical control of a secure subset of its network. Assume that the routers connecting that secure network do not allow in datagrams with source addresses belonging to interfaces on that secure network. In that situation it is possible to safely deploy protocols within that network which depend on the source address of datagrams for authentication purposes. Networks with physical security can still be used to run protocols which are convenient, but which have implementation or protocol bugs which would make them dangerous to use if external sources have access to the protocol. The external sources can be excluded using router datagram filtering. IP encapsulation protocols may allow datagrams to bypass the checks in the border routers. There are two cases to consider: - The case where the people controlling the border routers are trying to protect inner machines from themselves. - The case where the inner machine is looking after its own defense. An uncooperative inner machine cannot be protected by the border router except by barring all packets to that machine. There is nothing to stop encapsulated IP coming in to that inner machine in otherwise harmless datagrams such as port 53 UDP datagrams (i.e., apparently DNS datagrams). So there is a strong case for placing the security controls at the host rather than the router. However, in situations where the administrative control of the inner machine is cooperative but lacks thoroughness or competence, security can be enhanced by also putting protection in the border routers. 6.1. Router Considerations Routers need to be aware of IP encapsulation protocols so they can correctly filter incoming datagrams. Beyond that it is desirable that filtering be integrated with IP authentication [1]. In the case of IP encapsulation this can have 2 forms: Encapsulation might be allowed (in some cases) as long as the encapsulating datagrams authentically come from an expected Perkins Expires 10 November 1996 [Page 10] Internet Draft IP-within-IP 10 May 1996 encapsulator. Alternatively encapsulation might be allowed if the encapsulated datagrams have authentication. Data which is encapsulated and encrypted [2] may also pose a problem. In this case the router can only filter the datagram if it knows the security association. To allow this sort of encryption in environments where all packets need to be filtered (or at least accounted for) a mechanism must be in place for the receiving host to securely communicate the association to the border router. This might, more rarely, also apply to the association used for outgoing datagrams. 6.2. Host Considerations Receiving IP encapsulation software SHOULD classify incoming datagrams and only allow datagrams fitting one of the following categories: - The protocol is harmless: source address based authentication is not needed. - The datagram can be trusted because of trust in the authentically identified encapsulating host. That authentic identification could come from physical security plus border router configuration but is more likely to come from AH authentication. - The inner datagram has AH authentication. Some or all of this checking could be done in border routers rather than the receiving host but it is better if border router checks are used as backup rather than being the only check. 6.3. Using Security Options The security options of the inner IP header MAY affect the choice of security options for the encapsulating IP header. Perkins Expires 10 November 1996 [Page 11] Internet Draft IP-within-IP 10 May 1996 7. Acknowledgements Parts of sections 3 and 5 of this document were taken from sections (authored by Bill Simpson) of earlier versions of the mobile-IP Internet Draft [7]. Good ideas have also been included from RFC 1853 [10], also authored by Bill Simpson. "Security Considerations" (section 6) was largely contributed by Bob Smart. Thanks also to Anders Klemets for finding mistakes and suggesting many improvements to the draft. References [1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995. [2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, August 1995. [3] F. Baker, Editor. Requirements for IP Version 4 Routers. RFC 1812, June 1995. [4] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP Interoperability and Transition Mechanism. Internet Draft -- work in progress, March 1994. [5] S. Knowles. IESG Advice from Experience with Path MTU Discovery. RFC 1435, March 1993. [6] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191, November 1990. [7] C. Perkins, Editor. ietf-draft-mobileip-protocol-16.txt - work in progress. IPv4 Mobility Support, April 1996. [8] J. B. Postel, Editor. Internet Control Message Protocol. RFC 792, September 1981. [9] J. B. Postel, Editor. Internet Protocol. RFC 791, September 1981. [10] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995. Perkins Expires 10 November 1996 [Page 12] Internet Draft IP-within-IP 10 May 1996 Author's Address Questions about this memo can be directed to: Charles Perkins Room H3-D34 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1-914-784-7350 Fax: +1-914-784-6205 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-847-576-2753 Work: +1-408-526-8186 E-mail: solomon@comm.mot.com E-mail: tli@cisco.com Perkins Expires 10 November 1996 [Page 13]