draft-ietf-6man-ext-transmit-03.txt		draft-ietf-6man-ext-transmit-04.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 23, 2014 August 22, 2013		Expires: March 30, 2014 September 26, 2013
	Transmission and Processing of IPv6 Extension Headers		Transmission and Processing of IPv6 Extension Headers
	draft-ietf-6man-ext-transmit-03		draft-ietf-6man-ext-transmit-04
	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 23, 2014.		This Internet-Draft will expire on March 30, 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	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 . . . . . . . . . . 5
	2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 4		2.1. All Extension Headers . . . . . . . . . . . . . . . . . . 5
	2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 5		2.2. Hop-by-Hop Options . . . . . . . . . . . . . . . . . . . 6
	3. Security Considerations . . . . . . . . . . . . . . . . . . . 6		3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 7		6. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	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],
	which also described how they should be handled by intermediate		which also described how they should be handled by intermediate
	skipping to change at page 3, line 4		skipping to change at page 3, line 4
	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 [RFC6564]. The extension header		updated to create and interpret them [RFC6564]. The extension header
	mechanism is an important part of the IPv6 architecture, and several		mechanism is an important part of the IPv6 architecture, and several
	new 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. However, experience has showed that as a result, the		classifiers. However, experience has shown that as a result, the
	network is not transparent to IPv6 extension headers. Contrary to		network is not transparent to IPv6 extension headers. Contrary to
	Section 4 of RFC 2460, middleboxes sometimes examine and process the		Section 4 of RFC 2460, middleboxes sometimes examine and process 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. A		clumsy and requires knowledge of each extension header's format. A
	separate problem is that the header chain may even be fragmented		separate problem is that the header chain may even be fragmented
	[I-D.ietf-6man-oversized-header-chain].		[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 handled 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 end-to-end connectivity. This applies in particular to		problems of end-to-end connectivity. This applies in particular to
	firewalls that attempt to inspect packets at very high speed, since		firewalls that attempt to inspect packets at very high speed, since
	skipping to change at page 4, line 17		skipping to change at page 4, line 17
	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 locate 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 nodes 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.
	Also, Hop-by-Hop options are not handled by many high speed routers,		Also, Hop-by-Hop options are not handled by many high speed routers,
	or are processed only on a slow path. This document also updates the		or are processed only on a slow path. This document also updates the
	requirements for processing the Hop-by-Hop options header to make		requirements for processing the Hop-by-Hop options header to make
	them more realistic.		them more realistic.
	skipping to change at page 4, line 40		skipping to change at page 4, line 40
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	In the remainder of this document, the term "forwarding node" refers		In the remainder of this document, the term "forwarding node" refers
	to any router, firewall, load balancer, prefix translator, or any		to any router, firewall, load balancer, prefix translator, or any
	other device or middlebox that forwards IPv6 packets with or without		other device or middlebox that forwards IPv6 packets with or without
	examining the packet in any way.		examining the packet in any way.
			In this document "standard" IPv6 extension headers are those
			specified in detail by IETF standards actions. "Experimental"
			extension headers are those defined by any Experimental RFC, and the
			experimental extension header values 253 and 254 defined by [RFC3692]
			and [RFC4727]. "Defined" extension headers are the "standard"
			extension headers plus the "experimental" ones.
	2. Requirement to Transmit Extension Headers		2. Requirement to Transmit Extension Headers
	2.1. All Extension Headers		2.1. All Extension Headers
			As mentioned above, forwarding nodes that discard packets containing
			extension headers are known to cause connectivity failures and
			deployment problems. Therefore, it is important that forwarding
			nodes that inspect IPv6 headers can parse all defined extension
			headers and deal with them appropriately, as specified in this
			section.
	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,		a forwarding node is designed to examine extension headers for any
	such as firewalling, it MUST recognise and deal appropriately with		reason, such as firewalling, it MUST recognise and deal appropriately
	all standardised IPv6 extension header types and SHOULD recognise		with all standard IPv6 extension header types and SHOULD recognise
	experimental IPv6 extension header types. The list of standardised		and deal appropriately with experimental IPv6 extension header types.
	and experimental extension header types is maintained by IANA (see		The list of standard and experimental extension header types is
	Section 4) and implementors are advised to check this list regularly		maintained by IANA (see Section 4) and implementors are advised to
	for updates.		check this list regularly 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, 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 exceptions
	exceptions to this rule are discussed below.		to this rule are discussed next.
	As mentioned above, forwarding nodes that discard packets containing
	extension headers are known to cause connectivity failures and
	deployment problems. Therefore, it is important that forwarding
	nodes that inspect IPv6 extension headers can parse all standard
	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 standard 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.		SHOULD allow all standard extension headers.
	Experimental IPv6 extension headers, including types 253 and 254		Experimental IPv6 extension headers SHOULD be treated in the same way
	defined by [RFC3692] and [RFC4727], SHOULD be treated in the same way		as standard extension headers, including an individually configurable
	as standardised extension headers, but they MAY be dropped by		discard policy. However, the default configuration MAY drop
	default.		experimental extension headers.
	Forwarding nodes MUST be configurable to allow packets containing		Forwarding nodes MUST be configurable to allow packets containing
	unrecognised extension headers, but such packets MAY be dropped by		unrecognised extension headers, but the default configuration MAY
	default.		drop such packets.
	The IPv6 Routing Header Types 0 and 1 have been deprecated [RFC5095].		The IPv6 Routing Header Types 0 and 1 have been deprecated [RFC5095].
	However, this does not mean that the IPv6 Routing Header can be		However, this does not mean that the IPv6 Routing Header can be
	unconditionally dropped by forwarding nodes. Packets containing		unconditionally dropped by forwarding nodes. Packets containing
	standardised and undeprecated Routing Headers SHOULD be forwarded by		standardised and undeprecated Routing Headers SHOULD be forwarded by
	default. At the time of writing, these include Type 2 [RFC6275],		default. At the time of writing, these include Type 2 [RFC6275],
	Type 3 [RFC6554], and the experimental Routing Header Types 253 and		Type 3 [RFC6554], and the experimental Routing Header Types 253 and
	254 [RFC4727]. Others may be defined in future.		254 [RFC4727]. Others may be defined in future.
	2.2. Hop-by-Hop Options		2.2. Hop-by-Hop Options
	skipping to change at page 6, line 13		skipping to change at page 6, line 26
	this likely behaviour.		this likely behaviour.
	As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options		As a reminder, in RFC 2460, it is stated that the Hop-by-Hop Options
	header, if present, must be first.		header, if present, must be first.
	3. Security Considerations		3. Security Considerations
	Forwarding nodes that operate as firewalls MUST conform to the		Forwarding nodes that operate as firewalls MUST conform to the
	requirements in the previous section in order to respect the IPv6		requirements in the previous section in order to respect the IPv6
	extension header architecture. In particular, packets containing		extension header architecture. In particular, packets containing
	standard extension headers are only to be discarded as a result of a		standard extension headers are only to be discarded as a result of an
	configurable policy.		intentionally configured policy.
			These changes do not affect a firewall's ability to filter out
			traffic containing unwanted or suspect extension headers, if
			configured to do so. However, the changes do require firewalls to be
			capable of permitting any or all extension headers, if configured to
			do so. The default configurations are intended to allow normal use
			of any standard extension header, avoiding the connectivity issues
			described in Section 1 and Section 2.1.
	When new extension headers are standardised in the future, those		When new extension headers are standardised in the future, those
	implementing and configuring forwarding nodes, including firewalls,		implementing and configuring forwarding nodes, including firewalls,
	will need to take account of them. A newly defined header will		will need to take them into account. A newly defined header will
	exercise new code paths in a host that does recognise it, so caution		exercise new code paths in a host that does recognise it, so caution
	may be required. It is therefore to be expected that the deployment		may be required. Additional security issues with experimental values
	process will be slow and will depend on satisfactory operational		or new extension headers are to be found in [RFC4727] and [RFC6564].
	experience. Until it is complete, the new extension will fail in		As a result, it is to be expected that the deployment process will be
	some parts of the Internet. This aspect needs to be considered when		slow and will depend on satisfactory operational experience. Until
	deciding to standardise a new extension. Specific security		deployment is complete, the new extension will fail in some parts of
	considerations for each new extension should be documented in the		the Internet. This aspect needs to be considered when deciding to
	document that defines it.		standardise a new extension. Specific security considerations for
			each new extension should be documented in the 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 action, for example by adding an extra		types defined by an IETF Standards Action or IESG Approval (see list
	column to indicate this. This will also apply to any IPv6 Extension		below), for example by adding an extra column title "IPv6 Extension
			Header" to indicate this. This will also apply to any IPv6 Extension
	Header types defined in the future.		Header types defined in the future.
	Additionally, IANA is requested to replace the existing empty IPv6		Additionally, IANA is requested to make the existing empty IPv6 Next
	Next Header Types registry by an IPv6 Extension Header Types		Header Types registry redirect users to a new IPv6 Extension Header
	registry. It will contain only those protocol numbers which are also		Types registry. It will contain only those protocol numbers which
	marked as IPv6 Extension Header types in the Assigned Internet		are also marked as IPv6 Extension Header types in the Assigned
	Protocol Numbers registry. Experimental values will be marked as		Internet Protocol Numbers registry. Experimental values will be
	such. The initial list will be as follows:		marked as 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 7, line 20		skipping to change at page 7, line 47
	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 type 59, No Next Header, [RFC2460], which is not		This list excludes type 59, No Next Header, [RFC2460], which is not
	an extension header as such.		an extension header as such.
	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 and
			the IPv6 Extension Header Types registry will be managed accordingly.
	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, Sandra Murphy, Michael Richardson, Dan
	Bjoern Zeeb, and others.		Romascanu, Dave Thaler, Joe Touch, 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-04: updates following IETF Last Call,
			normative requirements clarified, IANA considerations clarified,
			security consuderations expanded, 2013-09-26.
	draft-ietf-6man-ext-transmit-03: added details for experimental		draft-ietf-6man-ext-transmit-03: added details for experimental
	values, various clarifications and minor corrections, 2013-08-22.		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.
	skipping to change at page 8, line 32		skipping to change at page 9, line 19
	[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.
	[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For		[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
	Values In the Internet Protocol and Related Headers", BCP		Values In the Internet Protocol and Related Headers", BCP
	37, RFC 2780, March 2000.		37, RFC 2780, March 2000.
	[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers		[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers
	Considered Useful", BCP 82, RFC 3692, January 2004.		Considered Useful", BCP 82, RFC 3692, January 2004.
	[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
	2005.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
	4303, December 2005.
	[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,		[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
	ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.		ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
	[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
	of Type 0 Routing Headers in IPv6", RFC 5095, December
	2007.
	[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
	"Host Identity Protocol", RFC 5201, April 2008.
	[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
	Shim Protocol for IPv6", RFC 5533, June 2009.
	[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
	in IPv6", RFC 6275, July 2011.
	[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and		[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
	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-04 (work in progress), August 2013.		header-chain-07 (work in progress), September 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.
			[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December
			2005.
			[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
			4303, December 2005.
			[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
			of Type 0 Routing Headers in IPv6", RFC 5095, December
			2007.
			[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
			"Host Identity Protocol", RFC 5201, April 2008.
			[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
			Shim Protocol for IPv6", RFC 5533, June 2009.
			[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
			in IPv6", RFC 6275, July 2011.
	[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6		[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
	Routing Header for Source Routes with the Routing Protocol		Routing Header for Source Routes with the Routing Protocol
	for Low-Power and Lossy Networks (RPL)", RFC 6554, March		for Low-Power and Lossy Networks (RPL)", RFC 6554, March
	2012.		2012.
	Authors' Addresses		Authors' Addresses
	Brian Carpenter		Brian Carpenter
	Department of Computer Science		Department of Computer Science
	University of Auckland		University of Auckland
End of changes. 34 change blocks.
	78 lines changed or deleted		102 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/