draft-ietf-6man-oversized-header-chain-07.txt		draft-ietf-6man-oversized-header-chain-08.txt
	IPv6 maintenance Working Group (6man) F. Gont		IPv6 maintenance Working Group (6man) F. Gont
	Internet-Draft SI6 Networks / UTN-FRH		Internet-Draft SI6 Networks / UTN-FRH
	Updates: 2460 (if approved) V. Manral		Updates: 2460 (if approved) V. Manral
	Intended status: Standards Track Hewlett-Packard Corp.		Intended status: Standards Track Hewlett-Packard Corp.
	Expires: March 14, 2014 R. Bonica		Expires: April 5, 2014 R. Bonica
	Juniper Networks		Juniper Networks
	September 10, 2013		October 2, 2013
	Implications of Oversized IPv6 Header Chains		Implications of Oversized IPv6 Header Chains
	draft-ietf-6man-oversized-header-chain-07		draft-ietf-6man-oversized-header-chain-08
	Abstract		Abstract
	The IPv6 specification allows IPv6 header chains of an arbitrary		The IPv6 specification allows IPv6 header chains of an arbitrary
	size. The specification also allows options which can in turn extend		size. The specification also allows options which can in turn extend
	each of the headers. In those scenarios in which the IPv6 header		each of the headers. In those scenarios in which the IPv6 header
	chain or options are unusually long and packets are fragmented, or		chain or options are unusually long and packets are fragmented, or
	scenarios in which the fragment size is very small, the first		scenarios in which the fragment size is very small, the first
	fragment of a packet may fail to include the entire IPv6 header		fragment of a packet may fail to include the entire IPv6 header
	chain. This document discusses the interoperability and security		chain. This document discusses the interoperability and security
	skipping to change at page 1, line 42		skipping to change at page 1, line 42
	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 14, 2014.		This Internet-Draft will expire on April 5, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	skipping to change at page 7, line 15		skipping to change at page 7, line 15
	4. Motivation		4. Motivation
	Many forwarding devices implement stateless firewalls. A stateless		Many forwarding devices implement stateless firewalls. A stateless
	firewall enforces a forwarding policy on packet-by-packet basis. In		firewall enforces a forwarding policy on packet-by-packet basis. In
	order to enforce its forwarding policy, the stateless firewall may		order to enforce its forwarding policy, the stateless firewall may
	need to glean information from both the IPv6 and upper-layer headers.		need to glean information from both the IPv6 and upper-layer headers.
	For example, assume that a stateless firewall discards all traffic		For example, assume that a stateless firewall discards all traffic
	received from an interface unless it destined for a particular TCP		received from an interface unless it destined for a particular TCP
	port on a particular IPv6 address. When this firewall is presented		port on a particular IPv6 address. When this firewall is presented
	with a fragmented packet, and the entire header chain is contained		with a fragmented packet that is destined for a different TCP port,
	within the first fragment, the firewall discards the first fragment		and the entire header chain is contained within the first fragment,
	and allows subsequent fragments to pass. Because the first fragment		the firewall discards the first fragment and allows subsequent
	was discarded, the packet cannot be reassembled at the destination.		fragments to pass. Because the first fragment was discarded, the
	Insomuch as the packet cannot be reassembled, the forwarding policy		packet cannot be reassembled at the destination. Insomuch as the
	is enforced.		packet cannot be reassembled, the forwarding policy is enforced.
	However, when the firewall is presented with a fragmented packet and		However, when the firewall is presented with a fragmented packet and
	the header chain spans multiple fragments, the first fragment does		the header chain spans multiple fragments, the first fragment does
	not contain enough information for the firewall to enforce its		not contain enough information for the firewall to enforce its
	forwarding policy. Lacking sufficient information, the stateless		forwarding policy. Lacking sufficient information, the stateless
	firewall either forwards or discards that fragment. Regardless of		firewall either forwards or discards that fragment. Regardless of
	the action that it takes, it may fail to enforce its forwarding		the action that it takes, it may fail to enforce its forwarding
	policy.		policy.
	5. Updates to RFC 2460		5. Updates to RFC 2460
	When a host fragments a IPv6 datagram, it MUST include the entire		When a host fragments a IPv6 datagram, it MUST include the entire
	header chain in the first fragment.		header chain in the first fragment.
	A host that receives a first-fragment that does not satisfy the		A host that receives a first-fragment that does not satisfy the
	above-stated requirement SHOULD discard that packet, and also MAY		above- stated requirement SHOULD discard the packet (e.g., including
	send an ICMPv6 error message to the source address of the offending		a configuration option that allows such fragments to be accepted for
	packet (subject to the rules for ICMPv6 errors specified in		backwards compatibility) and SHOULD send an ICMPv6 error message to
	[RFC4443]).		the source address of the offending packet (subject to the rules for
			ICMPv6 errors specified in [RFC4443]).
	Likewise, an intermediate system (e.g. router, firewall) that		Likewise, an intermediate system (e.g. router, firewall) that
	receives an IPv6 first-fragment that does not satisfy the above-		receives an IPv6 first-fragment that does not satisfy the above-
	stated requirements MAY discard that packet, and MAY send an ICMPv6		stated requirements MAY discard that packet, and MAY send an ICMPv6
	error message to the source address of the offending packet (subject		error message to the source address of the offending packet (subject
	to the rules for ICMPv6 error messages specified in [RFC4443]).		to the rules for ICMPv6 error messages specified in [RFC4443]).
	Intermediate systems having this capability SHOULD support		Intermediate systems having this capability SHOULD support
	configuration (e.g. enable/disable) of whether such packets are		configuration (e.g. enable/disable) of whether such packets are
	dropped or not by the intermediate system.		dropped or not by the intermediate system.
	If a host or intermediate system discards a first-fragment because it		If a host or intermediate system discards a first-fragment because it
	does not satisfy the above-stated requirements, and sends an ICMPv6		does not satisfy the above-stated requirements, and sends an ICMPv6
	error message due to the discard, then the ICMPv6 error message MUST		error message due to the discard, then the ICMPv6 error message MUST
	be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-		be Type 4 ("Parameter Problem") and MUST use Code TBD ("First-
	fragment has incomplete IPv6 Header Chain"). The Pointer field		fragment has incomplete IPv6 Header Chain"). The Pointer field
	contained by the ICMPv6 Parameter Problem message MUST be set to		contained by the ICMPv6 Parameter Problem message MUST be set to
	zero.		zero. Whether a host or intermediate system originates this ICMP
			message, its format is identical.
	As a result of the above mentioned requirements, a packet's header		As a result of the above mentioned requirements, a packet's header
	chain length cannot exceed the Path MTU associated with its		chain length cannot exceed the Path MTU associated with its
	destination. Hosts MAY discover the Path MTU, using procedures such		destination. Hosts MAY discover the Path MTU, using procedures such
	as those defined in [RFC1981] and [RFC4821]. However, if a host does		as those defined in [RFC1981] and [RFC4821]. However, if a host does
	not discover the Path MTU, it MUST limit the header chain length to		not discover the Path MTU, it MUST limit the header chain length to
	1280 bytes. Limiting the header chain length to 1280 bytes ensures		1280 bytes. Limiting the header chain length to 1280 bytes ensures
	that the header chain length does not exceed the IPv6 minimum MTU.		that the header chain length does not exceed the IPv6 minimum MTU
			[RFC2460].
	6. IANA Considerations		6. IANA Considerations
	IANA is requested to add a the following entry to the "Reason Code"		IANA is requested to add a the following entry to the "Reason Code"
	registry for ICMPv6 "Type 4 - Parameter Problem" messages:		registry for ICMPv6 "Type 4 - Parameter Problem" messages:
	CODE NAME/DESCRIPTION		CODE NAME/DESCRIPTION
	TBD IPv6 first-fragment has incomplete IPv6 header chain		TBD IPv6 first-fragment has incomplete IPv6 header chain
	7. Security Considerations		7. Security Considerations
	skipping to change at page 12, line 28		skipping to change at page 12, line 28
	[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control		[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
	Message Protocol (ICMPv6) for the Internet Protocol		Message Protocol (ICMPv6) for the Internet Protocol
	Version 6 (IPv6) Specification", RFC 4443, March 2006.		Version 6 (IPv6) Specification", RFC 4443, March 2006.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, March 2007.		Discovery", RFC 4821, March 2007.
	[I-D.ietf-6man-ext-transmit]		[I-D.ietf-6man-ext-transmit]
	Carpenter, B. and S. Jiang, "Transmission and Processing		Carpenter, B. and S. Jiang, "Transmission and Processing
	of IPv6 Extension Headers",		of IPv6 Extension Headers",
	draft-ietf-6man-ext-transmit-03 (work in progress),		draft-ietf-6man-ext-transmit-04 (work in progress),
	August 2013.		September 2013.
	9.2. Informative References		9.2. Informative References
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, May 2000.		Address Spoofing", BCP 38, RFC 2827, May 2000.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", BCP 84, RFC 3704, March 2004.		Networks", BCP 84, RFC 3704, March 2004.
End of changes. 9 change blocks.
	18 lines changed or deleted		21 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/