< draft-ietf-lpwan-ipv6-static-context-hc-01.txt		draft-ietf-lpwan-ipv6-static-context-hc-02.txt >
	lpwan Working Group A. Minaburo		lpwan Working Group A. Minaburo
	Internet-Draft Acklio		Internet-Draft Acklio
	Intended status: Informational L. Toutain		Intended status: Informational L. Toutain
	Expires: September 3, 2017 IMT-Atlantique		Expires: September 11, 2017 IMT-Atlantique
	C. Gomez		C. Gomez
	Universitat Politecnica de Catalunya		Universitat Politecnica de Catalunya
	March 02, 2017		March 10, 2017
	LPWAN Static Context Header Compression (SCHC) and fragmentation for		LPWAN Static Context Header Compression (SCHC) and fragmentation for
	IPv6 and UDP		IPv6 and UDP
	draft-ietf-lpwan-ipv6-static-context-hc-01		draft-ietf-lpwan-ipv6-static-context-hc-02
	Abstract		Abstract
	This document describes a header compression scheme and fragmentation		This document describes a header compression scheme and fragmentation
	functionality for IPv6/UDP protocols. These techniques are		functionality for IPv6/UDP protocols. These techniques are
	especially tailored for LPWAN (Low Power Wide Area Network) networks		especially tailored for LPWAN (Low Power Wide Area Network) networks
	and could be extended to other protocol stacks.		and could be extended to other protocol stacks.
	The Static Context Header Compression (SCHC) offers a great level of		The Static Context Header Compression (SCHC) offers a great level of
	flexibility when processing the header fields. Static context means		flexibility when processing the header fields. Static context means
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	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 September 3, 2017.		This Internet-Draft will expire on September 11, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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 8, line 13 ¶		skipping to change at page 8, line 13 ¶
	action taken by the decompressor to restore the original value.		action taken by the decompressor to restore the original value.
	/--------------------+-------------+---------------------------\		/--------------------+-------------+---------------------------\
	| Function | Compression | Decompression |		| Function | Compression | Decompression |
	| | | |		| | | |
	+--------------------+-------------+---------------------------+		+--------------------+-------------+---------------------------+
	|not-sent |elided |use value stored in ctxt |		|not-sent |elided |use value stored in ctxt |
	|value-sent |send |build from received value |		|value-sent |send |build from received value |
	|LSB(length) |send LSB |ctxt value OR rcvd value |		|LSB(length) |send LSB |ctxt value OR rcvd value |
	|compute-length |elided |compute length |		|compute-length |elided |compute length |
	|compute-UDP-checksum|elided |compute UDP checksum |		|compute-checksum |elided |compute UDP checksum |
	|ESiid-DID |elided |build IID from L2 ES addr |		|ESiid-DID |elided |build IID from L2 ES addr |
	|LAiid-DID |elided |build IID from L2 LA addr |		|LAiid-DID |elided |build IID from L2 LA addr |
	|mapping-sent |send index |value from index on a table|		|mapping-sent |send index |value from index on a table|
	\--------------------+-------------+---------------------------/		\--------------------+-------------+---------------------------/
	Figure 3: Compression and Decompression Functions		Figure 3: Compression and Decompression Functions
	Figure 3 sumarizes the functions defined to compress and decompress a		Figure 3 sumarizes the functions defined to compress and decompress a
	field. The first column gives the function's name. The second and		field. The first column gives the function's name. The second and
	third columns outlines the compression/decompression behavior.		third columns outlines the compression/decompression behavior.
	skipping to change at page 16, line 31 ¶		skipping to change at page 16, line 31 ¶
	The second and third rules use global addresses. The way the ES		The second and third rules use global addresses. The way the ES
	learns the prefix is not in the scope of the document.		learns the prefix is not in the scope of the document.
	The third rule compresses port numbers to 4 bits.		The third rule compresses port numbers to 4 bits.
	8. Fragmentation		8. Fragmentation
	8.1. Overview		8.1. Overview
	Fragmentation in LPWAN is mandatory and it is used if after the SCHC		Fragmentation support in LPWAN is mandatory and it is used if, after
	header compression the size of the packet is larger than the L2 data		SCHC header compression, the size of the resulting packet is larger
	unit maximum payload or if the SCHC header compression is not able to		than the L2 data unit maximum payload. Fragmentation is also used if
	compress the packet. In LPWAN technologies the L2 data unit size		SCHC header compression has not been able to compress a packet that
	typically varies from tens to hundreds of bytes. If the entire IPv6		is larger than the L2 data unit maximum payload. In LPWAN
	datagram fits within a single L2 data unit, the fragmentation		technologies the L2 data unit size typically varies from tens to
	mechanims is not used and the packet is sent unfragmented.		hundreds of bytes. If the entire IPv6 datagram fits within a single
			L2 data unit, the fragmentation mechanism is not used and the packet
			is sent unfragmented.
	If the datagram does not fit within a single L2 data unit, it SHALL		If the datagram does not fit within a single L2 data unit, it SHALL
	be broken into fragments.		be broken into fragments.
	Moreover, LPWAN technologies impose some strict limitations on		Moreover, LPWAN technologies impose some strict limitations on
	traffic; therefore it is desirable to enable optional fragment		traffic; therefore it is desirable to enable optional fragment
	retransmission, while a single fragment loss should not lead to		retransmission, while a single fragment loss should not lead to
	retransmitting the full datagram. To preserve energy, Things (End		retransmitting the full datagram. To preserve energy, Things (End
	Systems) are sleeping most of the time and may receive data during a		Systems) are sleeping most of the time and may receive data during a
	short period of time after transmission.		short period of time after transmission.
	This specification enables two main fragment delivery reliability		In order to adapt to the capabilities of various LPWAN technologies,
	options, namely: Unreliable and Reliable. The same reliability		this specification allows for a gradation of fragment delivery
	option MUST be used for all fragments of a packet. Note that the		reliability. There are three main options: Unreliable (UnR) mode,
	fragment delivery reliability option to be used is not necessarily		Reliable per-Packet (RpP) mode and Reliable per-Window (RpW) mode.
	tied to the particular characteristics of the underlying L2 LPWAN		Additionally, the specification provides the option to withhold
	technology (e.g. Unreliable may be used on top of an L2 LPWAN		acknowledgments (ACK) in case of success, making effectively the ACK
	technology with symmetric characteristics for uplink and downlink).		a Negative ACK (NACK). It is up to the underlying LPWAN technology
			to decide which setting to use and whether the same setting applies
			to all IPv6 packets. Note that the fragment delivery reliability
			option to be used is not necessarily tied to the particular
			characteristics of the underlying L2 LPWAN technology (e.g. UnR may
			be used on top of an L2 LPWAN technology with symmetric
			characteristics for uplink and downlink).
	In Unreliable, the receiver MUST NOT issue acknowledgments and the		The same reliability option MUST be used for all fragments of a
	sender MUST NOT perform fragment transmission retries.		packet.
	In Reliable, there exist two possible suboptions, namely: packet mode		In UnR mode, the receiver MUST NOT issue acknowledgments. In RpP
	and window mode. In packet mode, the receiver may transmit one		mode, the receiver may transmit one acknowledgment (ACK) after all
	acknowledgment (ACK) after all fragments carrying an IPv6 packet have		fragments carrying an IPv6 packet have been transmitted. The ACK
	been transmitted. The ACK informs the sender about received and		informs the sender about received and missing fragments from the IPv6
	missing fragments from the IPv6 packet. In window mode, an ACK may		packet. In RpW mode, an ACK may be transmitted by the fragment
	be transmitted by the fragment receiver after a window of fragments		receiver after a window of fragments have been sent. A window of
	have been sent. A window of fragments is a subset of the fragments		fragments is a subset of the full set of fragments needed to carry an
	needed to carry an IPv6 packet. In this mode, the ACK informs the		IPv6 packet. In this mode, the ACK informs the sender about received
	sender about received and missing fragments from the window of		and missing fragments from the window of fragments. In either mode,
	fragments. In either mode, upon receipt of an ACK that informs about		upon receipt of an ACK that informs about any lost fragments, the
	any lost fragments, the sender may retransmit the lost fragments.		sender may retransmit the lost fragments. The maximum number of ACK
	The maximum number of ACK and retransmission rounds is TBD. In		and retransmission rounds is TBD.
	Reliable, the same reliability suboption MUST be used for all
	fragments of a packet.
	Some LPWAN deployments may benefit from conditioning the creation and		Some LPWAN deployments may benefit from conditioning the creation and
	transmission of an ACK to the detection of at least one fragment loss		transmission of an ACK to the detection of at least one fragment loss
	(per-packet or per-window), thus leading to negative ACK (NACK)-		(per-packet or per-window), thus leading to NACK-oriented behavior,
	oriented behavior, while not having such condition may be preferred		while not having such condition may be preferred for other scenarios.
	for other scenarios.
	This document does not make any decision as to whether Unreliable or		This document does not make any decision as to whether UnR, RpP or
	Reliable are used, or whether in Reliable a fragment receiver		RpW modes are used, or or whether the transmission of ACKs is
	generates ACKs per packet or per window, or whether the transmission		conditioned to the detection of fragment losses or not. A complete
	of such ACKs is conditioned to the detection of fragment losses or		specification of the receiver and sender behaviors that correspond to
	not. A complete specification of the receiver and sender behaviors		each acknowledgment policy is also out of scope. Nevertheless, this
	that correspond to each acknowledgment policy is also out of scope.		document does provide examples of the different reliability options
	Nevertheless, this document does provide examples of the different		described.
	reliability options described.
	8.2. Fragment format		8.2. Fragment format
	A fragment comprises a fragmentation header and a fragment payload,		A fragment comprises a fragmentation header and a fragment payload,
	and conforms to the format shown in Figure 6. The fragment payload		and conforms to the format shown in Figure 6. The fragment payload
	carries a subset of either the IPv6 packet after header compression		carries a subset of either the IPv6 packet after header compression
	or an IPv6 packet which could not be compressed. A fragment is the		or an IPv6 packet which could not be compressed. A fragment is the
	payload in the L2 protocol data unit (PDU).		payload in the L2 protocol data unit (PDU).
	+---------------+-----------------------+		+---------------+-----------------------+
	skipping to change at page 18, line 38 ¶		skipping to change at page 18, line 40 ¶
	<----------- R ---------->		<----------- R ---------->
	<-- N --> <---- M ----->		<-- N --> <---- M ----->
	+----- ... -----+-- ... --+---- ... ----+		+----- ... -----+-- ... --+---- ... ----+
	| Rule ID | 11..1 | MIC |		| Rule ID | 11..1 | MIC |
	+----- ... -----+-- ... --+---- ... ----+		+----- ... -----+-- ... --+---- ... ----+
	Figure 8: Fragmentation Header for the Last Fragment		Figure 8: Fragmentation Header for the Last Fragment
	Rule ID: this field has a size of R - N bits in all fragments. Rule		Rule ID: this field has a size of R - N bits in all fragments. Rule
	ID may be used to signal whether Unreliable or Reliable are in use,		ID may be used to signal whether UnR, RpP or RpW mode is in use, and
	and within the latter, whether window mode or packet mode are used.		within the latter, whether window mode or packet mode are used.
	CFN: CFN stands for Compressed Fragment Number. The size of the CFN		CFN: CFN stands for Compressed Fragment Number. The size of the CFN
	field is N bits. In Unreliable, N=1. For Reliable, N equal to or		field is N bits. In UnR mode, N=1. For RpP or RpW modes, N equal to
	greater than 3 is recommended. This field is an unsigned integer		or greater than 3 is recommended. This field is an unsigned integer
	that carries a non-absolute fragment number. The CFN MUST be set		that carries a non-absolute fragment number. The CFN MUST be set
	sequentially decreasing from 2^N - 2 for the first fragment, and MUST		sequentially decreasing from 2^N - 2 for the first fragment, and MUST
	wrap from 0 back to 2^N - 2 (e.g. for N=3, the first fragment has		wrap from 0 back to 2^N - 2 (e.g. for N=3, the first fragment has
	CFN=6, subsequent CFNs are set sequentially and in decreasing order,		CFN=6, subsequent CFNs are set sequentially and in decreasing order,
	and CFN will wrap from 0 back to 6). The CFN for the last fragment		and CFN will wrap from 0 back to 6). The CFN for the last fragment
	has all bits set to 1. Note that, by this definition, the CFN value		has all bits set to 1. Note that, by this definition, the CFN value
	of 2^N - 1 is only used to identify a fragment as the last fragment		of 2^N - 1 is only used to identify a fragment as the last fragment
	carrying a subset of the IPv6 packet being transported, and thus the		carrying a subset of the IPv6 packet being transported, and thus the
	CFN does not strictly correspond to the N least significant bits of		CFN does not strictly correspond to the N least significant bits of
	the actual absolute fragment number. It is also important to note		the actual absolute fragment number. It is also important to note
	that, for N=1, the last fragment of the packet will carry a CFN equal		that, for N=1, the last fragment of the packet will carry a CFN equal
	to 1, while all previous fragments will carry a CFN of 0.		to 1, while all previous fragments will carry a CFN of 0.
	MIC: MIC stands for Message Integrity Check. This field has a size		MIC: MIC stands for Message Integrity Check. This field has a size
	of M bits. It is computed by the sender over the complete IPv6		of M bits. It is computed by the sender over the complete IPv6
	packet before fragmentation by using the TBD algorithm. The MIC		packet before fragmentation by using the TBD algorithm. The MIC
	allows to check for errors in the reassembled IPv6 packet, while it		allows to check for errors in the reassembled IPv6 packet, while it
	also enables compressing the UDP checksum by use of SCHC.		also enables compressing the UDP checksum by use of SCHC.
			The values for R, N and M are not specified in this document, and
			have to be determined by the underlying LPWAN technology.
	8.4. ACK format		8.4. ACK format
	The format of an ACK is shown in Figure 9:		The format of an ACK is shown in Figure 9:
	<----- R ---->		<----- R ---->
	+-+-+-+-+-+-+-+-+----- ... ---+		+-+-+-+-+-+-+-+-+----- ... ---+
	| Rule ID | bitmap |		| Rule ID | bitmap |
	+-+-+-+-+-+-+-+-+----- ... ---+		+-+-+-+-+-+-+-+-+----- ... ---+
	Figure 9: Format of an ACK		Figure 9: Format of an ACK
	Rule ID: In all ACKs, Rule ID has a size of R bits and SHALL be set		Rule ID: In all ACKs, Rule ID has a size of R bits and SHALL be set
	to TBD_ACK to signal that the message is an ACK.		to TBD_ACK to signal that the message is an ACK.
	bitmap: size of the bitmap field of an ACK can be equal to 0 or		bitmap: size of the bitmap field of an ACK can be equal to 0 or
	Ceiling(Number_of_Fragments/8) octets, where Number_of_Fragments		Ceiling(Number_of_Fragments/8) octets, where Number_of_Fragments
	denotes the number of fragments of a window (in window mode) or the		denotes the number of fragments of a window (in RpW mode) or the
	number of fragments that carry the IPv6 packet (in packet mode). The		number of fragments that carry the IPv6 packet (in RpP mode). The
	bitmap is a sequence of bits, where the n-th bit signals whether the		bitmap is a sequence of bits, where the n-th bit signals whether the
	n-th fragment transmitted has been correctly received (n-th bit set		n-th fragment transmitted has been correctly received (n-th bit set
	to 1) or not (n-th bit set to 0). Remaining bits with bit order		to 1) or not (n-th bit set to 0). Remaining bits with bit order
	greater than the number of fragments sent (as determined by the		greater than the number of fragments sent (as determined by the
	receiver) are set to 0, except for the last bit in the bitmap, which		receiver) are set to 0, except for the last bit in the bitmap, which
	is set to 1 if the last fragment (carrying the MIC) has been		is set to 1 if the last fragment (carrying the MIC) has been
	correctly received, and 0 otherwise. Absence of the bitmap in an ACK		correctly received, and 0 otherwise. Absence of the bitmap in an ACK
	confirms correct reception of all fragments to be acknowledged by		confirms correct reception of all fragments to be acknowledged by
	means of the ACK.		means of the ACK.
	Figure 10 shows an example of an ACK in packet mode, where the bitmap		Figure 10 shows an example of an ACK in packet mode, where the bitmap
	indicates that the second and the ninth fragments have not been		indicates that the second and the ninth fragments have not been
	correctly received. In this example, the IPv6 packet is carried by		correctly received. In this example, the IPv6 packet is carried by
	eleven fragments in total, therefore the bitmap in has a size of two		eleven fragments in total, therefore the bitmap has a size of two
	bytes.		bytes.
	1		1
	<----- R ----> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5		<----- R ----> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Rule ID |1|0|1|1|1|1|1|1|0|1|1|0|0|0|0|1|		| Rule ID |1|0|1|1|1|1|1|1|0|1|1|0|0|0|0|1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 10: Example of the Bitmap in an ACK		Figure 10: Example of the Bitmap in an ACK
	Figure 11 shows an example of an ACK in window mode (N=3), where the		Figure 11 shows an example of an ACK in RpW (N=3), where the bitmap
	bitmap indicates that the second and the fifth fragments have not		indicates that the second and the fifth fragments have not been
	been correctly received.		correctly received.
	<----- R ----> 0 1 2 3 4 5 6 7		<----- R ----> 0 1 2 3 4 5 6 7
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Rule ID |1|0|1|1|0|1|1|1|		| Rule ID |1|0|1|1|0|1|1|1|
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 11: Example of the bitmap in an ACK (in window mode, for N=3)		Figure 11: Example of the bitmap in an ACK (in RpW mode, for N=3)
	Figure 12 illustrates an ACK without bitmap.		Figure 12 illustrates an ACK without bitmap.
	<----- R ---->		<----- R ---->
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	| Rule ID |		| Rule ID |
	+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+
	Figure 12: Example of an ACK without bitmap		Figure 12: Example of an ACK without bitmap
	skipping to change at page 21, line 5 ¶		skipping to change at page 21, line 7 ¶
	Upon receipt of a link fragment, the receiver starts constructing the		Upon receipt of a link fragment, the receiver starts constructing the
	original unfragmented packet. It uses the CFN and the order of		original unfragmented packet. It uses the CFN and the order of
	arrival of each fragment to determine the location of the individual		arrival of each fragment to determine the location of the individual
	fragments within the original unfragmented packet. For example, it		fragments within the original unfragmented packet. For example, it
	may place the data payload of the fragments within a payload datagram		may place the data payload of the fragments within a payload datagram
	reassembly buffer at the location determined from the CFN and order		reassembly buffer at the location determined from the CFN and order
	of arrival of the fragments, and the fragment payload sizes. Note		of arrival of the fragments, and the fragment payload sizes. Note
	that the size of the original, unfragmented IPv6 packet cannot be		that the size of the original, unfragmented IPv6 packet cannot be
	determined from fragmentation headers.		determined from fragmentation headers.
	In Reliable, when a fragment with all CFN bits set to 0 is received,		In RpW mode, when a fragment with all CFN bits set to 0 is received,
	the recipient MAY transmit an ACK for the last window of fragments		the recipient MAY transmit an ACK for the last window of fragments
	sent. Note that the first fragment of the window is the one sent		sent. Note that the first fragment of the window is the one sent
	with CFN=2^N-2. In window mode, the fragment with CFN=0 is		with CFN=2^N-2. In RpW mode, the fragment with CFN=0 is considered
	considered the last fragment of its window, except for the last		the last fragment of its window, except for the last fragment of the
	fragment (with all CFN bits set to 1). The last fragment of a packet		whole packet (with all CFN bits set to 1), which is also the last
	is also the last fragment of the last window.		fragment of the last window.
	Once the recipient has received the last fragment, it checks for the		Once the recipient has received the last fragment, it checks for the
	integrity of the reassembled IPv6 datagram, based on the MIC		integrity of the reassembled IPv6 datagram, based on the MIC
	received. In Unreliable, if the integrity check indicates that the		received. In UnR mode, if the integrity check indicates that the
	reassembled IPv6 datagram does not match the original IPv6 datagram		reassembled IPv6 datagram does not match the original IPv6 datagram
	(prior to fragmentation), the reassembled IPv6 datagram MUST be		(prior to fragmentation), the reassembled IPv6 datagram MUST be
	discarded. In Reliable, upon receipt of the last fragment (i.e. with		discarded. In RpP or in RpW mode, upon receipt of the last fragment
	all CFN bits set to 1), the recipient MAY transmit an ACK for the		(i.e. with all CFN bits set to 1), the recipient MAY transmit an ACK
	last window of fragments sent (window mode) or for the whole set of		for the whole set of fragments sent that carry the complete IPv6
	fragments sent that carry a complete IPv6 packet (packet mode). In		packet.
	Reliable, the sender retransmits any lost fragments reported in the
	ACK. A maximum of TBD iterations of ACK and fragment retransmission		In RpP mode or in RpW mode, the sender retransmits any lost fragments
	rounds are allowed per-window or per-IPv6-packet in window mode or in		reported in the ACK. A maximum of TBD iterations of ACK and fragment
	packet mode, respectively. A complete specification of the		retransmission rounds are allowed per-window or per-IPv6-packet in
	mechanisms needed to enable the above described fragment delivery		RpP mode or in RpW mode, respectively. A complete specification of
			the mechanisms needed to enable the above described fragment delivery
	reliability options is out of the scope of this document.		reliability options is out of the scope of this document.
	If a fragment recipient disassociates from its L2 network, the		If a fragment recipient disassociates from its L2 network, the
	recipient MUST discard all link fragments of all partially		recipient MUST discard all link fragments of all partially
	reassembled payload datagrams, and fragment senders MUST discard all		reassembled payload datagrams, and fragment senders MUST discard all
	not yet transmitted link fragments of all partially transmitted		not yet transmitted link fragments of all partially transmitted
	payload (e.g., IPv6) datagrams. Similarly, when a node first		payload (e.g., IPv6) datagrams. Similarly, when a node first
	receives a fragment of a packet, it starts a reassembly timer. When		receives a fragment of a packet, it starts a reassembly timer. When
	this time expires, if the entire packet has not been reassembled, the		this time expires, if the entire packet has not been reassembled, the
	existing fragments MUST be discarded and the reassembly state MUST be		existing fragments MUST be discarded and the reassembly state MUST be
	flushed. The reassembly timeout MUST be set to a maximum of TBD		flushed. The reassembly timeout MUST be set to a maximum of TBD
	seconds).		seconds).
	8.6. Examples		9. Security considerations
			9.1. Security considerations for header compression
			TBD
			9.2. Security considerations for fragmentation
			This subsection describes potential attacks to LPWAN fragmentation
			and proposes countermeasures, based on existing analysis of attacks
			to 6LoWPAN fragmentation {HHWH}.
			A node can perform a buffer reservation attack by sending a first
			fragment to a target. Then, the receiver will reserve buffer space
			for the whole packet on the basis of the datagram size announced in
			that first fragment. Other incoming fragmented packets will be
			dropped while the reassembly buffer is occupied during the reassembly
			timeout. Once that timeout expires, the attacker can repeat the same
			procedure, and iterate, thus creating a denial of service attack.
			The (low) cost to mount this attack is linear with the number of
			buffers at the target node. However, the cost for an attacker can be
			increased if individual fragments of multiple packets can be stored
			in the reassembly buffer. To further increase the attack cost, the
			reassembly buffer can be split into fragment-sized buffer slots.
			Once a packet is complete, it is processed normally. If buffer
			overload occurs, a receiver can discard packets based on the sender
			behavior, which may help identify which fragments have been sent by
			an attacker.
			In another type of attack, the malicious node is required to have
			overhearing capabilities. If an attacker can overhear a fragment, it
			can send a spoofed duplicate (e.g. with random payload) to the
			destination. A receiver cannot distinguish legitimate from spoofed
			fragments. Therefore, the original IPv6 packet will be considered
			corrupt and will be dropped. To protect resource-constrained nodes
			from this attack, it has been proposed to establish a binding among
			the fragments to be transmitted by a node, by applying content-
			chaining to the different fragments, based on cryptographic hash
			functionality. The aim of this technique is to allow a receiver to
			identify illegitimate fragments.
			Further attacks may involve sending overlapped fragments (i.e.
			comprising some overlapping parts of the original IPv6 datagram).
			Implementers should make sure that correct operation is not affected
			by such event.
			10. Acknowledgements
			Thanks to Dominique Barthel, Carsten Bormann, Arunprabhu Kandasamy,
			Antony Markovski, Alexander Pelov, Pascal Thubert, Juan Carlos Zuniga
			for useful design consideration.
			11. References
			11.1. Normative References
			[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
			December 1998, <http://www.rfc-editor.org/info/rfc2460>.
			[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
			"Transmission of IPv6 Packets over IEEE 802.15.4
			Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
			<http://www.rfc-editor.org/info/rfc4944>.
			11.2. Informative References
			[I-D.ietf-lpwan-overview]
			Farrell, S., "LPWAN Overview", draft-ietf-lpwan-
			overview-01 (work in progress), February 2017.
			[I-D.minaburo-lp-wan-gap-analysis]
			Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP
			Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in
			progress), February 2016.
			Appendix A. Fragmentation examples
	This section provides examples of different fragment delivery		This section provides examples of different fragment delivery
	reliability options possible on the basis of this specification.		reliability options possible on the basis of this specification.
	Figure 13 illustrates the transmission of an IPv6 packet that needs		Figure 13 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Unreliable.		11 fragments in UnR mode.
	Sender Receiver		Sender Receiver
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=1-------->|MIC checked =>		|-------CFN=1-------->|MIC checked =>
	Figure 13: Transmission of an IPv6 packet carried by 11 fragments in		Figure 13: Transmission of an IPv6 packet carried by 11 fragments in
	Unreliable		UnR mode
	Figure 14 illustrates the transmission of an IPv6 packet that needs		Figure 14 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Reliable, for N=3, NACK-oriented packet mode, without		11 fragments in RpP mode, for N=3, NACK-oriented, without losses.
	losses.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	(no NACK)		(no NACK)
	Figure 14: Transmission of an IPv6 packet carried by 11 fragments in		Figure 14: Transmission of an IPv6 packet carried by 11 fragments in
	Reliable, for N=3, NACK-oriented packet mode; no losses.		RpP mode, for N=3, NACK-oriented; no losses.
	Figure 15 illustrates the transmission of an IPv6 packet that needs		Figure 15 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Reliable, for N=3, NACK-oriented packet mode, with		11 fragments in RpP mode, for N=3, NACK-oriented, with three losses.
	three losses.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4---X---->|		|-------CFN=4---X---->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2---X---->|		|-------CFN=2---X---->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4---X---->|		|-------CFN=4---X---->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	|<-------NACK---------|Bitmap:1101011110100000		|<-------NACK---------|Bitmap:1101011110100001
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	|-------CFN=4-------->|MIC checked =>		|-------CFN=4-------->|MIC checked =>
	(no NACK)		(no NACK)
	Figure 15: Transmission of an IPv6 packet carried by 11 fragments in		Figure 15: Transmission of an IPv6 packet carried by 11 fragments in
	Reliable, for N=3, NACK-oriented packet mode; three losses.		RpP mode, for N=3, NACK-oriented; three losses.
	Figure 16 illustrates the transmission of an IPv6 packet that needs		Figure 16 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Reliable, window mode, for N=3, without losses.		11 fragments in RpW mode, for N=3, without losses. Receiver feedback
	Receiver feedback is NACK-oriented. Note: in window mode, an		is NACK-oriented. Note: in RpW mode, an additional bit will be
	additional bit will be needed to number windows.		needed to number windows.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	(no NACK)		(no NACK)
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	(no NACK)		(no NACK)
	Figure 16: Transmission of an IPv6 packet carried by 11 fragments in		Figure 16: Transmission of an IPv6 packet carried by 11 fragments in
	Reliable, for N=3, NACK-oriented window mode; without losses.		RpW mode, for N=3, NACK-oriented; without losses.
	Figure 17 illustrates the transmission of an IPv6 packet that needs		Figure 17 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Reliable, window mode, for N=3, with three losses.		11 fragments in RpW mode, for N=3, with three losses. Receiver
	Receiver feedback is NACK-oriented. Note: in window mode, an		feedback is NACK-oriented. Note: in RpW mode, an additional bit will
	additional bit will be needed to number windows.		be needed to number windows.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4---X---->|		|-------CFN=4---X---->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2---X---->|		|-------CFN=2---X---->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|<-------NACK---------|Bitmap:11010110		|<-------NACK---------|Bitmap:11010111
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	(no NACK)		(no NACK)
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4---X---->|		|-------CFN=4---X---->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	|<-------NACK---------|Bitmap:11010000		|<-------NACK---------|Bitmap:11010001
	|-------CFN=4-------->|MIC checked =>		|-------CFN=4-------->|MIC checked =>
	(no NACK)		(no NACK)
	Figure 17: Transmission of an IPv6 packet carried by 11 fragments in		Figure 17: Transmission of an IPv6 packet carried by 11 fragments in
	Reliable, for N=3, NACK-oriented window mode; three losses.		RpW, for N=3, NACK-oriented; three losses.
	Figure 18 illustrates the transmission of an IPv6 packet that needs		Figure 18 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Reliable, packet mode, for N=3, without losses.		11 fragments in RpP mode, for N=3, without losses. Receiver feedback
	Receiver feedback is positive-ACK-oriented.		is positive-ACK-oriented.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	(End)		(End)
	Figure 18: Transmission of an IPv6 packet carried by 11 fragments in		Figure 18: Transmission of an IPv6 packet carried by 11 fragments in
	Reliable, for N=3, packet mode, positive-ACK-oriented; no losses.		RpP mode, for N=3, positive-ACK-oriented; no losses.
	Figure 19 illustrates the transmission of an IPv6 packet that needs		Figure 19 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Reliable, packet mode, for N=3, with three losses.		11 fragments in RpP mode, for N=3, with three losses. Receiver
	Receiver feedback is positive-ACK-oriented.		feedback is positive-ACK-oriented.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4---X---->|		|-------CFN=4---X---->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2---X---->|		|-------CFN=2---X---->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4---X---->|		|-------CFN=4---X---->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	|<-------ACK----------|bitmap:1101011110100000		|<-------ACK----------|bitmap:1101011110100001
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	|-------CFN=4-------->|MIC checked =>		|-------CFN=4-------->|MIC checked =>
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	(End)		(End)
	Figure 19: Transmission of an IPv6 packet carried by 11 fragments in		Figure 19: Transmission of an IPv6 packet carried by 11 fragments in
	Reliable, for N=3, packet mode, positive-ACK-oriented; with three		RpP, for N=3, positive-ACK-oriented; with three losses.
	losses.
	8.6.1. Reliable, window mode, ACK-oriented
	Figure 20 illustrates the transmission of an IPv6 packet that needs		Figure 20 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Reliable, window mode, for N=3, without losses.		11 fragments in RpW mode, for N=3, without losses. Receiver feedback
	Receiver feedback is positive-ACK-oriented. Note: in window mode, an		is positive-ACK-oriented. Note: in RpW mode, an additional bit will
	additional bit will be needed to number windows.		be needed to number windows.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	(End)		(End)
	Figure 20: Transmission of an IPv6 packet carried by 11 fragments in		Figure 20: Transmission of an IPv6 packet carried by 11 fragments in
	Reliable, for N=3, window mode, positive-ACK-oriented; no losses.		RpW mode, for N=3, positive-ACK-oriented; no losses.
	Figure 21 illustrates the transmission of an IPv6 packet that needs		Figure 21 illustrates the transmission of an IPv6 packet that needs
	11 fragments in Reliable, window mode, for N=3, with three losses.		11 fragments in RpW mode, for N=3, with three losses. Receiver
	Receiver feedback is positive-ACK-oriented. Note: in window mode, an		feedback is positive-ACK-oriented. Note: in RpW mode, an additional
	additional bit will be needed to number windows.		bit will be needed to number windows.
	Sender Receiver		Sender Receiver
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4---X---->|		|-------CFN=4---X---->|
	|-------CFN=3-------->|		|-------CFN=3-------->|
	|-------CFN=2---X---->|		|-------CFN=2---X---->|
	|-------CFN=1-------->|		|-------CFN=1-------->|
	|-------CFN=0-------->|		|-------CFN=0-------->|
	|<-------ACK----------|bitmap:11010110		|<-------ACK----------|bitmap:11010111
	|-------CFN=4-------->|		|-------CFN=4-------->|
	|-------CFN=2-------->|		|-------CFN=2-------->|
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	|-------CFN=6-------->|		|-------CFN=6-------->|
	|-------CFN=5-------->|		|-------CFN=5-------->|
	|-------CFN=4---X---->|		|-------CFN=4---X---->|
	|-------CFN=7-------->|MIC checked =>		|-------CFN=7-------->|MIC checked =>
	|<-------ACK----------|bitmap:11010000		|<-------ACK----------|bitmap:11010001
	|-------CFN=4-------->|MIC checked =>		|-------CFN=4-------->|MIC checked =>
	|<-------ACK----------|no bitmap		|<-------ACK----------|no bitmap
	(End)		(End)
	Figure 21: Transmission of an IPv6 packet carried by 11 fragments in		Figure 21: Transmission of an IPv6 packet carried by 11 fragments in
	Reliable, for N=3, window mode, positive-ACK-oriented; with three		RpW mode, for N=3, positive-ACK-oriented; with three losses.
	losses.
	9. Security considerations
	9.1. Security considerations for header compression
	TBD
	9.2. Security considerations for fragmentation
	This subsection describes potential attacks to LPWAN fragmentation
	and proposes countermeasures, based on existing analysis of attacks
	to 6LoWPAN fragmentation {HHWH}.
	A node can perform a buffer reservation attack by sending a first
	fragment to a target. Then, the receiver will reserve buffer space
	for the whole packet on the basis of the datagram size announced in
	that first fragment. Other incoming fragmented packets will be
	dropped while the reassembly buffer is occupied during the reassembly
	timeout. Once that timeout expires, the attacker can repeat the same
	procedure, and iterate, thus creating a denial of service attack.
	The (low) cost to mount this attack is linear with the number of
	buffers at the target node. However, the cost for an attacker can be
	increased if individual fragments of multiple packets can be stored
	in the reassembly buffer. To further increase the attack cost, the
	reassembly buffer can be split into fragment-sized buffer slots.
	Once a packet is complete, it is processed normally. If buffer
	overload occurs, a receiver can discard packets based on the sender
	behavior, which may help identify which fragments have been sent by
	an attacker.
	In another type of attack, the malicious node is required to have
	overhearing capabilities. If an attacker can overhear a fragment, it
	can send a spoofed duplicate (e.g. with random payload) to the
	destination. A receiver cannot distinguish legitimate from spoofed
	fragments. Therefore, the original IPv6 packet will be considered
	corrupt and will be dropped. To protect resource-constrained nodes
	from this attack, it has been proposed to establish a binding among
	the fragments to be transmitted by a node, by applying content-
	chaining to the different fragments, based on cryptographic hash
	functionality. The aim of this technique is to allow a receiver to
	identify illegitimate fragments.
	Further attacks may involve sending overlapped fragments (i.e.
	comprising some overlapping parts of the original IPv6 datagram).
	Implementers should make sure that correct operation is not affected
	by such event.
	10. Acknowledgements
	Thanks to Dominique Barthel, Carsten Bormann, Arunprabhu Kandasamy,
	Antony Markovski, Alexander Pelov, Pascal Thubert, Juan Carlos Zuniga
	for useful design consideration.
	In the fragmentation section, the authors have reused parts of text		Appendix B. Note
	available in section 5.3 of RFC 4944, and would like to thank the
	authors of RFC 4944.
	Carles Gomez has been funded in part by the Spanish Government		Carles Gomez has been funded in part by the Spanish Government
	(Ministerio de Educacion, Cultura y Deporte) through the Jose		(Ministerio de Educacion, Cultura y Deporte) through the Jose
	Castillejo grant CAS15/00336, and by the ERDF and the Spanish		Castillejo grant CAS15/00336, and by the ERDF and the Spanish
	Government through project TEC2016-79988-P. Part of his contribution		Government through project TEC2016-79988-P. Part of his contribution
	to this work has been carried out during his stay as a visiting		to this work has been carried out during his stay as a visiting
	scholar at the Computer Laboratory of the University of Cambridge.		scholar at the Computer Laboratory of the University of Cambridge.
	11. References
	11.1. Normative References
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4
	Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
	<http://www.rfc-editor.org/info/rfc4944>.
	11.2. Informative References
	[I-D.ietf-lpwan-overview]
	Farrell, S., "LPWAN Overview", draft-ietf-lpwan-
	overview-01 (work in progress), February 2017.
	[I-D.minaburo-lp-wan-gap-analysis]
	Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP
	Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in
	progress), February 2016.
	Authors' Addresses		Authors' Addresses
	Ana Minaburo		Ana Minaburo
	Acklio		Acklio
	2bis rue de la Chataigneraie		2bis rue de la Chataigneraie
	35510 Cesson-Sevigne Cedex		35510 Cesson-Sevigne Cedex
	France		France
	Email: ana@ackl.io		Email: ana@ackl.io
	Laurent Toutain		Laurent Toutain
	IMT-Atlantique		IMT-Atlantique
	2 rue de la Chataigneraie		2 rue de la Chataigneraie
	CS 17607		CS 17607
	35576 Cesson-Sevigne Cedex		35576 Cesson-Sevigne Cedex
	France		France
	Email: Laurent.Toutain@imt-atlantique.fr		Email: Laurent.Toutain@imt-atlantique.fr
	Carles Gomez		Carles Gomez
End of changes. 50 change blocks.
	193 lines changed or deleted		192 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/