< draft-ietf-mobileip-ip4inip4-02.txt		draft-ietf-mobileip-ip4inip4-03.txt >
	Internet Engineering Task Force C. Perkins		Internet Engineering Task Force C. Perkins
	INTERNET DRAFT IBM		INTERNET DRAFT IBM
	10 May 1996		31 May 1996
	IP Encapsulation within IP		IP Encapsulation within IP
	draft-ietf-mobileip-ip4inip4-02.txt		draft-ietf-mobileip-ip4inip4-03.txt
	Status of This Memo		Status of This Memo
	This document is a submission by the Mobile-IP Working Group of the		This document is a submission by the Mobile IP Working Group of the
	Internet Engineering Task Force (IETF). Comments should be submitted		Internet Engineering Task Force (IETF). Comments should be submitted
	to the mobile-ip@SmallWorks.com mailing list.		to the mobile-ip@SmallWorks.COM mailing list.
	Distribution of this memo is unlimited.		Distribution of this memo is unlimited.
	This document is an Internet-Draft. Internet Drafts are working		This document is an Internet-Draft. Internet-Drafts are working
	documents of the Internet Engineering Task Force (IETF), its Areas,		documents of the Internet Engineering Task Force (IETF), its areas,
	and its Working Groups. Note that other groups may also distribute		and its working groups. Note that other groups may also distribute
	working documents as Internet Drafts.		working documents as Internet-Drafts.
	Internet Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six months
	months, and may be updated, replaced, or obsoleted by other documents		and may be updated, replaced, or obsoleted by other documents at
	at any time. It is not appropriate to use Internet Drafts as		any time. It is inappropriate to use Internet-Drafts as reference
	reference material, or to cite them other than as a ``working draft''		material or to cite them other than as "work in progress."
	or ``work in progress.''
	To learn the current status of any Internet-Draft, please check		To learn the current status of any Internet-Draft, please check
	the ``1id-abstracts.txt'' listing contained in the internet-drafts		the "1id-abstracts.txt" listing contained in the Internet-Drafts
	Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net		Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
	(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific		munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
	Rim).		ftp.isi.edu (US West Coast).
	Abstract		Abstract
	This document specifies a method by which an IP datagram may		This document specifies a method by which an IP datagram may
	be encapsulated (carried as payload) within an IP datagram.		be encapsulated (carried as payload) within an IP datagram.
	Encapsulation is suggested as a means to alter the normal IP routing		Encapsulation is suggested as a means to alter the normal IP routing
	for datagrams, by delivering them to an intermediate destination		for datagrams, by delivering them to an intermediate destination
	which would not be otherwise selected by the (network part of the)		that would otherwise not be selected by the (network part of the) IP
	IP destination field. This may be done for any of a variety of		Destination Address field in the original IP header. Encapsulation
	reasons, but is particular useful for adherence to the mobile-IP		may serve a variety of purposes, such as delivery of a datagram to a
	specification.		mobile node using Mobile IP.
	1. Introduction		1. Introduction
	This document specifies a method by which an IP datagram may		This document specifies a method by which an IP datagram may
	be encapsulated (carried as payload) within an IP datagram.		be encapsulated (carried as payload) within an IP datagram.
	Encapsulation is suggested as a means to alter the normal IP routing		Encapsulation is suggested as a means to alter the normal IP routing
	for datagrams, by delivering them to an intermediate destination		for datagrams, by delivering them to an intermediate destination that
	which would not be otherwise selected based the (network part of the)		would otherwise not be selected based on the (network part of the)
	IP destination field. The process of encapsulation and decapsulation		IP Destination Address field in the original IP header. Once the
	a datagram is frequently referred to as "tunneling" the datagram, and		encapsulated datagram arrives at this intermediate destination node,
	the encapsulator and decapsulator are then considered to be the the		it is decapsulated, yielding the original IP datagram, which is then
			delivered to the destination indicated by the original Destination
			Address field. This use of encapsulation and decapsulation of a
			datagram is frequently referred to as "tunneling" the datagram, and
			the encapsulator and decapsulator are then considered to be the
	"endpoints" of the tunnel.		"endpoints" of the tunnel.
	In the most general encapsulation case we have		In the most general tunneling case we have
	source ---> encapsulator --------> decapsulator ---> destination		source ---> encapsulator --------> decapsulator ---> destination
	with these being separate machines. There may in general be multiple		with the source, encapsulator, decapsulator, and destination being
	source-destination pairs using the same tunnel.		separate nodes. The encapsulator node is considered the "entry
			point" of the tunnel, and the decapsulator node is considered
			the "exit point" of the tunnel. There in general may be multiple
			source-destination pairs using the same tunnel between the
			encapsulator and decapsulator.
	2. Motivation		2. Motivation
	The mobile-IP working group has specified the use of encapsulation		The Mobile IP working group has specified the use of encapsulation
	as a way to deliver datagrams from a mobile host's "home network"		as a way to deliver datagrams from a mobile node's "home network" to
	to an agent which can deliver datagrams to the mobile host by		an agent that can deliver datagrams locally by conventional means
	conventional means [7]. The use of encapsulation may also be		to the mobile node at its current location away from home [8]. The
	desirable whenever the source (or an intermediate router) of an		use of encapsulation may also be desirable whenever the source (or
	IP datagram must influence the route by which a datagram is to be		an intermediate router) of an IP datagram must influence the route
	delivered to its ultimate destination. Other possible applications		by which a datagram is to be delivered to its ultimate destination.
	include preferential billing, choice of routes with selected security		Other possible applications of encapsulation include multicasting,
			preferential billing, choice of routes with selected security
	attributes, and general policy routing.		attributes, and general policy routing.
	It is generally true that encapsulation and source routing techniques		It is generally true that encapsulation and the IP loose source
	can be used in similar ways to affect the routing of a datagram, but		routing option [10] can be used in similar ways to affect the routing
	there are several technical reasons to prefer encapsulation:		of a datagram, but there are several technical reasons to prefer
			encapsulation:
	- There are unsolved security problems associated with the use of		- There are unsolved security problems associated with the use of
	source routing.		the IP source routing options.
	- Current internet routers exhibit performance problems when		- Current Internet routers exhibit performance problems when
	forwarding datagrams which use the IP source routing option.		forwarding datagrams that contain IP options, including the IP
			source routing options.
	- Too many internet hosts process source routing options		- Many current Internet nodes process IP source routing options
	incorrectly.		incorrectly.
	- Firewalls may exclude source-routed datagrams.		- Firewalls may exclude IP source-routed datagrams.
	- Insertion of an IP source route option may complicate the		- Insertion of an IP source route option may complicate the
	processing of authentication information by the source and/or		processing of authentication information by the source and/or
	destination of a datagram, depending on how the authentication is		destination of a datagram, depending on how the authentication is
	specified to be performed.		specified to be performed.
	- It is considered impolite for intermediate routers to make		- It is considered impolite for intermediate routers to make
	modifications to datagrams which they did not originate.		modifications to datagrams which they did not originate.
	These technical advantages must be weighed against the disadvantages		These technical advantages must be weighed against the disadvantages
	posed by the use of encapsulation:		posed by the use of encapsulation:
	- Encapsulated datagrams typically are longer than source routed		- Encapsulated datagrams typically are larger than source routed
	datagrams.		datagrams.
	- Encapsulation cannot be used unless it is known in advance that		- Encapsulation cannot be used unless it is known in advance that
	the tunnel endpoint for the encapsulated datagram can decapsulate		the node at the tunnel exit point can decapsulate the datagram.
	the datagram.
	Since the majority of internet hosts today do not perform well		Since the majority of Internet nodes today do not perform well
	when IP loose source route options are used, the second technical		when IP loose source route options are used, the second technical
	disadvantage of encapsulation is not as serious as it might seem at		disadvantage of encapsulation is not as serious as it might seem at
	first.		first.
	3. IP in IP Encapsulation		3. IP in IP Encapsulation
	An outer IP header is inserted before the datagram's IP header:		To encapsulate an IP datagram using IP in IP encapsulation, an outer
			IP header [10] is inserted before the datagram's existing IP header,
			as follows:
	+---------------------------+		+---------------------------+
			| |
	| Outer IP Header |		| Outer IP Header |
			| |
	+---------------------------+ +---------------------------+		+---------------------------+ +---------------------------+
			| | | |
	| IP Header | | IP Header |		| IP Header | | IP Header |
			| | | |
	+---------------------------+ ====> +---------------------------+		+---------------------------+ ====> +---------------------------+
	| | | |		| | | |
			| | | |
	| IP Payload | | IP Payload |		| IP Payload | | IP Payload |
	| | | |		| | | |
			| | | |
	+---------------------------+ +---------------------------+		+---------------------------+ +---------------------------+
	The format of the IP header is described in RFC 791[9]. The outer		The outer IP header Source Address and Destination Address identify
	IP header source and destination addresses identify the "endpoints"		the "endpoints" of the tunnel. The inner IP header Source Address
	of the tunnel. The inner IP header source and destination addresses		and Destination Addresses identify the original sender and recipient
	identify the sender and recipient of the datagram. The inner IP		of the datagram, respectively. The inner IP header is not changed
	header is not changed by the node which encapsulates it, except		by the encapsulator, except to decrement the TTL as noted below, and
	to decrement the TTL before delivery. The inner header remains		remains unchanged during its delivery to the tunnel exit point. No
	unchanged during its delivery to the tunnel endpoint. No change		change to IP options in the inner header occurs during delivery of
	to IP options in the inner header occurs during delivery of the		the encapsulated datagram through the tunnel. If need be, other
	encapsulated datagram through the tunnel. If need be, other protocol		protocol headers such as the IP Authentication header [1] may be
	headers such as the IP Authentication header [1] may be inserted		inserted between the outer IP header and the inner IP header. Note
	between the outer IP header and the inner IP header (also see		that the security options of the inner IP header MAY affect the
	section 6.3).		choice of security options for the encapsulating (outer) IP header.
	3.1. IP Header Fields and Handling		3.1. IP Header Fields and Handling
			The fields in the outer IP header are set by the encapsulator as
			follows:
	Version		Version
	4		4
	IHL		IHL
	The Internet Header Length measures the length (in bytes) of		The Internet Header Length (IHL) is the length of the outer IP
	the outer IP header exclusive of its payload, but including any		header measured in 32-bit words [10].
	options which the encapsulating agent may insert.
	TOS		TOS
	The type of service is copied from the inner IP header.		The Type of Service (TOS) is copied from the inner IP header.
	Total Length		Total Length
	The length measures the length of the outer IP header along		The Total Length measures the length of the entire encapsulated
	with its payload, that is to say (typically) the inner IP		IP datagram, including the outer IP header, the inner IP
	header and the original datagram.		header, and its payload.
	Identification, Flags, Fragment Offset		Identification, Flags, Fragment Offset
	These three fields are set in accordance with the procedures		These three fields are set as specified in [10]. However, if
	specified in [9]. The "Don't Fragment" bit in the outer IP		the "Don't Fragment" bit is set in the inner IP header, it MUST
	header is copied from the corresponding flag in the inner IP		be set in the outer IP header; if the "Don't Fragment" bit is
	header.		not set in the inner IP header, it MAY be set in the outer IP
			header, as described in Section 5.1.
	Time to Live		Time to Live
	The Time To Live (TTL) field in the outer IP header is set to a		The Time To Live (TTL) field in the outer IP header is set to a
	value appropriate for delivery of the encapsulated datagram to		value appropriate for delivery of the encapsulated datagram to
	the tunnel endpoint.		the tunnel exit point.
	Protocol		Protocol
	The protocol field in the outer IP header is set to protocol		4
	number 4 for the encapsulation protocol.
	Header Checksum		Header Checksum
	The Header Checksum is computed over the length (in bytes) of		The Internet Header checksum [10] of the outer IP header.
	the outer IP header exclusive of its payload, but including any
	options which the encapsulating endpoint may insert.
	Source Address		Source Address
	The IP address of the encapsulating agent, that is, the tunnel		The IP address of the encapsulator, that is, the tunnel entry
	starting point.		point.
	Destination Address		Destination Address
	The IP address of the decapsulating agent, that is, the tunnel		The IP address of the decapsulator, that is, the tunnel exit
	completion point.		point.
	Options		Options
	not copied from the inner IP header. However, new options		Any options present in the inner IP header are in general NOT
	particular to the path MAY be added. In particular, any		copied to the outer IP header. However, new options specific
	supported flavors of security options of the inner IP header		to the tunnel path MAY be added. In particular, any supported
	MAY affect the choice of security options for the tunnel. It		types of security options of the inner IP header MAY affect the
	is not expected that there be a one-to-one mapping of such		choice of security options for the outer header. It is not
	options to the options or security headers selected for the		expected that there be a one-to-one mapping of such options to
	tunnel.		the options or security headers selected for the tunnel.
	The inner TTL is decremented by one. If the resulting TTL is		When encapsulating a datagram, the TTL in the inner IP header
	0, the datagram is not tunneled. An encapsulating agent MUST		is decremented by one if the tunneling is being done as part of
	NOT encapsulate a datagram with TTL = 0 for delivery to a tunnel		forwarding the datagram; otherwise, the inner header TTL is not
	endpoint. The TTL is not changed when decapsulating. If, after		changed during encapsulation. If the resulting TTL in the inner IP
	decapsulation, the inner datagram has TTL zero, a tunnel endpoint		header is 0, the datagram is discarded and an ICMP Time Exceeded
	MUST discard the datagram. If the decapsulator forwards the datagram		message SHOULD be returned to the sender. An encapsulator MUST NOT
	to some network interface, it will decrement the TTL as a result of		encapsulate a datagram with TTL = 0.
	doing normal IP forwarding. See also subsection 4.4.
	The encapsulating agent is free to use any existing IP mechanisms		The TTL in the inner IP header is not changed when decapsulating.
	appropriate for delivery of the encapsulated payload to the tunnel		If, after decapsulation, the inner datagram has TTL = 0, the
	endpoint. In particular, this means that use of IP options and		decapsulator MUST discard the datagram. If, after decapsulation, the
	fragmentation are allowed, unless the "Don't Fragment" bit is set in		decapsulator forwards the datagram to one of its network interfaces,
	the inner IP header. This is required so that hosts employing Path		it will decrement the TTL as a result of doing normal IP forwarding.
	MTU discovery [6] can obtain the information they seek.		See also Section 4.4.
			The encapsulator may use any existing IP mechanisms appropriate for
			delivery of the encapsulated payload to the tunnel exit point. In
			particular, use of IP options is allowed, and use of fragmentation
			is allowed unless the "Don't Fragment" bit is set in the inner IP
			header. This restriction on fragmentation is required so that nodes
			employing Path MTU Discovery [7] can obtain the information they
			seek.
	3.2. Routing Failures		3.2. Routing Failures
	Routing loops within a tunnel are particularly dangerous when		Routing loops within a tunnel are particularly dangerous when
	they cause datagrams to arrive again at the encapsulator. If the		they cause datagrams to arrive again at the encapsulator. Suppose
	IP Source matches any of its interfaces, an implementation MUST		a datagram arrives at a router for forwarding, and the router
	NOT further encapsulate. If the IP Source matches the tunnel		determines that the datagram has to be encapsulated before further
	destination, an implementation SHOULD NOT further encapsulate. See		delivery. Then:
	also subsection 4.4.
	4. ICMP messages from within the tunnel		- If the IP Source Address of the datagram matches the router's own
			IP address on any of its network interfaces, the router MUST NOT
			tunnel the datagram; instead, the datagram SHOULD be discarded.
	After an encapsulated datagram has been sent, the encapsulating		- If the IP Source Address of the datagram matches the IP address
	agent may receive an ICMP [8] message from any intermediate router		of the tunnel destination (the tunnel exit point is typically
	within the tunnel, except for the tunnel endpoint. The action taken		chosen by the router based on the Destination Address in the
	by the encapsulating agent depends on the type of ICMP message		datagram's IP header), the router MUST NOT tunnel the datagram;
	received. When the received message contains enough information, the		instead, the datagram SHOULD be discarded.
	encapsulating agent may use the incoming message to create a similar
	ICMP message, to be sent to the originator of the inner IP datagram.		See also Section 4.4.
	This process will be referred to as "relaying" the ICMP message to
	the source of the original unencapsulated datagram. Relaying an ICMP		4. ICMP Messages from within the Tunnel
	message requires that the encapsulator must strip off the outer IP
	header which it receives from the sender of the ICMP message. For		After an encapsulated datagram has been sent, the encapsulator may
	cases where the received message does not contain enough data, see		receive an ICMP [9] message from any intermediate router within the
	section 5.		tunnel other than the tunnel exit point. The action taken by the
			encapsulator depends on the type of ICMP message received. When the
			received message contains enough information, the encapsulator MAY
			use the incoming message to create a similar ICMP message, to be sent
			to the originator of the original unencapsulated IP datagram (the
			original sender). This process will be referred to as "relaying" the
			ICMP message from the tunnel.
			ICMP messages indicating an error in processing a datagram include a
			copy of (a portion of) the datagram causing the error. Relaying an
			ICMP message requires that the encapsulator strip off the outer IP
			header from this returned copy of the original datagram. For cases
			in which the received ICMP message does not contain enough data to
			relay the message, see Section 5.
	4.1. Destination Unreachable (Type 3)		4.1. Destination Unreachable (Type 3)
	Destination Unreachable messages are handled depending upon their		ICMP Destination Unreachable messages are handled by the encapsulator
	type. The model suggested here allows the tunnel to "extend" a		depending upon their Code field. The model suggested here allows
	network to include non-local (e.g., mobile) hosts. Thus, if the		the tunnel to "extend" a network to include non-local (e.g., mobile)
	original destination in the unencapsulated datagram is on the same		nodes. Thus, if the original destination in the unencapsulated
	network as the encapsulating agent, certain Destination Unreachable		datagram is on the same network as the encapsulator, certain
	codes may be modified to conform to the suggested model.		Destination Unreachable Code values may be modified to conform to the
			suggested model.
	Network Unreachable (Code 0)		Network Unreachable (Code 0)
	A Destination Unreachable message may be returned to		An ICMP Destination Unreachable message SHOULD be returned
	the original sender. If the original destination in		to the original sender. If the original destination in
	the unencapsulated datagram is on the same network as		the unencapsulated datagram is on the same network as the
	the encapsulating agent, the newly generated Destination		encapsulator, the newly generated Destination Unreachable
	Unreachable message sent by the encapsulating agent MAY have		message sent by the encapsulator MAY have Code 1 (Host
	code 1 (Host Unreachable), since presumably the datagram		Unreachable), since presumably the datagram arrived at the
	arrived to the correct network and the encapsulating agent is		correct network and the encapsulator is trying to create the
	trying to create the appearance that the original destination		appearance that the original destination is local to that
	is local even if it's not. Otherwise, the encapsulating agent		network even if it is not. Otherwise, if the encapsulator
	must return a Destination Unreachable with code 0 message to		returns a Destination Unreachable message, the Code field MUST
	the original sender.		be set to 0 (Network Unreachable).
	Host Unreachable (Code 1)		Host Unreachable (Code 1)
	The encapsulating agent must relay Host Unreachable messages to		The encapsulator SHOULD relay Host Unreachable messages to the
	the source of the original unencapsulated datagram.		sender of the original unencapsulated datagram, if possible.
	Protocol Unreachable (Code 2)		Protocol Unreachable (Code 2)
	When the encapsulating agent receives a Protocol Unreachable		When the encapsulator receives an ICMP Protocol Unreachable
	ICMP message, it should send a Destination Unreachable message		message, it SHOULD send a Destination Unreachable message with
	with code 0 or 1 (see the discussion for code 0) to the sender		Code 0 or 1 (see the discussion for Code 0) to the sender of
	of the original unencapsulated datagram. Since the original		the original unencapsulated datagram. Since the original
	sender might only rarely use protocol 4, it would be usually be		sender did not use protocol 4 in sending the datagram, it would
	meaningless to return code 2 to that sender.		be meaningless to return Code 2 to that sender.
	Port Unreachable (Code 3)		Port Unreachable (Code 3)
	This code should never be received by the encapsulating		This Code should never be received by the encapsulator, since
	agent, since the outer IP header does not refer to any port		the outer IP header does not refer to any port number. It MUST
	number. It must not be relayed to the source of the original		NOT be relayed to the sender of the original unencapsulated
	unencapsulated datagram.		datagram.
	Datagram Too Big (Code 4)		Datagram Too Big (Code 4)
	The encapsulating agent must relay Datagram Too Big messages to		The encapsulator MUST relay ICMP Datagram Too Big messages to
	the source of the original unencapsulated datagram.		the sender of the original unencapsulated datagram.
	Source Route Failed (Code 5)		Source Route Failed (Code 5)
	This code should be treated by the encapsulating agent		This Code SHOULD be handled by the encapsulator itself.
	itself. It must not be relayed to the source of the original		It MUST NOT be relayed to the sender of the original
	unencapsulated datagram.		unencapsulated datagram.
	4.2. Source Quench (Type 4)		4.2. Source Quench (Type 4)
	The encapsulating agent SHOULD NOT relay Source Quench messages to		The encapsulator SHOULD NOT relay ICMP Source Quench messages to the
	the source of the original unencapsulated datagram, but instead		sender of the original unencapsulated datagram, but instead SHOULD
	activate whatever congestion control mechanisms it implements to		activate whatever congestion control mechanisms it implements to help
	alleviate the congestion detected within the tunnel.		alleviate the congestion detected within the tunnel.
	4.3. Redirect (Type 5)		4.3. Redirect (Type 5)
	The encapsulating agent may act on the Redirect message if it is		The encapsulator MAY handle the ICMP Redirect messages itself.
	possible, but it should not relay the Redirect back to the source of		It MUST NOT not relay the Redirect to the sender of the original
	the datagram which was encapsulated.		unencapsulated datagram.
	4.4. Time Exceeded (Type 11)		4.4. Time Exceeded (Type 11)
	ICMP Time Exceeded messages report routing loops within the tunnel		ICMP Time Exceeded messages report (presumed) routing loops
	itself. Reception of Time Exceeded messages by the encapsulator MUST		within the tunnel itself. Reception of Time Exceeded messages by
	be reported to the originator as Host Unreachable (Type 3 Code 1).		the encapsulator MUST be reported to the sender of the original
	Host Unreachable is preferable to Network Unreachable; since the		unencapsulated datagram as Host Unreachable (Type 3, Code 1). Host
	datagram was handled by the encapsulator, and the encapsulator is		Unreachable is preferable to Network Unreachable; since the datagram
	often considered to be on the same network as the destination address		was handled by the encapsulator, and the encapsulator is often
	in the original unencapsulated datagram, the datagram is considered		considered to be on the same network as the destination address in
			the original unencapsulated datagram, then the datagram is considered
	to have reached the correct network, but not the correct destination		to have reached the correct network, but not the correct destination
	host within that network.		node within that network.
	4.5. Parameter Problem (Type 12)		4.5. Parameter Problem (Type 12)
	If the parameter problem points to a field copied from the original		If the Parameter Problem message points to a field copied from the
	unencapsulated datagram, the encapsulating agent may relay the ICMP		original unencapsulated datagram, the encapsulator MAY relay the
	message to the source; otherwise, if the problem occurs with an IP		ICMP message to the sender of the original unencapsulated datagram;
	option inserted by the encapsulating agent, then the encapsulating		otherwise, if the problem occurs with an IP option inserted by
	agent must not relay the ICMP message to the source. Note that an		the encapsulator, then the encapsulator MUST NOT relay the ICMP
	encapsulating agent following prevalent current practice will never		message to the original sender. Note that an encapsulator following
	insert any IP options into the encapsulated datagram, except possibly		prevalent current practice will never insert any IP options into the
	for security reasons.		encapsulated datagram, except possibly for security reasons.
	4.6. Other messages		4.6. Other ICMP Messages
	Other ICMP messages are not related to the encapsulation operations		Other ICMP messages are not related to the encapsulation operations
	described within this protocol specification, and should be acted on		described within this protocol specification, and should be acted on
	as specified in [8].		by the encapsulator as specified in [9].
	5. Tunnel Management		5. Tunnel Management
	Unfortunately, ICMP only requires IP routers to return 8 bytes (64		Unfortunately, ICMP only requires IP routers to return 8 octets
	bits) of the datagram beyond the IP header. This is not enough to		(64 bits) of the datagram beyond the IP header. This is not enough
	include the encapsulated header, so it is not always possible for the		to include a copy of the encapsulated (inner) IP header, so it is not
	home agent to immediately reflect the ICMP message from the interior		always possible for the encapsulator to relay the ICMP message from
	of a tunnel back to the originating host.		the interior of a tunnel back to the original sender.
	However, by carefully maintaining "soft state" about its tunnels,		However, by carefully maintaining "soft state" about tunnels into
	the encapsulating router can return accurate ICMP messages in most		which it sends, the encapsulator can return accurate ICMP messages to
	cases. The router SHOULD maintain at least the following soft state		the original sender in most cases. The encapsulator SHOULD maintain
	information about each tunnel:		at least the following soft state information about each tunnel:
	- MTU of the tunnel (subsection 5.1)		- MTU of the tunnel (Section 5.1)
	- TTL (path length) of the tunnel		- TTL (path length) of the tunnel
	- Reachability of the end of the tunnel		- Reachability of the end of the tunnel
	The router uses the ICMP messages it receives from the interior of a		The encapsulator uses the ICMP messages it receives from the interior
	tunnel to update the soft state information for that tunnel. ICMP		of a tunnel to update the soft state information for that tunnel.
	errors that could be received from one of the routers along the		ICMP errors that could be received from one of the routers along the
	tunnel interior include:		tunnel interior include:
	- Datagram Too Big		- Datagram Too Big
	- Time Exceeded		- Time Exceeded
	- Destination Unreachable		- Destination Unreachable
	- Source Quench		- Source Quench
	When subsequent datagrams arrive that would transit the tunnel,		When subsequent datagrams arrive that would transit the tunnel,
	the router checks the soft state for the tunnel. If the datagram		the encapsulator checks the soft state for the tunnel. If the
	would violate the state of the tunnel (such as, the TTL is less than		datagram would violate the state of the tunnel (for example, the TTL
	the tunnel TTL) the router sends an ICMP error message back to the		of the new datagram is less than the tunnel "soft state" TTL) the
	source, but also forwards the datagram into the tunnel.		encapsulator sends an ICMP error message back to the sender of the
			original datagram, but also encapsulates the datagram and forwards it
			into the tunnel.
	Using this technique, the ICMP error messages sent by encapsulating		Using this technique, the ICMP error messages sent by the
	routers will not always match up one-to-one with errors encountered		encapsulator will not always match up one-to-one with errors
	within the tunnel, but they will accurately reflect the state of the		encountered within the tunnel, but they will accurately reflect the
	network.		state of the network.
	Tunnel soft state was originally developed for the IP address		Tunnel soft state was originally developed for the IP Address
	encapsulation (IPAE) specification [4].		Encapsulation (IPAE) specification [4].
	5.1. Tunnel MTU Discovery		5.1. Tunnel MTU Discovery
	When the Don't Fragment bit is set by the originator and copied		When the Don't Fragment bit is set by the originator and copied into
	into the outer IP header, the proper MTU of the tunnel will		the outer IP header, the proper MTU of the tunnel will be learned
	be learned from ICMP (Type 3 Code 4) "Datagram Too Big" errors		from ICMP Datagram Too Big (Type 3, Code 4) messages reported to
	reported to the encapsulator. To support originating hosts		the encapsulator. To support sending nodes which use Path MTU
	which use this capability, all implementations MUST support Path		Discovery, all encapsulator implementations MUST support Path MTU
	MTU Discovery [5, 6] within their tunnels. In this particular		Discovery [5, 7] soft state within their tunnels. In this particular
	application there are several advantages:		application, there are several advantages:
	- As a benefit of Tunnel MTU Discovery, any fragmentation which		- As a benefit of Path MTU Discovery within the tunnel, any
	occurs because of the size of the encapsulation header is		fragmentation which occurs because of the size of the
	performed only once after encapsulation. This prevents multiple		encapsulation header is performed only once after encapsulation.
	fragmentation of a single datagram, which improves processing		This prevents multiple fragmentation of a single datagram, which
	efficiency of the path routers and tunnel decapsulator.		improves processing efficiency of the decapsulator and the
			routers within the tunnel.
	- If the source of the unencapsulated datagram is doing MTU		- If the source of the unencapsulated datagram is doing Path MTU
	discovery then it is desirable for the encapsulator to know the		Discovery, then it is desirable for the encapsulator to know
	MTU to the decapsulator. If it doesn't know the MTU then it		the MTU of the tunnel. Any ICMP Datagram Too Big messages from
	can transfer the DF bit to the outer datagram; however, if that		within the tunnel are returned to the encapsulator, and as noted
	triggers ICMP Datagram Too Big from within the tunnel (and hence		in Section 5, it is not always possible for the encapsulator to
	returned to the encapsulator) the encapsulator cannot always		relay ICMP messages to the source of the original unencapsulated
	return a correct ICMP response to the source unless it has kept		datagram. By maintaining "soft state" about the MTU of the
	state information about recently sent datagrams. If the tunnel		tunnel, the encapsulator can return correct ICMP Datagram Too Big
	MTU is returned to the source by the encapsulator in a Datagram		messages to the original sender of the unencapsulated datagram to
	Too Big message, the MTU that is conveyed SHOULD be the MTU of		support its own Path MTU Discovery. In this case, the MTU that
	the tunnel minus the size of the encapsulating IP header. This		is conveyed to the original sender by the encapsulator SHOULD
	will avoid fragmentation of the original IP datagram by the		be the MTU of the tunnel minus the size of the encapsulating
	encapsulator, something that is otherwise certain to occur.		IP header. This will avoid fragmentation of the original IP
			datagram by the encapsulator.
	- If the source is not doing MTU discovery it is still desirable		- If the source of the original unencapsulated datagram is
	for the encapsulator to know the MTU to the decapsulator. In		not doing Path MTU Discovery, it is still desirable for the
	particular it is much better to fragment the inner datagram than		encapsulator to know the MTU of the tunnel. In particular, it is
	to allow the outer datagram to be fragmented. Fragmenting the		much better to fragment the original datagram when encapsulating,
	inner datagram can be done without special buffer requirements		than to allow the encapsulated datagram to be fragmented.
	and without the need to keep state in the decapsulator.		Fragmenting the original datagram can be done by the encapsulator
	By contrast if the outer datagram is fragmented then the		without special buffer requirements and without the need to
	decapsulator needs to keep state and buffer space on behalf of		keep reassembly state in the decapsulator. By contrast, if
	the destination.		the encapsulated datagram is fragmented, then the decapsulator
			must reassemble the fragmented (encapsulated) datagram before
			decapsulating it, requiring reassembly state and buffer space
			within the decapsulator.
	The encapsulator SHOULD in normal circumstances do MTU discovery		Thus, the encapsulator SHOULD normally do Path MTU Discovery,
	and try to send datagrams with the DF bit set. However there are		requiring it to send all datagrams into the tunnel with the "Don't
	problems with this approach. When the source sets the DF bit it can		Fragment" bit set in the outer IP header. However there are
	react quickly to resend the information if it gets a ICMP Datagram		problems with this approach. When the original sender sets the
	Too Big. When the encapsulator gets a ICMP Datagram Too Big, but the		"Don't Fragment" bit, the sender can react quickly to any returned
	source had not set the DF bit, then there is nothing sensible that		ICMP Datagram Too Big error message by retransmitting the original
	the encapsulator can do to let the source know. The encapsulator MAY		datagram. On the other hand, suppose that the encapsulator receives
	keep a copy of the sent datagram whenever it tries increasing the MTU		an ICMP Datagram Too Big message from within the tunnel. In that
	- this will allow it to resend the datagram fragmented if it gets a		case, if the original sender of the unencapsulated datagram had
	datagram too big response. Alternatively the encapsulator MAY be		not set the "Don't Fragment" bit, there is nothing sensible that
	configured for certain classes of input to not set the DF bit when		the encapsulator can do to let the original sender know of the
	the source has not set the DF bit.		error. The encapsulator MAY keep a copy of the sent datagram
			whenever it tries increasing the tunnel MTU, in order to allow it
			to fragment and resend the datagram if it gets a Datagram Too Big
			response. Alternatively the encapsulator MAY be configured for
			certain types of datagrams not to set the "Don't Fragment" bit when
			the original sender of the unencapsulated datagram has not set the
			"Don't Fragment" bit.
	5.2. Congestion		5.2. Congestion
	Tunnel soft state will collect indications of congestion, such as		An encapsulator might receive indications of congestion from the
	an ICMP (Type 4) Source Quench or a Congestion Experienced flag in		tunnel, for example, by receiving ICMP Source Quench messages from
	datagrams from the decapsulator (tunnel peer). When forwarding		nodes within the tunnel. In addition, certain link layers and
	another datagram into the tunnel, it is appropriate to use approved		various protocols not related to the Internet suite of protocols
	means for controlling congestion [3]; Source Quench messages SHOULD		might provide such indications in the form of a Congestion
	NOT be sent to the originator.		Experienced [6] flag. The encapsulator SHOULD reflect conditions of
			congestion in its "soft state" for the tunnel, and when subsequently
			forwarding datagrams into the tunnel, the encapsulator SHOULD use
			appropriate means for controlling congestion [3]; However, the
			encapsulator SHOULD NOT send ICMP Source Quench messages to the
			original sender of the unencapsulated datagram.
	6. Security Considerations		6. Security Considerations
	IP encapsulation potentially reduces the security of the Internet.		IP encapsulation potentially reduces the security of the Internet,
	For this reason care needs to be taken in the implementation and		and care needs to be taken in the implementation and deployment of
	deployment.		IP encapsulation. For example, IP encapsulation makes it difficult
			for border routers to filter datagrams based on header fields. In
	Assume an organization has good physical control of a secure subset		particular, the original values of the Source Address, Destination
	of its network. Assume that the routers connecting that secure		Address, and Protocol fields in the IP header, and the port numbers
	network do not allow in datagrams with source addresses belonging to		used in any transport header within the datagram, are not located
	interfaces on that secure network. In that situation it is possible		in their normal positions within the datagram after encapsulation.
	to safely deploy protocols within that network which depend on the		Since any IP datagram can be encapsulated and passed through a
	source address of datagrams for authentication purposes.		tunnel, such filtering border routers need to carefully examine all
			datagrams.
	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		6.1. Router Considerations
	Routers need to be aware of IP encapsulation protocols so they can		Routers need to be aware of IP encapsulation protocols in order
	correctly filter incoming datagrams.		to correctly filter incoming datagrams. It is desirable that
			such filtering be integrated with IP authentication [1]. Where IP
	Beyond that it is desirable that filtering be integrated with IP		authentication is used, encapsulated packets might be allowed to
	authentication [1]. In the case of IP encapsulation this can have		enter an organization when the encapsulating (outer) packet or the
	2 forms: Encapsulation might be allowed (in some cases) as long		encapsulated (inner) packet is sent by an authenticated, trusted
	as the encapsulating datagrams authentically come from an expected		source. Encapuslated packets containing no such authentication
	encapsulator. Alternatively encapsulation might be allowed if the		represent a potentially large security risk.
	encapsulated datagrams have authentication.
	Data which is encapsulated and encrypted [2] may also pose a problem.		IP datagrams which are encapsulated and encrypted [2] might also
	In this case the router can only filter the datagram if it knows		pose a problem for filtering routers. In this case, the router can
	the security association. To allow this sort of encryption in		filter the datagram only if it shares the security association used
	environments where all packets need to be filtered (or at least		for the encryption. To allow this sort of encryption in environments
	accounted for) a mechanism must be in place for the receiving host		in which all packets need to be filtered (or at least accounted for),
	to securely communicate the association to the border router. This		a mechanism must be in place for the receiving node to securely
	might, more rarely, also apply to the association used for outgoing		communicate the security association to the border router. This
	datagrams.		might, more rarely, also apply to the security association used for
			outgoing datagrams.
	6.2. Host Considerations		6.2. Host Considerations
	Receiving IP encapsulation software SHOULD classify incoming		Host implementations that are capable of receiving encapsulated IP
	datagrams and only allow datagrams fitting one of the following		datagrams SHOULD admit only those datagrams fitting into one or more
	categories:		of the following categories:
	- The protocol is harmless: source address based authentication is		- The protocol is harmless: source address-based authentication is
	not needed.		not needed.
	- The datagram can be trusted because of trust in the authentically		- The encapsulating (outer) datagram comes from an authentically
	identified encapsulating host. That authentic identification		identified, trusted source. The authenticity of the source could
	could come from physical security plus border router		be established by relying on physical security in addition to
	configuration but is more likely to come from AH authentication.		border router configuration, but is more likely to come from use
			of the IP Authentication header [1].
	- The inner datagram has AH authentication.
	Some or all of this checking could be done in border routers rather		- The encapuslated (inner) datagram includes an IP Authentication
	than the receiving host but it is better if border router checks are		header.
	used as backup rather than being the only check.
	6.3. Using Security Options		- The encapsulated (inner) datagram is addressed to a network
			interface belonging to the decapsulator, or to a node with which
			the decapsulator has entered into a special relationship for
			delivering such encapsulated datagrams.
	The security options of the inner IP header MAY affect the choice of		Some or all of this checking could be done in border routers rather
	security options for the encapsulating IP header.		than the receiving node, but it is better if border router checks are
			used as backup, rather than being the only check.
	7. Acknowledgements		7. Acknowledgements
	Parts of sections 3 and 5 of this document were taken from sections		Parts of Sections 3 and 5 of this document were taken from portions
	(authored by Bill Simpson) of earlier versions of the mobile-IP		(authored by Bill Simpson) of earlier versions of the Mobile IP
	Internet Draft [7]. Good ideas have also been included from RFC		Internet Draft [8]. The original text for section 6 (Security
	1853 [10], also authored by Bill Simpson. "Security Considerations"		Considerations) was contributed by Bob Smart. Good ideas have also
	(section 6) was largely contributed by Bob Smart. Thanks also to		been included from RFC 1853 [11], also authored by Bill Simpson.
	Anders Klemets for finding mistakes and suggesting many improvements		Thanks also to Anders Klemets for finding mistakes and suggesting
	to the draft.		improvements to the draft. Finally, thanks to David Johnson for
			going over the draft with a fine-toothed comb, finding mistakes,
			improving consistency, and making many other improvements to the
			draft.
	References		References
	[1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.		[1] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.
	[2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827,		[2] R. Atkinson. IP Encapsulating Security Payload. RFC 1827,
	August 1995.		August 1995.
	[3] F. Baker, Editor. Requirements for IP Version 4 Routers. RFC		[3] F. Baker, Editor. Requirements for IP Version 4 Routers. RFC
	1812, June 1995.		1812, June 1995.
	[4] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP		[4] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: The SIPP
	Interoperability and Transition Mechanism. Internet Draft --		Interoperability and Transition Mechanism. Internet Draft --
	work in progress, March 1994.		work in progress, March 1994.
	[5] S. Knowles. IESG Advice from Experience with Path MTU		[5] S. Knowles. IESG Advice from Experience with Path MTU
	Discovery. RFC 1435, March 1993.		Discovery. RFC 1435, March 1993.
	[6] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191,		[6] A. Mankin and K. Ramakrishnan. Gateway Congestion Control
			Survey. RFC 1254, August 1991.
			[7] J. Mogul and S. Deering. Path MTU Discovery. RFC 1191,
	November 1990.		November 1990.
	[7] C. Perkins, Editor. ietf-draft-mobileip-protocol-16.txt - work		[8] C. Perkins, Editor. IPv4 Mobility Support.
	in progress. IPv4 Mobility Support, April 1996.		ietf-draft-mobileip-protocol-17.txt (work in progress), May 1996.
	[8] J. B. Postel, Editor. Internet Control Message Protocol. RFC		[9] J. B. Postel, Editor. Internet Control Message Protocol. RFC
	792, September 1981.		792, September 1981.
	[9] J. B. Postel, Editor. Internet Protocol. RFC 791, September		[10] J. B. Postel, Editor. Internet Protocol. RFC 791, September
	1981.		1981.
	[10] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995.		[11] W. Simpson. IP in IP Tunneling. RFC 1853, October 1995.
	Author's Address		Author's Address
	Questions about this memo can be directed to:		Questions about this memo can be directed to:
	Charles Perkins		Charles Perkins
	Room H3-D34		Room H3-D34
	T. J. Watson Research Center		T. J. Watson Research Center
	IBM Corporation		IBM Corporation
	30 Saw Mill River Rd.		30 Saw Mill River Rd.
	Hawthorne, NY 10532		Hawthorne, NY 10532
	Work: +1-914-784-7350		Work: +1-914-784-7350
	Fax: +1-914-784-6205		Fax: +1-914-784-6205
	E-mail: perk@watson.ibm.com		E-mail: perk@watson.ibm.com
	The working group can be contacted via the current chairs:		The working group can be contacted via the current chair:
	Jim Solomon Tony Li		Jim Solomon
	Motorola, Inc. cisco systems		Motorola, Inc.
	1301 E. Algonquin Rd. 170 W. Tasman Dr.		1301 E. Algonquin Rd.
	Schaumburg, IL 60196 San Jose, CA 95134		Schaumburg, IL 60196
	Work: +1-847-576-2753 Work: +1-408-526-8186		Work: +1-847-576-2753
	E-mail: solomon@comm.mot.com E-mail: tli@cisco.com		E-mail: solomon@comm.mot.com
End of changes. 89 change blocks.
	343 lines changed or deleted		384 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/