draft-ietf-6man-deprecate-atomfrag-generation-05.txt		draft-ietf-6man-deprecate-atomfrag-generation-06.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
	Intended status: Informational W. Liu		Intended status: Informational W. Liu
	Expires: July 23, 2016 Huawei Technologies		Expires: October 6, 2016 Huawei Technologies
	T. Anderson		T. Anderson
	Redpill Linpro		Redpill Linpro
	January 20, 2016		April 4, 2016
	Generation of IPv6 Atomic Fragments Considered Harmful		Generation of IPv6 Atomic Fragments Considered Harmful
	draft-ietf-6man-deprecate-atomfrag-generation-05		draft-ietf-6man-deprecate-atomfrag-generation-06
	Abstract		Abstract
	RFC2460 requires that when a host receives an ICMPv6 "Packet Too Big"		This document discusses the security implications of the generation
	message reporting an MTU smaller than 1280 bytes, the host includes a		of IPv6 atomic fragments and a number of interoperability issues
	Fragment Header in all subsequent packets sent to that destination,
	without reducing the assumed Path-MTU. The simplicity with which
	ICMPv6 "Packet Too Big" messages can be forged means that an attacker
	can leverage this functionality (the generation of IPv6 atomic
	fragments) to trigger the use of fragmentation for any arbitrary IPv6
	flow, and subsequently perform any fragmentation-based attack. This
	document discusses the security implications of the generation of
	IPv6 atomic fragments and a number of interoperability issues
	associated with IPv6 atomic fragments, and concludes that the		associated with IPv6 atomic fragments, and concludes that the
	aforementioned functionality is undesirable, thus documenting the		aforementioned functionality is undesirable, thus documenting the
	motivation for removing this functionality in the revision of the		motivation for removing this functionality in the revision of the
	core IPv6 protocol specification [I-D.ietf-6man-rfc2460bis].		core IPv6 protocol specification.
	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 July 23, 2016.		This Internet-Draft will expire on October 6, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Security Implications of the Generation of IPv6 Atomic
	3. Security Implications of the Generation of IPv6 Atomic
	Fragments . . . . . . . . . . . . . . . . . . . . . . . . . . 3		Fragments . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Additional Considerations . . . . . . . . . . . . . . . . . . 5		3. Additional Considerations . . . . . . . . . . . . . . . . . . 4
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8.1. Normative References . . . . . . . . . . . . . . . . . . 7		7.1. Normative References . . . . . . . . . . . . . . . . . . 7
	8.2. Informative References . . . . . . . . . . . . . . . . . 8		7.2. Informative References . . . . . . . . . . . . . . . . . 7
	Appendix A. Small Survey of OSes that Fail to Produce IPv6		Appendix A. Small Survey of OSes that Fail to Produce IPv6
	Atomic Fragments . . . . . . . . . . . . . . . . . . 9		Atomic Fragments . . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
	1. Introduction		1. Introduction
	[RFC2460] specifies the IPv6 fragmentation mechanism, which allows		[RFC2460] specifies the IPv6 fragmentation mechanism, which allows
	IPv6 packets to be fragmented into smaller pieces such that they can		IPv6 packets to be fragmented into smaller pieces such that they can
	fit in the Path-MTU to the intended destination(s).		fit in the Path-MTU to the intended destination(s).
	Section 5 of [RFC2460] states that, when a host receives an ICMPv6		Section 5 of [RFC2460] states that, when a host receives an ICMPv6
	"Packet Too Big" message [RFC4443] advertising an MTU smaller than		"Packet Too Big" message [RFC4443] advertising an MTU smaller than
	1280 bytes (the minimum IPv6 MTU), the host is not required to reduce		1280 bytes (the minimum IPv6 MTU), the host is not required to reduce
	the assumed Path-MTU, but must simply include a Fragment Header in		the assumed Path-MTU, but must simply include a Fragment Header in
	all subsequent packets sent to that destination. The resulting		all subsequent packets sent to that destination. The resulting
	packets will thus *not* be actually fragmented into several pieces,		packets will thus *not* be actually fragmented into several pieces,
	but rather just include a Fragment Header with both the "Fragment		but rather be "atomic fragments" [RFC6946] (i.e., just include a
	Offset" and the "M" flag set to 0 (i.e., "atomic fragments"		Fragment Header with both the "Fragment Offset" and the "M" flag set
	[RFC6946]). [RFC6946] requires that these atomic fragments be		to 0). [RFC6946] requires that these atomic fragments be essentially
	essentially processed by the destination host as non-fragmented		processed by the destination host as non-fragmented traffic (since
	traffic (since there are not really any fragments to be reassembled).		there are not really any fragments to be reassembled). The goal of
	The goal of these atomic fragments is simply to convey an appropriate		these atomic fragments is simply to convey an appropriate
	Identification value to be employed by IPv6/IPv4 translators for the		Identification value to be employed by IPv6/IPv4 translators for the
	resulting IPv4 fragments.		resulting IPv4 fragments.
	While atomic fragments might seem rather benign, there are scenarios		While atomic fragments might seem rather benign, there are scenarios
	in which the generation of IPv6 atomic fragments can be leveraged for		in which the generation of IPv6 atomic fragments can be leveraged for
	performing a number of attacks against the corresponding IPv6 flows.		performing a number of attacks against the corresponding IPv6 flows.
	Since there are concrete security implications arising from the		Since there are concrete security implications arising from the
	generation of IPv6 atomic fragments, and there is no real gain in		generation of IPv6 atomic fragments, and there is no real gain in
	generating IPv6 atomic fragments (as opposed to e.g. having IPv6/IPv4		generating IPv6 atomic fragments (as opposed to e.g. having IPv6/IPv4
	translators generate a Fragment Identification value themselves), we		translators generate a Fragment Identification value themselves), we
	conclude that this functionality is undesirable.		conclude that this functionality is undesirable.
	Section 3 briefly discusses the security implications of the		Section 2 briefly discusses the security implications of the
	generation of IPv6 atomic fragments, and describes a specific Denial		generation of IPv6 atomic fragments, and describes a specific Denial
	of Service (DoS) attack vector that leverages the widespread		of Service (DoS) attack vector that leverages the widespread
	filtering of IPv6 fragments in the public Internet. Section 4		filtering of IPv6 fragments in the public Internet. Section 3
	provides additional considerations regarding the usefulness of		provides additional considerations regarding the usefulness of
	generating IPv6 atomic fragments.		generating IPv6 atomic fragments.
	2. Terminology		2. Security Implications of the Generation of IPv6 Atomic Fragments
	IPv6 atomic fragments:
	IPv6 packets that contain a Fragment Header with the Fragment
	Offset set to 0 and the M flag set to 0 (as defined by [RFC6946]).
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].
	3. Security Implications of the Generation of IPv6 Atomic Fragments
	The security implications of IP fragmentation have been discussed at		The security implications of IP fragmentation have been discussed at
	length in [RFC6274] and [I-D.ietf-6man-predictable-fragment-id]. An		length in [RFC6274] and [RFC7739]. An attacker can leverage the
	attacker can leverage the generation of IPv6 atomic fragments to		generation of IPv6 atomic fragments to trigger the use of
	trigger the use of fragmentation in an arbitrary IPv6 flow and		fragmentation in an arbitrary IPv6 flow and subsequently perform any
	subsequently perform any fragmentation-based attack against legacy		fragmentation-based attack against legacy IPv6 nodes that do not
	IPv6 nodes that do not implement [RFC6946].		implement [RFC6946].
	Unfortunately, even nodes that already implement [RFC6946] can be		Unfortunately, even nodes that already implement [RFC6946] can be
	subject to DoS attacks as a result of the generation of IPv6 atomic		subject to DoS attacks as a result of the generation of IPv6 atomic
	fragments. Let us assume that Host A is communicating with Server B,		fragments. Let us assume that Host A is communicating with Server B,
	and that, as a result of the widespread dropping of IPv6 packets that		and that, as a result of the widespread dropping of IPv6 packets that
	contain extension headers (including fragmentation)		contain extension headers (including fragmentation)
	[I-D.ietf-v6ops-ipv6-ehs-in-real-world], some intermediate node		[I-D.ietf-v6ops-ipv6-ehs-in-real-world], some intermediate node
	filters fragments between Host A and Server B. If an attacker sends		filters fragments between Host A and Server B. If an attacker sends
	a forged ICMPv6 "Packet Too Big" (PTB) error message to server B,		a forged ICMPv6 "Packet Too Big" (PTB) error message to server B,
	reporting an MTU smaller than 1280, this will trigger the generation		reporting an MTU smaller than 1280, this will trigger the generation
	skipping to change at page 5, line 5 ¶		skipping to change at page 4, line 33 ¶
	headers, the ICMPv6 payload might not even contain any useful		headers, the ICMPv6 payload might not even contain any useful
	information on which to perform validation checks.		information on which to perform validation checks.
	o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big"		o Upon receipt of one of the aforementioned ICMPv6 "Packet Too Big"
	error messages, the Destination Cache [RFC4861] is usually updated		error messages, the Destination Cache [RFC4861] is usually updated
	to reflect that any subsequent packets to such destination should		to reflect that any subsequent packets to such destination should
	include a Fragment Header. This means that a single ICMPv6		include a Fragment Header. This means that a single ICMPv6
	"Packet Too Big" error message might affect multiple communication		"Packet Too Big" error message might affect multiple communication
	instances (e.g., TCP connections) with such destination.		instances (e.g., TCP connections) with such destination.
	o As noted in Section 4, SIIT [RFC6145] (including derivative		o As noted in Section 3, SIIT [RFC6145] (including derivative
	protocols such as Stateful NAT64 [RFC6146]) is the only technology		protocols such as Stateful NAT64 [RFC6146]) is the only technology
	which currently makes use of atomic fragments. Unfortunately, an		which currently makes use of atomic fragments. Unfortunately, an
	IPv6 node cannot easily limit its exposure to the aforementioned		IPv6 node cannot easily limit its exposure to the aforementioned
	attack vector by only generating IPv6 atomic fragments towards		attack vector by only generating IPv6 atomic fragments towards
	IPv4 destinations behind a stateless translator. This is due to		IPv4 destinations behind a stateless translator. This is due to
	the fact that Section 3.3 of [RFC6052] encourages operators to use		the fact that Section 3.3 of [RFC6052] encourages operators to use
	a Network-Specific Prefix (NSP) that maps the IPv4 address space		a Network-Specific Prefix (NSP) that maps the IPv4 address space
	into IPv6. When an NSP is being used, IPv6 addresses representing		into IPv6. When an NSP is being used, IPv6 addresses representing
	IPv4 nodes (reached through a stateless translator) are		IPv4 nodes (reached through a stateless translator) are
	indistinguishable from native IPv6 addresses.		indistinguishable from native IPv6 addresses.
	4. Additional Considerations		3. Additional Considerations
	Besides the security assessment provided in Section 3, it is		Besides the security assessment provided in Section 2, it is
	interesting to evaluate the pros and cons of having an IPv6-to-IPv4		interesting to evaluate the pros and cons of having an IPv6-to-IPv4
	translating router rely on the generation of IPv6 atomic fragments.		translating router rely on the generation of IPv6 atomic fragments.
	Relying on the generation of IPv6 atomic fragments implies a reliance		Relying on the generation of IPv6 atomic fragments implies a reliance
	on:		on:
	1. ICMPv6 packets arriving from the translator to the IPv6 node		1. ICMPv6 packets arriving from the translator to the IPv6 node
	2. The ability of the nodes receiving ICMPv6 PTB messages reporting		2. The ability of the nodes receiving ICMPv6 PTB messages reporting
	an MTU smaller than 1280 bytes to actually produce atomic		an MTU smaller than 1280 bytes to actually produce atomic
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 26 ¶
	3. ECMP routing [RFC2992] with more than one translator is employed		3. ECMP routing [RFC2992] with more than one translator is employed
	for e.g., redundancy purposes		for e.g., redundancy purposes
	In such a scenario, if each translator were to select the IPv4		In such a scenario, if each translator were to select the IPv4
	Identification on its own (rather than selecting the IPv4		Identification on its own (rather than selecting the IPv4
	Identification from the low-order 16-bits of the Fragment		Identification from the low-order 16-bits of the Fragment
	Identification of IPv6 atomic fragments), this could possibly lead to		Identification of IPv6 atomic fragments), this could possibly lead to
	IPv4 Identification collisions. However, since a number of		IPv4 Identification collisions. However, since a number of
	implementations set the IPv6 Fragment Identification according to the		implementations set the IPv6 Fragment Identification according to the
	output of a Pseudo-Random Number Generator (PRNG) (see Appendix B of		output of a Pseudo-Random Number Generator (PRNG) (see Appendix B of
	[I-D.ietf-6man-predictable-fragment-id]) and the translator only		[RFC7739]) and the translator only employs the low-order 16-bits of
	employs the low-order 16-bits of such value, it is very unlikely that		such value, it is very unlikely that relying on the Fragment
	relying on the Fragment Identification of the IPv6 atomic fragment		Identification of the IPv6 atomic fragment will result in a reduced
	will result in a reduced IPv4 Identification collision rate (when		IPv4 Identification collision rate (when compared to the case where
	compared to the case where the translator selects each IPv4		the translator selects each IPv4 Identification on its own).
	Identification on its own).
	Finally, we note that [RFC6145] is currently the only "consumer" of		Finally, we note that [RFC6145] is currently the only "consumer" of
	IPv6 atomic fragments, and it correctly and diligently notes (in		IPv6 atomic fragments, and it correctly and diligently notes (in
	Section 6) the possible interoperability problems of relying on IPv6		Section 6) the possible interoperability problems of relying on IPv6
	atomic fragments, proposing as a workaround that leads to more robust		atomic fragments, proposing as a workaround that leads to more robust
	behavior and simplified code.		behavior and simplified code.
	5. IANA Considerations		4. IANA Considerations
	There are no IANA registries within this document. The RFC-Editor		There are no IANA registries within this document.
	can remove this section before publication of this document as an
	RFC.
	6. Security Considerations		5. Security Considerations
	This document briefly discusses the security implications of the		This document briefly discusses the security implications of the
	generation of IPv6 atomic fragments, and describes a specific Denial		generation of IPv6 atomic fragments, and describes a specific Denial
	of Service (DoS) attack vector that leverages the widespread		of Service (DoS) attack vector that leverages the widespread
	filtering of IPv6 fragments in the public Internet. It concludes		filtering of IPv6 fragments in the public Internet. It concludes
	that the generation of IPv6 atomic fragments is an undesirable		that the generation of IPv6 atomic fragments is an undesirable
	feature, and documents the motivation for removing this functionality		feature, and documents the motivation for removing this functionality
	from [I-D.ietf-6man-rfc2460bis].		from [I-D.ietf-6man-rfc2460bis].
	7. Acknowledgements		6. Acknowledgements
	The authors would like to thank (in alphabetical order) Congxiao Bao,		The authors would like to thank (in alphabetical order) Congxiao Bao,
	Bob Briscoe, Brian Carpenter, Tatuya Jinmei, Bob Hinden, Alberto		Bob Briscoe, Brian Carpenter, Tatuya Jinmei, Bob Hinden, Alberto
	Leiva, Xing Li, Jeroen Massar, Erik Nordmark, Qiong Sun, Ole Troan,		Leiva, Xing Li, Jeroen Massar, Erik Nordmark, Qiong Sun, Ole Troan,
	and Tina Tsou, for providing valuable comments on earlier versions of		and Tina Tsou, for providing valuable comments on earlier versions of
	this document.		this document.
	Fernando Gont would like to thank Jan Zorz / Go6 Lab		Fernando Gont would like to thank Jan Zorz / Go6 Lab
	<http://go6lab.si/>, and Jared Mauch / NTT America, for providing		<http://go6lab.si/>, and Jared Mauch / NTT America, for providing
	access to systems and networks that were employed to produce some of		access to systems and networks that were employed to produce some of
	tests that resulted in the publication of this document.		tests that resulted in the publication of this document.
	Additionally, he would like to thank SixXS <https://www.sixxs.net>		Additionally, he would like to thank SixXS <https://www.sixxs.net>
	for providing IPv6 connectivity.		for providing IPv6 connectivity.
	8. References		7. References
	8.1. Normative References		7.1. Normative References
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.		December 1998, <http://www.rfc-editor.org/info/rfc2460>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet		Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", RFC 4443,		Protocol Version 6 (IPv6) Specification", RFC 4443,
	DOI 10.17487/RFC4443, March 2006,		DOI 10.17487/RFC4443, March 2006,
	<http://www.rfc-editor.org/info/rfc4443>.		<http://www.rfc-editor.org/info/rfc4443>.
	[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU		[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU
	Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,		Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
	<http://www.rfc-editor.org/info/rfc4821>.		<http://www.rfc-editor.org/info/rfc4821>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<http://www.rfc-editor.org/info/rfc4861>.		<http://www.rfc-editor.org/info/rfc4861>.
	[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation		[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
	Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,		Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
	<http://www.rfc-editor.org/info/rfc6145>.		<http://www.rfc-editor.org/info/rfc6145>.
	8.2. Informative References		7.2. Informative References
	[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery",
	RFC 2923, DOI 10.17487/RFC2923, September 2000,
	<http://www.rfc-editor.org/info/rfc2923>.
	[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path		[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
	Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,		Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,
	<http://www.rfc-editor.org/info/rfc2992>.		<http://www.rfc-editor.org/info/rfc2992>.
	[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,		[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
	DOI 10.17487/RFC5927, July 2010,		DOI 10.17487/RFC5927, July 2010,
	<http://www.rfc-editor.org/info/rfc5927>.		<http://www.rfc-editor.org/info/rfc5927>.
	[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.		[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
	skipping to change at page 9, line 13 ¶		skipping to change at page 8, line 27 ¶
	April 2011, <http://www.rfc-editor.org/info/rfc6146>.		April 2011, <http://www.rfc-editor.org/info/rfc6146>.
	[RFC6274] Gont, F., "Security Assessment of the Internet Protocol		[RFC6274] Gont, F., "Security Assessment of the Internet Protocol
	Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,		Version 4", RFC 6274, DOI 10.17487/RFC6274, July 2011,
	<http://www.rfc-editor.org/info/rfc6274>.		<http://www.rfc-editor.org/info/rfc6274>.
	[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments",		[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments",
	RFC 6946, DOI 10.17487/RFC6946, May 2013,		RFC 6946, DOI 10.17487/RFC6946, May 2013,
	<http://www.rfc-editor.org/info/rfc6946>.		<http://www.rfc-editor.org/info/rfc6946>.
	[I-D.ietf-6man-predictable-fragment-id]		[RFC7739] Gont, F., "Security Implications of Predictable Fragment
	Gont, F., "Security Implications of Predictable Fragment		Identification Values", RFC 7739, DOI 10.17487/RFC7739,
	Identification Values", draft-ietf-6man-predictable-		February 2016, <http://www.rfc-editor.org/info/rfc7739>.
	fragment-id-10 (work in progress), October 2015.
	[I-D.ietf-v6ops-ipv6-ehs-in-real-world]		[I-D.ietf-v6ops-ipv6-ehs-in-real-world]
	Gont, F., Linkova, J., Chown, T., and S. LIU,		Gont, F., Linkova, J., Chown, T., and S. LIU,
	"Observations on the Dropping of Packets with IPv6		"Observations on the Dropping of Packets with IPv6
	Extension Headers in the Real World", draft-ietf-v6ops-		Extension Headers in the Real World", draft-ietf-v6ops-
	ipv6-ehs-in-real-world-02 (work in progress), December		ipv6-ehs-in-real-world-02 (work in progress), December
	2015.		2015.
	[I-D.ietf-6man-rfc2460bis]		[I-D.ietf-6man-rfc2460bis]
	Deering, S. and B. Hinden, "Internet Protocol, Version 6		Deering, S. and B. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", draft-ietf-6man-rfc2460bis-02 (work		(IPv6) Specification", draft-ietf-6man-rfc2460bis-04 (work
	in progress), December 2015.		in progress), March 2016.
	[Morbitzer]		[Morbitzer]
	Morbitzer, M., "TCP Idle Scans in IPv6", Master's Thesis.		Morbitzer, M., "TCP Idle Scans in IPv6", Master's Thesis.
	Thesis number: 670. Department of Computing Science,		Thesis number: 670. Department of Computing Science,
	Radboud University Nijmegen. August 2013,		Radboud University Nijmegen. August 2013,
	<http://www.ru.nl/publish/pages/769526/		<http://www.ru.nl/publish/pages/769526/
	m_morbitzer_masterthesis.pdf>.		m_morbitzer_masterthesis.pdf>.
	[JOOL] Leiva Popper, A., "nf_defrag_ipv4 and nf_defrag_ipv6",		[JOOL] Leiva Popper, A., "nf_defrag_ipv4 and nf_defrag_ipv6",
	April 2015, <https://github.com/NICMx/Jool/wiki/		April 2015, <https://github.com/NICMx/Jool/wiki/
End of changes. 28 change blocks.
	82 lines changed or deleted		50 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/