draft-ietf-6man-ext-transmit-02.txt		draft-ietf-6man-ext-transmit-03.txt
	6man B. Carpenter		6man B. Carpenter
	Internet-Draft Univ. of Auckland		Internet-Draft Univ. of Auckland
	Updates: 2460, 2780 (if approved) S. Jiang		Updates: 2460, 2780 (if approved) S. Jiang
	Intended status: Standards Track Huawei Technologies Co., Ltd		Intended status: Standards Track Huawei Technologies Co., Ltd
	Expires: February 07, 2014 August 06, 2013		Expires: February 23, 2014 August 22, 2013
	Transmission of IPv6 Extension Headers		Transmission and Processing of IPv6 Extension Headers
	draft-ietf-6man-ext-transmit-02		draft-ietf-6man-ext-transmit-03
	Abstract		Abstract
	Various IPv6 extension headers have been standardised since the IPv6		Various IPv6 extension headers have been standardised since the IPv6
	standard was first published. This document updates RFC 2460 to		standard was first published. This document updates RFC 2460 to
	clarify how intermediate nodes should deal with such extension		clarify how intermediate nodes should deal with such extension
	headers and with any that are defined in future. It also specifies		headers and with any that are defined in future. It also specifies
	how extension headers should be registered by IANA, with a		how extension headers should be registered by IANA, with a
	corresponding minor update to RFC 2780.		corresponding minor update to RFC 2780.
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 February 07, 2014.		This Internet-Draft will expire on February 23, 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 2, line 14		skipping to change at page 2, line 14
	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 and Problem Statement . . . . . . . . . . . . . 2		1. Introduction and Problem Statement . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Requirement to Transmit Extension Headers . . . . . . . . . . 4		2. Requirement to Transmit Extension Headers . . . . . . . . . . 4
	2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 4		2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 4
	2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 5		2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 5
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 5		3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7		6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . 8
	7.2. Informative References . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction and Problem Statement		1. Introduction and Problem Statement
	In IPv6, an extension header is any header that follows the initial		In IPv6, an extension header is any header that follows the initial
	40 bytes of the packet and precedes the upper layer header (which		40 bytes of the packet and precedes the upper layer header (which
	might be a transport header, an ICMPv6 header, or a notional "No Next		might be a transport header, an ICMPv6 header, or a notional "No Next
	Header").		Header").
	An initial set of IPv6 extension headers was defined by [RFC2460],		An initial set of IPv6 extension headers was defined by [RFC2460],
	skipping to change at page 2, line 44		skipping to change at page 2, line 44
	"...extension headers are not examined or processed		"...extension headers are not examined or processed
	by any node along a packet's delivery path, until the packet reaches		by any node along a packet's delivery path, until the packet reaches
	the node (or each of the set of nodes, in the case of multicast)		the node (or each of the set of nodes, in the case of multicast)
	identified in the Destination Address field of the IPv6 header."		identified in the Destination Address field of the IPv6 header."
	This provision meant that forwarding nodes should be completely		This provision meant that forwarding nodes should be completely
	transparent to extension headers. There was no provision for		transparent to extension headers. There was no provision for
	forwarding nodes to modify them, remove them, insert them, or use		forwarding nodes to modify them, remove them, insert them, or use
	them to affect forwarding behaviour. Thus, new extension headers		them to affect forwarding behaviour. Thus, new extension headers
	could be introduced progressively, used only by hosts that have been		could be introduced progressively, used only by hosts that have been
	updated to create and interpret them. The extension header mechanism		updated to create and interpret them [RFC6564]. The extension header
	is an important part of the IPv6 architecture, and several new		mechanism is an important part of the IPv6 architecture, and several
	extension headers have been standardised since RFC 2460.		new extension headers have been standardised since RFC 2460.
	Today, packets are often forwarded not only by straightforward IP		Today, packets are often forwarded not only by straightforward IP
	routers, but also by a variety of intermediate nodes, often referred		routers, but also by a variety of intermediate nodes, often referred
	to as middleboxes, such as firewalls, load balancers, or packet		to as middleboxes, such as firewalls, load balancers, or packet
	classifiers. Unfortunately, experience has showed that as a result,		classifiers. However, experience has showed that as a result, the
	the network is not transparent to IPv6 extension headers. Contrary		network is not transparent to IPv6 extension headers. Contrary to
	to Section 4 of RFC 2460, middleboxes sometimes examine and process		Section 4 of RFC 2460, middleboxes sometimes examine and process the
	the entire IPv6 packet before making a decision to either forward or		entire IPv6 packet before making a decision to either forward or
	discard the packet. This means that they need to traverse the chain		discard the packet. This means that they need to traverse the chain
	of extension headers, if present, until they find the transport		of extension headers, if present, until they find the transport
	header (or an encrypted payload). Unfortunately, because not all		header (or an encrypted payload). Unfortunately, because not all
	IPv6 extension headers follow a uniform TLV format, this process is		IPv6 extension headers follow a uniform TLV format, this process is
	clumsy and requires knowledge of each extension header's format.		clumsy and requires knowledge of each extension header's format. A
			separate problem is that the header chain may even be fragmented
			[I-D.ietf-6man-oversized-header-chain].
	The process is potentially slow as well as clumsy, possibly		The process is potentially slow as well as clumsy, possibly
	precluding its use in nodes attempting to process packets at line		precluding its use in nodes attempting to process packets at line
	speed. The present document does not intend to solve this problem,		speed. The present document does not intend to solve this problem,
	which is caused by the fundamental architecture of IPv6 extension		which is caused by the fundamental architecture of IPv6 extension
	headers. This document focuses on clarifying how the header chain		headers. This document focuses on clarifying how the header chain
	should be traversed in the current IPv6 architecture.		should be traversed in the current IPv6 architecture.
	If they encounter an unrecognised extension header type, some		If they encounter an unrecognised extension header type, some
	firewalls treat the packet as suspect and drop it. Unfortunately, it		firewalls treat the packet as suspect and drop it. Unfortunately, it
	is an established fact that several widely used firewalls do not		is an established fact that several widely used firewalls do not
	recognise some or all of the extension headers standardised since RFC		recognise some or all of the extension headers standardised since RFC
	2460. It has also been observed that certain firewalls do not even		2460. It has also been observed that certain firewalls do not even
	handle all the extension headers standardised in RFC 2460, including		handle all the extension headers standardised in RFC 2460, including
	the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental		the fragment header [I-D.taylor-v6ops-fragdrop], causing fundamental
	problems of connectivity. This applies in particular to firewalls		problems of end-to-end connectivity. This applies in particular to
	that attempt to inspect packets statelessly at very high speed, since		firewalls that attempt to inspect packets at very high speed, since
	they cannot take the time to reassemble fragmented packets,		they cannot take the time to reassemble fragmented packets,
	especially when under a denial of service attack.		especially when under a denial of service attack.
	Other types of middlebox, such as load balancers or packet		Other types of middlebox, such as load balancers or packet
	classifiers, might also fail in the presence of extension headers		classifiers, might also fail in the presence of extension headers
	that they do not recognise.		that they do not recognise.
	A contributory factor to this problem is that, because extension		A contributory factor to this problem is that, because extension
	headers are numbered out of the existing IP Protocol Number space,		headers are numbered out of the existing IP Protocol Number space,
	there is no collected list of them. For this reason, it is hard for		there is no collected list of them. For this reason, it is hard for
	an implementor to quickly identify the full set of standard extension		an implementor to quickly identify the full set of standard extension
	headers. An implementor who consults only RFC 2460 will miss all		headers. An implementor who consults only RFC 2460 will miss all
	extension headers defined subsequently.		extension headers defined subsequently.
	This combination of circumstances creates a "Catch-22" situation		This combination of circumstances creates a "Catch-22" situation
	[Heller] for the deployment of any newly standardised extension		[Heller] for the deployment of any newly standardised extension
	header except for local use. It cannot be widely deployed, because		header except for local use. It cannot be widely deployed, because
	existing middleboxes will render large parts of the Internet opaque		existing middleboxes will drop it on many paths through the Internet.
	to it. However, most middleboxes will not be updated to allow the		However, most middleboxes will not be updated to allow the new header
	new header to pass until it has been proved safe and useful on the		to pass until it has been proved safe and useful on the open
	open Internet, which is impossible until the middleboxes have been		Internet, which is impossible until the middleboxes have been
	updated.		updated.
	The uniform TLV format now defined for extension headers [RFC6564]		The uniform TLV format now defined for extension headers [RFC6564]
	will improve the situation, but only for future extensions. Some		will improve the situation, but only for future extensions. Some
	tricky and potentially malicious cases will be avoided by forbidding		tricky and potentially malicious cases will be avoided by forbidding
	very long chains of extension headers that need to be fragmented		very long chains of extension headers that need to be fragmented
	[I-D.ietf-6man-oversized-header-chain]. This will alleviate concerns		[I-D.ietf-6man-oversized-header-chain]. This will alleviate concerns
	that stateless firewalls cannot handle a complete header chain as		that stateless firewalls cannot locate a complete header chain as
	required by the present document.		required by the present document.
	However, these changes are insufficient to correct the underlying		However, these changes are insufficient to correct the underlying
	problem. The present document clarifies that the above requirement		problem. The present document clarifies that the above requirement
	from RFC 2460 applies to all types of node that forward IPv6 packets		from RFC 2460 applies to all types of node that forward IPv6 packets
	and to all extension headers standardised now and in the future. It		and to all extension headers standardised now and in the future. It
	also requests IANA to create a subsidiary registry that clearly		also requests IANA to create a subsidiary registry that clearly
	identifies extension header types, and updates RFC 2780 accordingly.		identifies extension header types, and updates RFC 2780 accordingly.
	Fundamental changes to the IPv6 extension header architecture are out		Fundamental changes to the IPv6 extension header architecture are out
	of scope for this document.		of scope for this document.
	skipping to change at page 4, line 47		skipping to change at page 4, line 49
	2. Requirement to Transmit Extension Headers		2. Requirement to Transmit Extension Headers
	2.1. All Extension Headers		2.1. All Extension Headers
	Any forwarding node along an IPv6 packet's path, which forwards the		Any forwarding node along an IPv6 packet's path, which forwards the
	packet for any reason, SHOULD do so regardless of any extension		packet for any reason, SHOULD do so regardless of any extension
	headers that are present, as required by RFC 2460. Exceptionally, if		headers that are present, as required by RFC 2460. Exceptionally, if
	this node is designed to examine extension headers for any reason,		this node is designed to examine extension headers for any reason,
	such as firewalling, it MUST recognise and deal appropriately with		such as firewalling, it MUST recognise and deal appropriately with
	all standardised IPv6 extension header types. The list of		all standardised IPv6 extension header types and SHOULD recognise
	standardised extension header types is maintained by IANA (see		experimental IPv6 extension header types. The list of standardised
			and experimental extension header types is maintained by IANA (see
	Section 4) and implementors are advised to check this list regularly		Section 4) and implementors are advised to check this list regularly
	for updates.		for updates.
	RFC 2460 requires destination hosts to discard packets containing		RFC 2460 requires destination hosts to discard packets containing
	unrecognised extension headers. However, intermediate forwarding		unrecognised extension headers. However, intermediate forwarding
	nodes SHOULD NOT do this by default, since that might cause them to		nodes SHOULD NOT do this by default, since that might cause them to
	inadvertently discard traffic using a recently standardised extension		inadvertently discard traffic using a recently standardised extension
	header, not yet recognised by the intermediate node. The only		header, not yet recognised by the intermediate node. The only
	exceptions to this rule are discussed below.		exceptions to this rule are discussed below.
	As mentioned above, forwarding nodes that discard packets containing		As mentioned above, forwarding nodes that discard packets containing
	extension headers are known to cause connectivity failures and		extension headers are known to cause connectivity failures and
	deployment problems. Therefore, it is important that forwarding		deployment problems. Therefore, it is important that forwarding
	nodes that inspect IPv6 extension headers can parse all standard		nodes that inspect IPv6 extension headers can parse all standard
	headers and are able to behave according to the above requirements.		headers and are able to behave according to the above requirements.
	If a forwarding node discards a packet containing a standard IPv6		If a forwarding node discards a packet containing a standard IPv6
	extension header, it MUST be the result of a configurable policy, and		extension header, it MUST be the result of a configurable policy, and
	not just the result of a failure to recognise such a header. This		not just the result of a failure to recognise such a header. This
	means that the discard policy for each standardised type of extension		means that the discard policy for each standardised type of extension
	header MUST be individually configurable. The default configuration		header MUST be individually configurable. The default configuration
	SHOULD allow all standardised extension headers except the		SHOULD allow all standardised extension headers.
	experimental values 253 and 254 standardised by [RFC3692] and
	[RFC4727]. Forwarding nodes MUST be configurable to allow packets
	containing unrecognised extension headers, but such packets MAY be
	dropped by default.
	The IPv6 Routing Header Types 0 and 1 have been deprecated and SHOULD		Experimental IPv6 extension headers, including types 253 and 254
	NOT be used. However, as specified in [RFC5095], this does not mean		defined by [RFC3692] and [RFC4727], SHOULD be treated in the same way
	that the IPv6 Routing Header can be unconditionally dropped by		as standardised extension headers, but they MAY be dropped by
	forwarding nodes. Packets containing standardised and undeprecated		default.
	Routing Headers SHOULD be forwarded by default. At the time of
	writing, these include Type 2 [RFC6275], Type 3 [RFC6554], and the		Forwarding nodes MUST be configurable to allow packets containing
	experimental Routing Header Types 253 and 254 [RFC4727]. Others may		unrecognised extension headers, but such packets MAY be dropped by
	be defined in future.		default.
			The IPv6 Routing Header Types 0 and 1 have been deprecated [RFC5095].
			However, this does not mean that the IPv6 Routing Header can be
			unconditionally dropped by forwarding nodes. Packets containing
			standardised and undeprecated Routing Headers SHOULD be forwarded by
			default. At the time of writing, these include Type 2 [RFC6275],
			Type 3 [RFC6554], and the experimental Routing Header Types 253 and
			254 [RFC4727]. Others may be defined in future.
	2.2. Hop-by-Hop Options		2.2. Hop-by-Hop Options
	The IPv6 Hop-by-Hop Options header SHOULD be processed by		The IPv6 Hop-by-Hop Options header SHOULD be processed by
	intermediate forwarding nodes as described in [RFC2460]. However, it		intermediate forwarding nodes as described in [RFC2460]. However, it
	is to be expected that high performance routers will either ignore		is to be expected that high performance routers will either ignore
	it, or assign packets containing it to a slow processing path.		it, or assign packets containing it to a slow processing path.
	Designers planning to use a Hop-by-Hop option need to be aware of		Designers planning to use a Hop-by-Hop option need to be aware of
	this likely behaviour.		this likely behaviour.
	skipping to change at page 6, line 24		skipping to change at page 6, line 32
	experience. Until it is complete, the new extension will fail in		experience. Until it is complete, the new extension will fail in
	some parts of the Internet. This aspect needs to be considered when		some parts of the Internet. This aspect needs to be considered when
	deciding to standardise a new extension. Specific security		deciding to standardise a new extension. Specific security
	considerations for each new extension should be documented in the		considerations for each new extension should be documented in the
	document that defines it.		document that defines it.
	4. IANA Considerations		4. IANA Considerations
	IANA is requested to clearly mark in the Assigned Internet Protocol		IANA is requested to clearly mark in the Assigned Internet Protocol
	Numbers registry those values which are also IPv6 Extension Header		Numbers registry those values which are also IPv6 Extension Header
	types defined by an IETF standards action, for example by adding an		types defined by an IETF action, for example by adding an extra
	extra column to indicate this. This will also apply to any IPv6		column to indicate this. This will also apply to any IPv6 Extension
	Extension Header types standardised in the future.		Header types defined in the future.
	Additionally, IANA is requested to replace the existing empty IPv6		Additionally, IANA is requested to replace the existing empty IPv6
	Next Header Types registry by an IPv6 Extension Header Types		Next Header Types registry by an IPv6 Extension Header Types
	registry. It will contain only those protocol numbers which are also		registry. It will contain only those protocol numbers which are also
	marked as IPv6 Extension Header types in the Assigned Internet		marked as IPv6 Extension Header types in the Assigned Internet
	Protocol Numbers registry and were defined by an IETF standards		Protocol Numbers registry. Experimental values will be marked as
	action. The initial list will be as follows:		such. The initial list will be as follows:
	o 0, Hop-by-Hop Options, [RFC2460]		o 0, Hop-by-Hop Options, [RFC2460]
	o 43, Routing, [RFC2460], [RFC5095]		o 43, Routing, [RFC2460], [RFC5095]
	o 44, Fragment, [RFC2460]		o 44, Fragment, [RFC2460]
	o 50, Encapsulating Security Payload, [RFC4303]		o 50, Encapsulating Security Payload, [RFC4303]
	o 51, Authentication, [RFC4302]		o 51, Authentication, [RFC4302]
	skipping to change at page 6, line 44		skipping to change at page 7, line 4
	o 0, Hop-by-Hop Options, [RFC2460]		o 0, Hop-by-Hop Options, [RFC2460]
	o 43, Routing, [RFC2460], [RFC5095]		o 43, Routing, [RFC2460], [RFC5095]
	o 44, Fragment, [RFC2460]		o 44, Fragment, [RFC2460]
	o 50, Encapsulating Security Payload, [RFC4303]		o 50, Encapsulating Security Payload, [RFC4303]
	o 51, Authentication, [RFC4302]		o 51, Authentication, [RFC4302]
	o 60, Destination Options, [RFC2460]		o 60, Destination Options, [RFC2460]
	o 135, MIPv6, [RFC6275]		o 135, MIPv6, [RFC6275]
			o 139, experimental use, HIP, [RFC5201]
	o 140, shim6, [RFC5533]		o 140, shim6, [RFC5533]
	o 253, experimental use, [RFC3692], [RFC4727]		o 253, experimental use, [RFC3692], [RFC4727]
	o 254, experimental use, [RFC3692], [RFC4727]		o 254, experimental use, [RFC3692], [RFC4727]
	This list excludes both type 59, No Next Header, [RFC2460], which is		This list excludes type 59, No Next Header, [RFC2460], which is not
	not an extension header as such, and type 139, HIP, [RFC5201], which		an extension header as such.
	is experimental.
	The references to the IPv6 Next Header field in [RFC2780] are to be		The references to the IPv6 Next Header field in [RFC2780] are to be
	interpreted as also applying to the IPv6 Extension Header field.		interpreted as also applying to the IPv6 Extension Header field.
	5. Acknowledgements		5. Acknowledgements
	This document was triggered by mailing list discussions including		This document was triggered by mailing list discussions including
	John Leslie, Stefan Marksteiner and others. Valuable comments and		John Leslie, Stefan Marksteiner and others. Valuable comments and
	contributions were made by Dominique Barthel, Tim Chown, Lorenzo		contributions were made by Dominique Barthel, Tim Chown, Lorenzo
	Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh		Colitti, Fernando Gont, C. M. Heard, Bob Hinden, Ray Hunter, Suresh
	Krishnan, Marc Lampo, Michael Richardson, Dave Thaler, Joe Touch,		Krishnan, Marc Lampo, Michael Richardson, Dave Thaler, Joe Touch,
	Bjoern Zeeb, and others.		Bjoern Zeeb, and others.
	Brian Carpenter was a visitor at the Computer Laboratory, Cambridge		Brian Carpenter was a visitor at the Computer Laboratory, Cambridge
	University during part of this work.		University during part of this work.
	This document was produced using the xml2rfc tool [RFC2629].		This document was produced using the xml2rfc tool [RFC2629].
	6. Change log [RFC Editor: Please remove]		6. Change log [RFC Editor: Please remove]
			draft-ietf-6man-ext-transmit-03: added details for experimental
			values, various clarifications and minor corrections, 2013-08-22.
	draft-ietf-6man-ext-transmit-02: explicit mention of header types 253		draft-ietf-6man-ext-transmit-02: explicit mention of header types 253
	and 254, editorial fixes, 2013-08-06.		and 254, editorial fixes, 2013-08-06.
	draft-ietf-6man-ext-transmit-01: tuned use of normative language,		draft-ietf-6man-ext-transmit-01: tuned use of normative language,
	clarified that only standardised extensions are covered (hence		clarified that only standardised extensions are covered (hence
	excluding HIP), 2013-05-29.		excluding HIP), 2013-05-29.
	draft-ietf-6man-ext-transmit-00: first WG version, more		draft-ietf-6man-ext-transmit-00: first WG version, more
	clarifications, 2013-03-26.		clarifications, 2013-03-26.
	skipping to change at page 9, line 6		skipping to change at page 9, line 16
	M. Bhatia, "A Uniform Format for IPv6 Extension Headers",		M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
	RFC 6564, April 2012.		RFC 6564, April 2012.
	7.2. Informative References		7.2. Informative References
	[Heller] Heller, J., "Catch-22", Simon and Schuster , 1961.		[Heller] Heller, J., "Catch-22", Simon and Schuster , 1961.
	[I-D.ietf-6man-oversized-header-chain]		[I-D.ietf-6man-oversized-header-chain]
	Gont, F., Manral, V., and R. Bonica, "Implications of		Gont, F., Manral, V., and R. Bonica, "Implications of
	Oversized IPv6 Header Chains", draft-ietf-6man-oversized-		Oversized IPv6 Header Chains", draft-ietf-6man-oversized-
	header-chain-03 (work in progress), July 2013.		header-chain-04 (work in progress), August 2013.
	[I-D.taylor-v6ops-fragdrop]		[I-D.taylor-v6ops-fragdrop]
	Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,		Jaeggli, J., Colitti, L., Kumari, W., Vyncke, E., Kaeo,
	M., and T. Taylor, "Why Operators Filter Fragments and		M., and T. Taylor, "Why Operators Filter Fragments and
	What It Implies", draft-taylor-v6ops-fragdrop-01 (work in		What It Implies", draft-taylor-v6ops-fragdrop-01 (work in
	progress), June 2013.		progress), June 2013.
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
	June 1999.		June 1999.
End of changes. 23 change blocks.
	47 lines changed or deleted		58 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/