draft-ietf-6man-udpchecksums-04.txt		draft-ietf-6man-udpchecksums-05.txt
	Network Working Group M. Eubanks		Network Working Group M. Eubanks
	Internet-Draft AmericaFree.TV LLC		Internet-Draft AmericaFree.TV LLC
	Updates: 2460 (if approved) P. Chimento		Updates: 2460 (if approved) P. Chimento
	Intended status: Standards Track Johns Hopkins University Applied		Intended status: Standards Track Johns Hopkins University Applied
	Expires: March 9, 2013 Physics Laboratory		Expires: April 25, 2013 Physics Laboratory
	M. Westerlund		M. Westerlund
	Ericsson		Ericsson
	September 5, 2012		October 22, 2012
	UDP Checksums for Tunneled Packets		UDP Checksums for Tunneled Packets
	draft-ietf-6man-udpchecksums-04		draft-ietf-6man-udpchecksums-05
	Abstract		Abstract
	This document provides an update of the Internet Protocol version 6		This document provides an update of the Internet Protocol version 6
	(IPv6) specification (RFC2460) to improve the performance of IPv6 in		(IPv6) specification (RFC2460) to improve the performance of IPv6 in
	the use case when a tunnel protocol uses UDP with IPv6 to tunnel		the use case when a tunnel protocol uses UDP with IPv6 to tunnel
	packets. The performance improvement is obtained by relaxing the		packets. The performance improvement is obtained by relaxing the
	IPv6 UDP checksum requirement for suitable tunneling protocol where		IPv6 UDP checksum requirement for suitable tunneling protocol where
	header information is protected on the "inner" packet being carried.		header information is protected on the "inner" packet being carried.
	This relaxation removes the overhead associated with the computation		This relaxation removes the overhead associated with the computation
	of UDP checksums on IPv6 packets used to carry tunnel protocols and		of UDP checksums on IPv6 packets used to carry tunnel protocols and
	thereby improves the efficiency of the traversal of firewalls and		thereby improves the efficiency of the traversal of firewalls and
	other network middleboxes by such protocols. We describe how the		other network middleboxes by such protocols. We describe how the
	IPv6 UDP checksum requirement can be relaxed in the situation where		IPv6 UDP checksum requirement can be relaxed in the situation where
	the encapsulated packet itself contains a checksum, the limitations		the encapsulated packet itself contains a checksum, the limitations
	and risks of this approach, and defines restrictions on the use of		and risks of this approach, and define restrictions on the use of
	this relaxation to mitigate these risks.		this relaxation to mitigate these risks.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 9, 2013.		This Internet-Draft will expire on April 25, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2. Some Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4		3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
	4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 6		5. The Zero-Checksum Update . . . . . . . . . . . . . . . . . . . 7
	6. Additional Observations . . . . . . . . . . . . . . . . . . . 9		6. Additional Observations . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10		8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . . 9
	10.2. Informative References . . . . . . . . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	This work constitutes an update of the Internet Protocol Version 6		This work constitutes an update of the Internet Protocol Version 6
	(IPv6) Specification [RFC2460], in the use case when a tunnel		(IPv6) Specification [RFC2460], in the use case when a tunnel
	protocol uses UDP with IPv6 to tunnel packets. With the rapid growth		protocol uses UDP with IPv6 to tunnel packets. With the rapid growth
	of the Internet, tunneling protocols have become increasingly		of the Internet, tunneling protocols have become increasingly
	important to enable the deployment of new protocols. Tunneled		important to enable the deployment of new protocols. Tunneled
	protocols can be deployed rapidly, while the time to upgrade and		protocols can be deployed rapidly, while the time to upgrade and
	deploy a critical mass of routers, switches and end hosts on the		deploy a critical mass of routers, switches and end hosts on the
	skipping to change at page 4, line 20		skipping to change at page 4, line 20
	2. Some Terminology		2. Some Terminology
	For the remainder of this document, we discuss only IPv6, since this		For the remainder of this document, we discuss only IPv6, since this
	problem does not exist for IPv4. Therefore all reference to 'IP'		problem does not exist for IPv4. Therefore all reference to 'IP'
	should be understood as a reference to IPv6.		should be understood as a reference to IPv6.
	The document uses the terms "tunneling" and "tunneled" as adjectives		The document uses the terms "tunneling" and "tunneled" as adjectives
	when describing packets. When we refer to 'tunneling packets' we		when describing packets. When we refer to 'tunneling packets' we
	refer to the outer packet header that provides the tunneling		refer to the outer packet header that provides the tunneling
	function. When we refer to 'tunneled packets' we refer to the inner		function. When we refer to 'tunneled packets' we refer to the inner
	packet, i.e. the packet being carried in the tunnel.		packet, i.e., the packet being carried in the tunnel.
	2.1. Requirements Language		2.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Problem Statement		3. Problem Statement
	This document provides an update for the case where a tunnel protocol		This document provides an update for the case where a tunnel protocol
	transports tunnelled packets that already have a UDP header with a		transports tunneled packets that already have a transport header with
	checksum, there is both a benefit and a cost to compute and check the		a checksum. There is both a benefit and a cost to computing and
	UDP checksum of the outer (encapsulating) UDP transport header. In		checking the UDP checksum of the outer (encapsulating) UDP transport
	certain cases, where reducing the forwarding cost is important, such		header. In certain cases, where reducing the forwarding cost is
	as for systems that perform the check in software, the cost may		important, such as for systems that perform the check in software,
	outweigh the benefit; this document describes a means to avoid that		the cost may outweigh the benefit; this document describes a means to
	cost, in the case where there is an inner header with a checksum.		avoid that cost. In the case where there is an inner header with a
			checksum.
	4. Discussion		4. Discussion
	IPv6 UDP Checksum Considerations [I-D.ietf-6man-udpzero] describes		IPv6 UDP Checksum Considerations [I-D.ietf-6man-udpzero] describes
	the issues related to allowing UDP over IPv6 to have a valid checksum		the issues related to allowing UDP over IPv6 to have a valid checksum
	of zero and is not repeated here.		of zero and is not repeated here.
	Section 5.1 of [I-D.ietf-6man-udpzero], identifies 9 requirements		Section 5 and 6 of [I-D.ietf-6man-udpzero], identifies node and inner
	that introduce constraints on the usage of a zero checksum for UDP		protocol requirements respectively that introduce constraints on the
	over IPv6. This document is intended to satisfy these requirements.		usage of a zero checksum for UDP over IPv6. This document is
			intended to satisfy these requirements.
	[I-D.ietf-6man-udpzero] and mailing list discussions have noted there		[I-D.ietf-6man-udpzero] and mailing list discussions have noted there
	is still the possibility of deep-inspection firewall devices or other		is still the possibility of deep-inspection firewall devices or other
	middleboxes checking the UDP checksum field of the outer packet and		middleboxes checking the UDP checksum field of the outer packet and
	thereby discarding the tunneling packets. This would be an issue		thereby discarding the tunneling packets. This would be an issue
	also for any legacy IPv6 system that has not implemented this update		also for any legacy IPv6 system that has not implemented this update
	to the IPv6 specification. In this case, the system (according to		to the IPv6 specification. In this case, the system (according to
	RFC 2460) will discard the zero-checksum UDP packets, and should log		RFC 2460) will discard the zero-checksum UDP packets, and should log
	this as an error.		this as an error.
	The below discuss how path errors can be detected and handled in an		The points below discuss how path errors can be detected and handled
	UDP tunneling protocol when the checksum protection is disabled.		in an UDP tunneling protocol when the checksum protection is
	Note that other (non-tunneling) protocols may have different		disabled. Note that other (non-tunneling) protocols may have
	approaches, but these are not the topic of this update. We propose		different approaches, but these are not the topic of this update. We
	the following approach to handle this problem:		propose the following approach to handle this problem:
	o Context (i.e. tunneling state) should be established via		o Context (i.e. tunneling state) should be established via
	application Protocol Data Units (PDUs) that are carried in		application Protocol Data Units (PDUs) that are carried in
	checksummed UDP packets. That is, any control packets flowing		checksummed UDP packets. That is, any control packets flowing
	between the tunnel endpoints should be protected by UDP checksums.		between the tunnel endpoints should be protected by UDP checksums.
	The control packets can also contain any negotiation required to		The control packets can also contain any negotiation required to
	enable the endpoint/adapters to accept UDP packets with a zero		enable the endpoint/adapters to accept UDP packets with a zero
	checksum. The control packets may also carry any negotiation		checksum. The control packets may also carry any negotiation
	required to enable the endpoint/adapters to identify the set of		required to enable the endpoint/adapters to identify the set of
	ports that need to enable reception UDP datagrams with a zero		ports that need to enable reception of UDP datagrams with a zero
	checksum.		checksum.
	o A system shall not set the UDP checksum to zero in packets that do		o A system never sets the UDP checksum to zero in packets that do
	not contain tunneled packets.		not contain tunneled packets.
	o UDP keep-alive packets with checksum zero can be sent to validate		o UDP keep-alive packets with checksum zero can be sent to validate
	paths, given that paths between tunnel endpoints can change and so		paths, given that paths between tunnel endpoints can change and so
	middleboxes in the path may vary during the life of the		middleboxes in the path may vary during the life of the
	association. Paths with middleboxes that are intolerant of a UDP		association. Paths with middleboxes that are intolerant of a UDP
	checksum of zero will drop the keep-alives and the endpoints will		checksum of zero will drop the keep-alives and the endpoints will
	discover that. Note that this need only be done per tunnel		discover that. Note that this need only be done per tunnel
	endpoint pair, not per tunnel context. Keep-alive traffic should		endpoint pair, not per tunnel context. Keep-alive traffic can
	include both packets with tunnel checksums and packets with		include both packets with tunnel checksums and packets with
	checksums equal to zero to enable the remote end to distinguish		checksums equal to zero to enable the remote end to distinguish
	between path failures and the blockage of packets with checksum		between path failures and the blockage of packets with checksum
	equal to zero.		equal to zero.
	o Corruption of the encapsulating IPv6 source address, destination		o Corruption of the encapsulating IPv6 source address, destination
	address and/or the UDP source port, destination port fields : If		address and/or the UDP source port, and destination port fields :
	the 9 restrictions in [I-D.ietf-6man-udpzero] are followed, the		If the restrictions in [I-D.ietf-6man-udpzero] are followed, the
	inner packets (tunneled packets) should be protected and run the		inner packets (tunneled packets) will be protected and run the
	usual (presumably small) risk of having undetected corruption(s).		usual (presumably small) risk of having undetected corruption(s).
	If tunneling protocol contexts contain (at a minimum) source and		If tunneling protocol contexts contain (at a minimum) source and
	destination IP addresses and source and destination ports, there		destination IP addresses and source and destination ports, there
	are 16 possible corruption outcomes. We note that these outcomes		are 16 possible corruption outcomes. We note that these outcomes
	are not equally likely. The possible corruption outcomes may be:		are not equally likely. The possible corruption outcomes may be:
	* Half of the 16 possible corruption combinations have a		* Half of the 16 possible corruption combinations have a
	corrupted destination address. If the incorrect destination is		corrupted destination address. If the incorrect destination is
	reached and the node doesn't have an application for the		reached and the node doesn't have an application for the
	destination port, the packet will be dropped. If the		destination port, the packet will be dropped. If the
	application at the incorrect destination is the same tunneling		application at the incorrect destination is the same tunneling
	protocol and if it has a matching context (which can be assumed		protocol and if it has a matching context (which can be assumed
	to be a very low probability event) the inner packet will be		to be a very low probability event) the inner packet will be
	decapsulated and forwarded. Application developers should		decapsulated and forwarded. Application developers can verify
	verify the context of the packets they receive using UDP, as		the context of the packets they receive using UDP, as described
	described in [RFC5405]. Applications that verify the context		in [RFC5405]. Applications that verify the context of a
	of a datagram are expected to have a high probability of		datagram are expected to have a high probability of discarding
	discarding corrupted data. [I-D.ietf-6man-udpzero] presents		corrupted data. [I-D.ietf-6man-udpzero] presents examples of
	examples of cases where corruption can inadvertently impact		cases where corruption can inadvertently impact application
	application state.		state.
	* Half of the 8 possible corruption combinations with a correct		* Half of the 8 possible corruption combinations with a correct
	destination address have a corrupted source address. If the		destination address have a corrupted source address. If the
	tunnel contexts contain all elements of the address-port		tunnel contexts contain all elements of the address-port
	4-tuple, then the likelihood is that this corruption will be		4-tuple, then the likelihood is that this corruption will be
	detected.		detected. It may in fact be discarded on route due to source
			address validation techniques, such as Unicast Reverse Path
			Forwarding [RFC2827].
	* Of the remaining 4 possibilities, with valid source and		* Of the remaining 4 possibilities, with valid source and
	destination IPv6 addresses, 1 has all 4 fields valid, the other		destination IPv6 addresses, one has all 4 fields valid, the
	three have one or both ports corrupted. Again, if the		other three have one or both ports corrupted. Again, if the
	tunneling endpoint context contains sufficient information,		tunneling endpoint context contains sufficient information,
	these error should be detected with high probability.		these errors should be detected with high probability.
	o Corruption of source-fragmented encapsulating packets: In this		o Corruption of source-fragmented encapsulating packets: In this
	case, a tunneling protocol may reassemble fragments associated		case, a tunneling protocol may reassemble fragments associated
	with the wrong context at the right tunnel endpoint, or it may		with the wrong context at the right tunnel endpoint, or it may
	reassemble fragments associated with a context at the wrong tunnel		reassemble fragments associated with a context at the wrong tunnel
	endpoint, or corrupted fragments may be reassembled at the right		endpoint, or corrupted fragments may be reassembled at the right
	context at the right tunnel endpoint. In each of these cases, the		context at the right tunnel endpoint. In each of these cases, the
	IPv6 length of the encapsulating header may be checked (though		IPv6 length of the encapsulating header may be checked (though
	[I-D.ietf-6man-udpzero] points out the weakness in this check).		[I-D.ietf-6man-udpzero] points out the weakness in this check).
	In addition, if the encapsulated packet is protected by a		In addition, if the encapsulated packet is protected by a
	skipping to change at page 7, line 6		skipping to change at page 7, line 10
	some probability).		some probability).
	While they do not guarantee correctness, these mechanism can reduce		While they do not guarantee correctness, these mechanism can reduce
	the risks of relaxing the UDP checksum requirement for IPv6.		the risks of relaxing the UDP checksum requirement for IPv6.
	5. The Zero-Checksum Update		5. The Zero-Checksum Update
	This specification updates IPv6 to allow a UDP checksum of zero for		This specification updates IPv6 to allow a UDP checksum of zero for
	the outer encapsulating packet of a tunneling protocol. UDP		the outer encapsulating packet of a tunneling protocol. UDP
	endpoints that implement this update MUST change their behavior for		endpoints that implement this update MUST change their behavior for
	any destination port explicitly configured for zero checksum and not		any destination port explicitly configured for zero checksum and MUST
	discard UDP packets received with a checksum value of zero on the		NOT discard UDP packets received with a checksum value of zero on the
	outer packet. When this is done, it requires the constraints in		outer packet. When this is done, it requires the constraints in
	Section 5.1 of [I-D.ietf-6man-udpzero].		Section 5 and 6 of [I-D.ietf-6man-udpzero].
	Specifically, the text in [RFC2460] Section 8.1, 4th bullet is		Specifically, the text in [RFC2460] Section 8.1, 4th bullet is
	updated. We refer to the following text:		updated. We refer to the following text:
	"Unlike IPv4, when UDP packets are originated by an IPv6 node, the		"Unlike IPv4, when UDP packets are originated by an IPv6 node, the
	UDP checksum is not optional. That is, whenever originating a UDP		UDP checksum is not optional. That is, whenever originating a UDP
	packet, an IPv6 node must compute a UDP checksum over the packet and		packet, an IPv6 node must compute a UDP checksum over the packet and
	the pseudo-header, and, if that computation yields a result of zero,		the pseudo-header, and, if that computation yields a result of zero,
	it must be changed to hex FFFF for placement in the UDP header. IPv6		it must be changed to hex FFFF for placement in the UDP header. IPv6
	receivers must discard UDP packets containing a zero checksum, and		receivers must discard UDP packets containing a zero checksum, and
	skipping to change at page 7, line 33		skipping to change at page 7, line 37
	replaced by:		replaced by:
	Whenever originating a UDP packet, an IPv6 node SHOULD compute a		Whenever originating a UDP packet, an IPv6 node SHOULD compute a
	UDP checksum over the packet and the pseudo-header, and, if that		UDP checksum over the packet and the pseudo-header, and, if that
	computation yields a result of zero, it must be changed to hex		computation yields a result of zero, it must be changed to hex
	FFFF for placement in the UDP header. IPv6 receivers SHOULD		FFFF for placement in the UDP header. IPv6 receivers SHOULD
	discard UDP packets containing a zero checksum, and SHOULD log the		discard UDP packets containing a zero checksum, and SHOULD log the
	error. However, some protocols, such as tunneling protocols that		error. However, some protocols, such as tunneling protocols that
	use UDP as a tunnel encapsulation, MAY omit computing the UDP		use UDP as a tunnel encapsulation, MAY omit computing the UDP
	checksum of the encapsulating UDP header and set it to zero,		checksum of the encapsulating UDP header and set it to zero,
	subject to the constraints described in RFCXXXX. In cases where		subject to the constraints described in Applicability Statement
	the encapsulating protocol uses a zero checksum for UDP, the		for the use of IPv6 UDP Datagrams with Zero Checksums
	receiver of packets sent to a port enabled to receive zero-		[I-D.ietf-6man-udpzero]. In cases where the encapsulating
	checksum packets MUST NOT discard packets solely for having a UDP		protocol uses a zero checksum for UDP, the receiver of packets
	checksum of zero. Note that these constraints apply only to		sent to a port enabled to receive zero-checksum packets MUST NOT
	encapsulating protocols that omit calculating the UDP checksum and		discard packets solely for having a UDP checksum of zero. Note
	set it to zero. An encapsulating protocol can always choose to		that these constraints apply only to encapsulating protocols that
	compute the UDP checksum, in which case, its behavior is not		omit calculating the UDP checksum and set it to zero. An
	updated and uses the method specified in RFC2460.		encapsulating protocol can always choose to compute the UDP
			checksum, in which case, its behavior is not updated and uses the
	1. IPv6 protocol stack implementations SHOULD NOT by default		method specified in Section 8.1 of RFC2460.
	allow the new method. The default node receiver behavior MUST
	discard all IPv6 packets carrying UDP packets with a zero
	checksum.
	2. Implementations MUST provide a way to signal the set of ports
	that will be enabled to receive UDP datagrams with a zero
	checksum. An IPv6 node that enables reception of UDP packets
	with a zero-checksum, MUST enable this only for a specific
	port or port-range. This may be implemented via a socket API
	call, or similar mechanism.
	3. RFC 2460 specifies that IPv6 nodes should log UDP datagrams
	with a zero-checksum. A port for which zero-checksum has been
	enabled MUST NOT log zero-checksum datagrams for that reason
	(of course, there might be other reasons to log such packets).
	4. A stack may separately identify UDP datagrams that are
	discarded with a zero checksum. It SHOULD NOT add these to
	the standard log, since the endpoint has not been verified.
	5. UDP Tunnels that encapsulate IP MAY rely on the inner packet
	integrity checks provided that the tunnel will not
	significantly increase the rate of corruption of the inner IP
	packet. If a significantly increased corruption rate can
	occur, then the tunnel MUST provide an additional integrity
	verification mechanism. An integrity mechanism is always
	recommended at the tunnel layer to ensure that corruption
	rates of the inner most packet are not increased.
	6. Tunnels that encapsulate Non-IP packets MUST have a CRC or
	other mechanism for checking packet integrity, unless the
	Non-IP packet specifically is designed for transmission over
	lower layers that do not provide any packet integrity
	guarantee. In particular, the application must be designed so
	that corruption of this information does not result in
	accumulated state or incorrect processing of a tunneled
	payload.
	7. UDP applications that support use of a zero-checksum, SHOULD
	NOT rely upon correct reception of the IP and UDP protocol
	information (including the length of the packet) when decoding
	and processing the packet payload. In particular, the
	application must be designed so that corruption of this
	information does not result in accumulated state or incorrect
	processing of a tunneled payload.
	8. If a method proposes recursive tunnels, it MUST provide
	guidance that is appropriate for all use-cases. Restrictions
	may be needed to the use of a tunnel encapsulations and the
	use of recursive tunnels (e.g. Necessary when the endpoint is
	not verified).
	9. IPv6 nodes that receive ICMPv6 messages that refer to packets
	with a zero UDP checksum MUST provide appropriate checks
	concerning the consistency of the reported packet to verify
	that the reported packet actually originated from the node,
	before acting upon the information (e.g. validating the
	address and port numbers in the ICMPv6 message body).
	Middleboxes MUST allow IPv6 packets with UDP checksum equal to		Middleboxes MUST allow IPv6 packets with UDP checksum equal to
	zero to pass. Implementations of middleboxes MAY allow		zero to pass. Implementations of middleboxes MAY allow
	configuration of specific port ranges for which a zero UDP		configuration of specific port ranges for which a zero UDP
	checksum is valid and may drop IPv6 UDP packets outside those		checksum is valid and may drop IPv6 UDP packets outside those
	ranges.		ranges.
	The path between tunnel endpoints can change, thus also the		The path between tunnel endpoints can change, thus also the
	middleboxes in the path may vary during the life of the		middleboxes in the path may vary during the life of the
	association. Paths with middleboxes that are intolerant of a UDP		association. Paths with middleboxes that are intolerant of a UDP
	checksum of zero will drop any keep-alives sent to validate the		checksum of zero will drop any keep-alives sent to validate the
	path using checksum zero and the endpoints will discover that.		path using checksum zero and the endpoints will discover that.
	Therefore keep-alive traffic SHOULD include both packets with		Therefore keep-alive traffic SHOULD include both packets with
	tunnel checksums and packets with checksums equal to zero to		tunnel checksums and packets with checksums equal to zero to
	enable the remote end to distinguish between path failures and the		enable the remote end to distinguish between path failures and the
	blockage of packets with checksum equal to zero. Note that path		blockage of packets with checksum equal to zero. Note that path
	validation need only be done per tunnel endpoint pair, not per		validation need only be done per tunnel endpoint pair, not per
	tunnel context.		tunnel context.
	RFC-Editor Note: Please replace RFCXXXX above with the RFC number
	this specification receives and remove this note.
	6. Additional Observations		6. Additional Observations
	The existence of this issue among a significant number of protocols		The existence of this issue among a significant number of protocols
	being developed in the IETF motivates this specified change. The		being developed in the IETF motivates this specified change. The
	authors would also like to make the following observations:		authors would also like to make the following observations:
	o An empirically-based analysis of the probabilities of packet		o An empirically-based analysis of the probabilities of packet
	corruptions (with or without checksums) has not (to our knowledge)		corruptions (with or without checksums) has not (to our knowledge)
	been conducted since about 2000. It is now 2012. We strongly		been conducted since about 2000. It is now 2012. We strongly
	suggest that an empirical study is in order, along with an		suggest that an empirical study is in order, along with an
	skipping to change at page 10, line 23		skipping to change at page 9, line 10
	This document makes no request of IANA.		This document makes no request of IANA.
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	8. Security Considerations		8. Security Considerations
	It requires less work to generate zero-checksum attack packets than		It requires less work to generate zero-checksum attack packets than
	ones with full UDP checksums. However, this does not lead to any		ones with full UDP checksums. However, this does not lead to any
	significant new vulnerabilities as checksums are not a security		significant new vulnerabilities as checksums are not a security
	measure and can be easily generated by any attacker, as properly		measure and can be easily generated by any attacker. Properly
	configured tunnels should check the validity of the inner packet and		configured tunnels should check the validity of the inner packet and
	perform any needed security checks, regardless of the checksum		perform any needed security checks, regardless of the checksum
	status, and finally as most attacks are generated from compromised		status. Most attacks are generated from compromised hosts which
	hosts which automatically create checksummed packets (in other words,		automatically create checksummed packets (in other words, it would
	it would generally be more, not less, effort for most attackers to		generally be more, not less, effort for most attackers to generate
	generate zero UDP checksums on the host).		zero UDP checksums on the host).
	9. Acknowledgements		9. Acknowledgements
	We would like to thank Brian Haberman and Gorry Fairhurst for		We would like to thank Brian Haberman and Gorry Fairhurst for
	discussions and reviews.		discussions and reviews.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
			[I-D.ietf-6man-udpzero]
			Fairhurst, G. and M. Westerlund, "Applicability Statement
			for the use of IPv6 UDP Datagrams with Zero Checksums",
			draft-ietf-6man-udpzero-07 (work in progress),
			October 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and		[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
	G. Fairhurst, "The Lightweight User Datagram Protocol		G. Fairhurst, "The Lightweight User Datagram Protocol
	(UDP-Lite)", RFC 3828, July 2004.		(UDP-Lite)", RFC 3828, July 2004.
	[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent,		[RFC5619] Yamamoto, S., Williams, C., Yokota, H., and F. Parent,
	"Softwire Security Analysis and Requirements", RFC 5619,		"Softwire Security Analysis and Requirements", RFC 5619,
	August 2009.		August 2009.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-6man-udpzero]
	Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum
	Considerations", draft-ietf-6man-udpzero-06 (work in
	progress), June 2012.
	[I-D.ietf-lisp]		[I-D.ietf-lisp]
	Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,		Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",		"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-23 (work in progress), May 2012.		draft-ietf-lisp-23 (work in progress), May 2012.
	[I-D.ietf-mboned-auto-multicast]		[I-D.ietf-mboned-auto-multicast]
	Bumgardner, G., "Automatic Multicast Tunneling",		Bumgardner, G., "Automatic Multicast Tunneling",
	draft-ietf-mboned-auto-multicast-14 (work in progress),		draft-ietf-mboned-auto-multicast-14 (work in progress),
	June 2012.		June 2012.
			[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
			Defeating Denial of Service Attacks which employ IP Source
			Address Spoofing", BCP 38, RFC 2827, May 2000.
	[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines		[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
	for Application Designers", BCP 145, RFC 5405,		for Application Designers", BCP 145, RFC 5405,
	November 2008.		November 2008.
	Authors' Addresses		Authors' Addresses
	Marshall Eubanks		Marshall Eubanks
	AmericaFree.TV LLC		AmericaFree.TV LLC
	P.O. Box 141		P.O. Box 141
	Clifton, Virginia 20124		Clifton, Virginia 20124
	skipping to change at page 12, line 4		skipping to change at page 10, line 31
	Marshall Eubanks		Marshall Eubanks
	AmericaFree.TV LLC		AmericaFree.TV LLC
	P.O. Box 141		P.O. Box 141
	Clifton, Virginia 20124		Clifton, Virginia 20124
	USA		USA
	Phone: +1-703-501-4376		Phone: +1-703-501-4376
	Fax:		Fax:
	Email: marshall.eubanks@gmail.com		Email: marshall.eubanks@gmail.com
	P.F. Chimento		P.F. Chimento
	Johns Hopkins University Applied Physics Laboratory		Johns Hopkins University Applied Physics Laboratory
	11100 Johns Hopkins Road		11100 Johns Hopkins Road
	Laurel, MD 20723		Laurel, MD 20723
	USA		USA
	Phone: +1-443-778-1743		Phone: +1-443-778-1743
	Fax:
	Email: Philip.Chimento@jhuapl.edu		Email: Philip.Chimento@jhuapl.edu
	URI:
	Magnus Westerlund		Magnus Westerlund
	Ericsson		Ericsson
	Farogatan 6		Farogatan 6
	SE-164 80 Kista		SE-164 80 Kista
	Sweden		Sweden
	Phone: +46 10 714 82 87		Phone: +46 10 714 82 87
	Email: magnus.westerlund@ericsson.com		Email: magnus.westerlund@ericsson.com
End of changes. 30 change blocks.
	135 lines changed or deleted		81 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/