< draft-floyd-ecn-tunnels-00.txt		draft-floyd-ecn-tunnels-01.txt >
	Internet Engineering Task Force S. Floyd		Internet Engineering Task Force S. Floyd
	INTERNET DRAFT K. K. Ramakrishnan		INTERNET DRAFT K. K. Ramakrishnan
	draft-floyd-ecn-tunnels-00.txt April 2000		draft-floyd-ecn-tunnels-01.txt D. Black
			October 2000
	ECN Interactions with IP Tunnels		ECN Interactions with IP Tunnels
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 41 ¶
	Abstract		Abstract
	The encapsulation of IP packet headers in tunnels is used in many		The encapsulation of IP packet headers in tunnels is used in many
	places, including IPsec and IP in IP [RFC2003]. Explicit Congestion		places, including IPsec and IP in IP [RFC2003]. Explicit Congestion
	Notification (ECN) is an experimental addition to the IP architecture		Notification (ECN) is an experimental addition to the IP architecture
	that uses the ECN field in the IP header to provide an indication of		that uses the ECN field in the IP header to provide an indication of
	the onset of congestion to applications. ECN provides this		the onset of congestion to applications. ECN provides this
	congestion indication to enable end-node adaptation to network		congestion indication to enable end-node adaptation to network
	conditions without the use of dropped packets [RFC 2481]. Currently,		conditions without the use of dropped packets [RFC 2481]. Currently,
	the ECN specification does not accommodate the constraints imposed by		the ECN specification does not accommodate the constraints imposed by
	with some of these pre-existing specifications for tunnels. This		some of these pre-existing specifications for tunnels. This document
	document considers issues related to interactions between ECN and IP		considers issues related to interactions between ECN and IP tunnels,
	tunnels, and proposes two alternative solutions.		and proposes two alternative solutions.
	A different set of issues are raised, relative to ECN, when IP		A different set of issues are raised, relative to ECN, when IP
	packets are encapsulated in tunnels with non-IP packet headers. This		packets are encapsulated in tunnels with non-IP packet headers. This
	occurs with MPLS [MPLS], GRE [GRE], L2TP [L2TP], and PPTP [PPTP].		occurs with MPLS [MPLS], GRE [GRE], L2TP [L2TP], and PPTP [PPTP].
	For these protocols, there is no conflict with ECN; it is just that		For these protocols, there is no conflict with ECN; it is just that
	ECN cannot be used within the tunnel unless an ECN codepoint can be		ECN cannot be used within the tunnel unless an ECN codepoint can be
	specified for the header of the encapsulating protocol. [RFD99]		specified for the header of the encapsulating protocol. [RFD99]
	presents a proposal for incorporating ECN into MPLS, and proposals		presents a proposal for incorporating ECN into MPLS, and proposals
	for incorporating ECN into GRE, L2TP, or PPTP will be considered as		for incorporating ECN into GRE, L2TP, or PPTP will be considered as
	the need arises.		the need arises.
	skipping to change at page 8, line 12 ¶		skipping to change at page 8, line 12 ¶
	explicitly configured to support the full-functionality option, the		explicitly configured to support the full-functionality option, the
	tunnel egress point expects the ECT bit in the outer header to be 0.		tunnel egress point expects the ECT bit in the outer header to be 0.
	When an ECN-capable tunnel egress point receives a packet with the		When an ECN-capable tunnel egress point receives a packet with the
	ECT bit in the outer header set to 1, in a tunnel that has not been		ECT bit in the outer header set to 1, in a tunnel that has not been
	configured to support the full-functionality option, that packet		configured to support the full-functionality option, that packet
	should be processed, according to whether CE bit was set, as follows.		should be processed, according to whether CE bit was set, as follows.
	It is RECOMMENDED that such packets, with the ECT bit set to 1 on a		It is RECOMMENDED that such packets, with the ECT bit set to 1 on a
	tunnel that has not been configured to support the full-functionality		tunnel that has not been configured to support the full-functionality
	option, be dropped at the egress point if CE is set to 1 in the outer		option, be dropped at the egress point if CE is set to 1 in the outer
	header and forwarded if CE is 0 in the outer header.		header but 0 in the inner header, and forwarded otherwise.
	An IP tunnel cannot provide protection against erasure of congestion		An IP tunnel cannot provide protection against erasure of congestion
	indications based on resetting the value of the CE bit in packets for		indications based on resetting the value of the CE bit in packets for
	which ECT is set in the outer header. The erasure of congestion		which ECT is set in the outer header. The erasure of congestion
	indications may impact the network and other flows in ways that would		indications may impact the network and other flows in ways that would
	not be possible in the absence of ECN. It is important to note that		not be possible in the absence of ECN. It is important to note that
	erasure of congestion indications can only be performed to congestion		erasure of congestion indications can only be performed to congestion
	indications placed by nodes within the tunnel; the copy of the CE bit		indications placed by nodes within the tunnel; the copy of the CE bit
	in the inner header preserves congestion notifications from nodes		in the inner header preserves congestion notifications from nodes
	upstream of the tunnel ingress. If erasure of congestion		upstream of the tunnel ingress. If erasure of congestion
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 5 ¶
	field within the tunnel, analyzing all the opportunities for an		field within the tunnel, analyzing all the opportunities for an
	adversary to change the ECN field. In many cases, the change to the		adversary to change the ECN field. In many cases, the change to the
	ECN field is no worse than dropping a packet. However, we noted that		ECN field is no worse than dropping a packet. However, we noted that
	some changes have the more serious consequence of subverting end-to-		some changes have the more serious consequence of subverting end-to-
	end congestion control. However, we point out that even then the		end congestion control. However, we point out that even then the
	potential damage is limited, and is similar to the threat posed by an		potential damage is limited, and is similar to the threat posed by an
	end-system intentionally failing to cooperate with end-to-end		end-system intentionally failing to cooperate with end-to-end
	congestion control. We therefore believe that with these changes it		congestion control. We therefore believe that with these changes it
	is reasonable to use ECN with IP tunnels, as described in RFC 2481.		is reasonable to use ECN with IP tunnels, as described in RFC 2481.
	9. References		9. Acknowledgements
			We thank Tabassum Bint Haque from Dhaka, Bangladesh, for feedback on
			an earlier version of this draft.
			10. References
	[FF98] Floyd, S., and Fall, K., Promoting the Use of End-to-End		[FF98] Floyd, S., and Fall, K., Promoting the Use of End-to-End
	Congestion Control in the Internet, IEEE/ACM Transactions on		Congestion Control in the Internet, IEEE/ACM Transactions on
	Networking, August 1999. URL "http://www-		Networking, August 1999. URL "http://www-
	nrg.ee.lbl.gov/floyd/end2end-paper.html".		nrg.ee.lbl.gov/floyd/end2end-paper.html".
	[GRE] S. Hanks, T. Li, D. Farinacci, and P. Traina, Generic Routing		[GRE] S. Hanks, T. Li, D. Farinacci, and P. Traina, Generic Routing
	Encapsulation (GRE), RFC 1701, October 1994. URL		Encapsulation (GRE), RFC 1701, October 1994. URL
	"http://www.ietf.cnri.reston.va.us/rfc/rfc1701.txt".		"http://www.ietf.cnri.reston.va.us/rfc/rfc1701.txt".
	skipping to change at page 12, line 9 ¶		skipping to change at page 13, line 9 ¶
	[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, Generic		[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, Generic
	Routing Encapsulation (GRE), RFC 1701, October 1994.		Routing Encapsulation (GRE), RFC 1701, October 1994.
	[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, Generic		[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, Generic
	Routing Encapsulation over IPv4 networks, RFC 1702, October 1994.		Routing Encapsulation over IPv4 networks, RFC 1702, October 1994.
	[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom		[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, and Tom
	Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM		Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM
	Computer Communications Review, October 1999.		Computer Communications Review, October 1999.
	10. Security Considerations		11. Security Considerations
	Security considerations have been addressed in the main body of the		Security considerations have been addressed in the main body of the
	document.		document.
	AUTHORS' ADDRESSES		AUTHORS' ADDRESSES
	Sally Floyd		Sally Floyd
	AT&T Center for Internet Research at ICSI (ACIRI)		AT&T Center for Internet Research at ICSI (ACIRI)
	Phone: +1 (510) 666-2989		Phone: +1 (510) 666-2989
	Email: floyd@aciri.org		Email: floyd@aciri.org
	URL: http://www-nrg.ee.lbl.gov/floyd/		URL: http://www-nrg.ee.lbl.gov/floyd/
	K. K. Ramakrishnan		K. K. Ramakrishnan
	AT&T Labs. Research		TeraOptic Networks
	Phone: +1 (973) 360-8766		Phone: +1 (408) 666-8650
	Email: kkrama@research.att.com		Email: kk@teraoptic.com
	URL: http://www.research.att.com/info/kkrama
	This draft was created in April 2000.		David L. Black
	It expires October 2000.		EMC Corporation
			42 South St.
			Hopkinton, MA 01748
			Phone: +1 (508) 435-1000 x75140
			Email: black_david@emc.com
			This draft was created in October 2000.
			It expires April 2001.
End of changes. 7 change blocks.
	11 lines changed or deleted		16 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/