< draft-barthel-lpwan-oam-schc-00.txt		draft-barthel-lpwan-oam-schc-01.txt >
	lpwan Working Group D. Barthel		lpwan Working Group D. Barthel
	Internet-Draft Orange SA		Internet-Draft Orange SA
	Intended status: Informational L. Toutain		Intended status: Informational L. Toutain
	Expires: August 1, 2019 IMT-Atlantique		Expires: September 11, 2020 IMT Atlantique
	A. Kandasamy		A. Kandasamy
	Acklio		Acklio
	D. Dujovne		D. Dujovne
	Universidad Diego Portales		Universidad Diego Portales
	JC. Zuniga		JC. Zuniga
	SIGFOX		SIGFOX
	January 28, 2019		March 10, 2020
	OAM for LPWAN using Static Context Header Compression (SCHC)		OAM for LPWAN using Static Context Header Compression (SCHC)
	draft-barthel-lpwan-oam-schc-00		draft-barthel-lpwan-oam-schc-01
	Abstract		Abstract
	With IP protocols now generalizing to constrained networks, users		With IP protocols now generalizing to constrained networks, users
	expect to be able to Operate, Administer and Maintain them with the		expect to be able to Operate, Administer and Maintain them with the
	familiar tools and protocols they already use on less constrained		familiar tools and protocols they already use on less constrained
	networks.		networks.
	OAM uses specific messages sent into the data plane to measure some		OAM uses specific messages sent into the data plane to measure some
	parameters of a network. Most of the time, no explicit values are		parameters of a network. Most of the time, no explicit values are
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	traffic.		traffic.
	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 https://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 August 1, 2019.		This Internet-Draft will expire on September 11, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Detailed behavior . . . . . . . . . . . . . . . . . . . . . . 4		4. Detailed behavior . . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Device is the source of an ICMPv6 error message . . . . . 4		4.1. Device does a ping . . . . . . . . . . . . . . . . . . . 4
	4.2. Device is the destination of an ICMPv6 error message . . 5		4.1.1. Rule example . . . . . . . . . . . . . . . . . . . . 6
	4.2.1. ICMPv6 error message compression. . . . . . . . . . . 6		4.2. Device is ping'ed . . . . . . . . . . . . . . . . . . . . 6
	4.3. Device does a ping . . . . . . . . . . . . . . . . . . . 7		4.2.1. Rule example . . . . . . . . . . . . . . . . . . . . 7
	4.4. Device is ping'ed . . . . . . . . . . . . . . . . . . . . 9		4.3. Device is the source of an ICMPv6 error message . . . . . 7
	5. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.4. Device is the destination of an ICMPv6 error message . . 8
			4.4.1. ICMPv6 error message compression. . . . . . . . . . . 9
			5. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security considerations . . . . . . . . . . . . . . . . . . . 11		6. Security considerations . . . . . . . . . . . . . . . . . . . 11
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 11		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 12		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The primitive functionalities of OAM [RFC6291] are achieved with the		The primitive functionalities of OAM [RFC6291] are achieved with the
	ICMPv6 protocol.		ICMPv6 protocol.
	ICMPv6 [RFC4443] is a companion protocol to IPv6 [RFC8200].		ICMPv6 [RFC4443] is a companion protocol to IPv6 [RFC8200].
	[RFC4443] defines a generic message format. This format is used for		[RFC4443] defines a generic message format. This format is used for
	messages to be sent back to the source of an IPv6 packet to inform it		messages to be sent back to the source of an IPv6 packet to inform it
	skipping to change at page 4, line 20 ¶		skipping to change at page 4, line 20 ¶
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	3. Use cases		3. Use cases
	In the LPWAN architecture, we can distinguish the following cases:		In the LPWAN architecture, we can distinguish the following cases:
			o the Device is the originator of an Echo Request message, and
			therefore the destination of the Echo Reply message.
			o the Device is the destination of an Echo Request message, and
			therefore the purported source of an Echo Reply message.
	o the Device is the (purported) source of an ICMP error message,		o the Device is the (purported) source of an ICMP error message,
	mainly in response to an incorrect incoming IPv6 message, or in		mainly in response to an incorrect incoming IPv6 message, or in
	response to a ping request. In this case, as much as possible,		response to a ping request. In this case, as much as possible,
	the core SCHC C/D should act as a proxy and originate the ICMP		the core SCHC C/D should act as a proxy and originate the ICMP
	message, so that the Device and the LPWAN network are protected		message, so that the Device and the LPWAN network are protected
	from this unwanted traffic.		from this unwanted traffic.
	o the Device is the destination of the ICMP message, mainly in		o the Device is the destination of the ICMP message, mainly in
	response to a packet sent by the Device to the network that		response to a packet sent by the Device to the network that
	generates an error. In this case, we want the ICMP message to		generates an error. In this case, we want the ICMP message to
	reach the Device, and this document describes in section		reach the Device, and this document describes in section
	Section 4.2.1 what SCHC compression should be applied.		Section 4.4.1 what SCHC compression should be applied.
	o the Device is the originator of an Echo Request message, and
	therefore the destination of the Echo Reply message.
	o the Device is the destination of an Echo Request message, and
	therefore the purported source of an Echo Reply message.
	These cases are further described in Section 4.		These cases are further described in Section 4.
	4. Detailed behavior		4. Detailed behavior
	4.1. Device is the source of an ICMPv6 error message		4.1. Device does a ping
			If a ping request is generated by a Device, then SCHC compression
			applies.
			The format of an ICMPv6 Echo Request message is described in
			Figure 1, with Type=128 and Code=0.
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Type | Code | Checksum |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Identifier | Sequence Number |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Data ...
			+-+-+-+-+-
			Figure 1: ICMPv6 Echo Request message format
			If we assume that one rule will be devoted to compressing Echo
			Request messages, then Type and Code are known in the rule to be 128
			and 0 and can therefore be elided with the not-sent CDA.
			Checksum can be reconstructed with the compute-checksum CDA and
			therefore is not transmitted.
			[RFC4443] states that Identifier and Sequence Number are meant to
			"aid in matching Echo Replies to this Echo Request" and that they
			"may be zero". Data is "zero or more bytes of arbitrary data".
			We recommend that Identifier be zero, Sequence Number be a counter on
			3 bits, and Data be zero bytes (absent). Therefore, Identifier is
			elided with the not-sent CDA, Sequence Number is transmitted on 3
			bits with the LSB CDA and no Data is transmitted.
			The transmission cost of the Echo Request message is therefore the
			size of the Rule Id + 3 bits.
			When the destination receives the Echo Request message, it will
			respond back with a Echo Reply message. This message bears the same
			format as the Echo Request message but with Type = 129 (see
			Figure 1).
			[RFC4443] states that the Identifier, Sequence Number and Data fields
			of the Echo Reply message shall contain the same values as the
			invoking Echo Request message. Therefore, a rule shall be used
			similar to that used for compressing the Echo Request message.
			TODO: how about a shared rule for Echo Request and Echo Reply with an
			LSB(1) CDA on the Type field? Or exploiting the Up/Down direction
			field in the rule?
			4.1.1. Rule example
			The following rule gives an example of a SCHC compression. The type
			can be elided if the direction is taken into account. Identifier is
			ignored and generated as 0 at decompression. This implies that only
			one single ping can be launched at any given time on a device.
			Finally, only the least significant 8 bits of the sequence number are
			sent on the LPWAN, allowing a serie of 255 consecutive pings.
			+----------------+--+--+--+---------+--------+------------++------+
			| Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent |
			| | | | | | Opera. | Action ||(bits)|
			+----------------+--+--+--+---------+---------------------++------+
			|ICMPv6 Type |8 |1 |Up|128 | equal | not-sent || |
			|ICMPv6 Type |8 |1 |Dw|129 | equal | not-sent || |
			|ICMPv6 Code |8 |1 |Bi|0 | equal | not-sent || |
			|ICMPv6 Identif. |16|1 |Bi|0 | ignore | not-sent || |
			|ICMPv6 Sequence |16|1 |Bi|0 | MSB(24)| LSB || 8 |
			+================+==+==+==+=========+========+============++======+
			Figure 2: Example of compression rule for a ping from the device
			4.2. Device is ping'ed
			If the Device is ping'ed (i.e., is the destination of an Echo Request
			message), the default behavior is to avoid propagating the Echo
			Request message over the LPWAN.
			This is done by proxying the ping request on the core SCHC C/D. This
			requires to add an action when the rule is selected. Instead of been
			processed by the compressor, the packet description is processed by a
			ping proxy. The rule is used for the selection, so CDAs are not
			necessary.
			The resulting behavior is shown on Figure 3 and described below:
			Device NGW core SCHC C/D Internet Host
			| | | Echo Request, Code=0 |
			| | |<---------------------------|
			| | | |
			| | |--------------------------->|
			| | | Echo Reply, Code=0 |
			Figure 3: Examples of ICMPv6 Echo Request/Reply
			4.2.1. Rule example
			The following rule shows an example of a compression rule for pinging
			a device.
			+----------------+--+--+--+---------+--------+------------++------+
			| Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent |
			| | | | | | Opera. | Action ||(bits)|
			+----------------+--+--+--+---------+---------------------++------+
			|ICMPv6 Type |8 |1 |Dw|128 | equal | not-sent || |
			|ICMPv6 Type |8 |1 |Uo|129 | equal | not-sent || |
			|ICMPv6 Code |8 |1 |Bi|0 | equal | not-sent || |
			|ICMPv6 Identif. |16|1 |Bi|0 | ignore | value-sent || |
			|ICMPv6 Sequence |16|1 |Bi|0 | MSB(24)| LSB || 8 |
			+================+==+==+==+=========+========+============++======+
			Figure 4: Example of compression rule for a ping to a device
			In this example, type and code are elided, the identifer has to be
			sent, and the sequence number is limited to one byte.
			4.3. Device is the source of an ICMPv6 error message
	As stated in [RFC4443], a node should generate an ICMPv6 message in		As stated in [RFC4443], a node should generate an ICMPv6 message in
	response to an IPv6 packet that is malformed or which cannot be		response to an IPv6 packet that is malformed or which cannot be
	processed due to some incorrect field value.		processed due to some incorrect field value.
	The general intent of this document is to spare both the Device and		The general intent of this document is to spare both the Device and
	the LPWAN network this un-necessary traffic. The incorrect packets		the LPWAN network this un-necessary traffic. The incorrect packets
	should be caught at the core SCHC C/D and the ICMPv6 notification		should be caught at the core SCHC C/D and the ICMPv6 notification
	should be sent back from there.		should be sent back from there.
	Device NGW core SCHC C/D Internet Host		Device NGW core SCHC C/D Internet Host
	| | | Destination Port=XXX |		| | | Destination Port=XXX |
	| | |<---------------------------|		| | |<---------------------------|
	| | | |		| | | |
	| | |--------------------------->|		| | |--------------------------->|
	| | | ICMPv6 Port Unreachable |		| | | ICMPv6 Port Unreachable |
	| | | |		| | | |
	| | | |		| | | |
	Figure 1: Example of ICMPv6 error message sent back to the Internet		Figure 5: Example of ICMPv6 error message sent back to the Internet
	Figure 1 shows an example of an IPv6 packet trying to reach a Device.		Figure 5 shows an example of an IPv6 packet trying to reach a Device.
	Let's assume that the port number used as destination port is not		Let's assume that the port number used as destination port is not
	"known" (needs better definition) from the core SCHC C/D. Instead of		"known" (needs better definition) from the core SCHC C/D. Instead of
	sending the packet over the LPWAN and having this packet rejected by		sending the packet over the LPWAN and having this packet rejected by
	the Device, the core SCHC C/D issues an ICMPv6 error message		the Device, the core SCHC C/D issues an ICMPv6 error message
	"Destination Unreachable" (Type 1) with Code 1 ("Port Unreachable")		"Destination Unreachable" (Type 1) with Code 1 ("Port Unreachable")
	on behalf of the Device.		on behalf of the Device.
			In that case the SCHC C/D acts as a router and MUST have a routable
			IPv6 address to generate an ICMPv6 message. when compressing a packet
			containing an IPv6 header, no compression rules are found and: * if a
			rule contains some extension headers, a parameter problem may be
			generated (type 4), * no rules contains the IPv6 prefix, a no route
			to destination ICMPv6 message (type 0, code 0) may be generated, * a
			prefix is found, but no devIID matches, a address unreachable ICMPv6
			message (type 0, code 3) may be generated, * a device IPv6 address is
			found, but no port matches, a port unreachable ICMPv6 message (type
			0, code 4) may be generated,
	TODO: This assumes that all ports that the Device listens to will be		TODO: This assumes that all ports that the Device listens to will be
	matched by a SCHC rule. Is this the basic assumption of SCHC that		matched by a SCHC rule. Is this the basic assumption of SCHC that
	all packets that do not match a rule are rejected? If yes, why do		all packets that do not match a rule are rejected? If yes, why do
	have fragmentation also for uncompressed packets?		have fragmentation also for uncompressed packets?
	TODO: discuss the various Type/Code that are expected to be generated		TODO: discuss the various Type/Code that are expected to be generated
	in response to various errors.		in response to various errors.
	4.2. Device is the destination of an ICMPv6 error message		4.4. Device is the destination of an ICMPv6 error message
	In this situation, we assume that a Device has been configured to		In this situation, we assume that a Device has been configured to
	send information to a server on the Internet. If this server becomes		send information to a server on the Internet. If this server becomes
	no longer accessible, an ICMPv6 message will be generated back		no longer accessible, an ICMPv6 message will be generated back
	towards the Device by an intermediate router. This information can		towards the Device by an intermediate router. This information can
	be useful to the Device, for example for reducing the reporting rate		be useful to the Device, for example for reducing the reporting rate
	in case of periodic reporting of data. Therefore, we compress the		in case of periodic reporting of data. Therefore, we compress the
	ICMPv6 message using SCHC and forward it to the Device over the		ICMPv6 message using SCHC and forward it to the Device over the
	LPWAN.		LPWAN.
	skipping to change at page 6, line 16 ¶		skipping to change at page 9, line 16 ¶
	| | | |		| | | |
	| SCHC compressed IPv6 | |		| SCHC compressed IPv6 | |
	|~~~~~~~~~~~|----------->|----------------------X |		|~~~~~~~~~~~|----------->|----------------------X |
	| | | <--------------------- |		| | | <--------------------- |
	|<~~~~~~~~~~|------------| ICMPv6 Host unreachable |		|<~~~~~~~~~~|------------| ICMPv6 Host unreachable |
	|SCHC compressed ICMPv6 | |		|SCHC compressed ICMPv6 | |
	| | | |		| | | |
	| | | |		| | | |
	Figure 2: Example of ICMPv6 error message sent back to the Device		Figure 6: Example of ICMPv6 error message sent back to the Device
	Figure 2 illustrates this behavior. The ICMPv6 error message is		Figure 6 illustrates this behavior. The ICMPv6 error message is
	compressed as described in Section 4.2.1 and forwarded over the LPWAN		compressed as described in Section 4.4.1 and forwarded over the LPWAN
	to the Device.		to the Device.
	4.2.1. ICMPv6 error message compression.		4.4.1. ICMPv6 error message compression.
	The ICMPv6 error messages defined in [RFC4443] contain the fields		The ICMPv6 error messages defined in [RFC4443] contain the fields
	shown in Figure 3.		shown in Figure 7.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |		| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Value |		| Value |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| As much of invoking packet |		| As much of invoking packet |
	+ as possible without the ICMPv6 packet +		+ as possible without the ICMPv6 packet +
	| exceeding the minimum IPv6 MTU |		| exceeding the minimum IPv6 MTU |
	Figure 3: ICMPv6 Error Message format		Figure 7: ICMPv6 Error Message format
	[RFC4443] states that Type can take the values 1 to 4, and Code can		[RFC4443] states that Type can take the values 1 to 4, and Code can
	be set to values between 0 and 6. Value is unused for the		be set to values between 0 and 6. Value is unused for the
	Destination Unreachable and Time Exceeded messages. It contains the		Destination Unreachable and Time Exceeded messages. It contains the
	MTU for the Packet Too Big message and a pointer to the byte causing		MTU for the Packet Too Big message and a pointer to the byte causing
	the error for the Parameter Error message. Therefore, Value is never		the error for the Parameter Error message. Therefore, Value is never
	expected to be greater than 1280 in LPWAN networks.		expected to be greater than 1280 in LPWAN networks.
	The following generic rule can therefore be used to compress all		The following generic rule can therefore be used to compress all
	ICMPv6 error messages as defined today. More specific rules can also		ICMPv6 error messages as defined today. More specific rules can also
	skipping to change at page 7, line 34 ¶		skipping to change at page 10, line 34 ¶
	Rule Id must be sent in the compressed ICMPv6 message to the Device.		Rule Id must be sent in the compressed ICMPv6 message to the Device.
	TODO: the erroneous IPv6 packet header (not just the Rule Id) should		TODO: the erroneous IPv6 packet header (not just the Rule Id) should
	be sent back. This includes the Rule Id and the compression residue.		be sent back. This includes the Rule Id and the compression residue.
	This means the SCHC C/D uses the context backwards (in the reverse		This means the SCHC C/D uses the context backwards (in the reverse
	direction). How does the Device know it must also use the context		direction). How does the Device know it must also use the context
	backwards?		backwards?
	TODO: how does one know that the "payload" of a compressed-header		TODO: how does one know that the "payload" of a compressed-header
	packet is in fact another compressed header?		packet is in fact another compressed header?
	4.3. Device does a ping
	If a ping request is generated by a Device, then SCHC compression
	applies.
	The format of an ICMPv6 Echo Request message is described in
	Figure 4, with Type=128 and Code=0.
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Code | Checksum |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier | Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data ...
	+-+-+-+-+-
	Figure 4: ICMPv6 Echo Request message format
	If we assume that one rule will be devoted to compressing Echo
	Request messages, then Type and Code are known in the rule to be 128
	and 0 and can therefore be elided with the not-sent CDA.
	Checksum can be reconstructed with the compute-checksum CDA and
	therefore is not transmitted.
	[RFC4443] states that Identifier and Sequence Number are meant to
	"aid in matching Echo Replies to this Echo Request" and that they
	"may be zero". Data is "zero or more bytes of arbitrary data".
	We recommend that Identifier be zero, Sequence Number be a counter on
	3 bits, and Data be zero bytes (absent). Therefore, Identifier is
	elided with the not-sent CDA, Sequence Number is transmitted on 3
	bits with the LSB CDA and no Data is transmitted.
	The transmission cost of the Echo Request message is therefore the
	size of the Rule Id + 3 bits.
	When the destination receives the Echo Request message, it will
	respond back with a Echo Reply message. This message bears the same
	format as the Echo Request message but with Type = 129 (see
	Figure 4).
	[RFC4443] states that the Identifier, Sequence Number and Data fields
	of the Echo Reply message shall contain the same values as the
	invoking Echo Request message. Therefore, a rule shall be used
	similar to that used for compressing the Echo Request message.
	TODO: how about a shared rule for Echo Request and Echo Reply with an
	LSB(1) CDA on the Type field? Or exploiting the Up/Down direction
	field in the rule?
	4.4. Device is ping'ed
	If the Device is ping'ed (i.e., is the destination of an Echo Request
	message), the default behavior is to avoid propagating the Echo
	Request message over the LPWAN.
	This is the recommended behavior with the Code 0 (default value) of
	the Echo Request message.
	The resulting behavior is shown on Figure 5 and described below:
	Device NGW core SCHC C/D Internet Host
	| | | Echo Request, Code=0 |
	| | |<---------------------------|
	| | | |
	| | |--------------------------->|
	| | | Echo Reply, Code=0 |
	Figure 5: Examples of ICMPv6 Echo Request/Reply
	o Code = 0: The Echo Request message is not propagated on the LPWAN
	to the Device. If the SCHC C/D finds a rule in the context with
	the IPv6 address of the Device, it responds with an Echo Reply on
	behalf of the Device. If no rule is found with that IPv6 address,
	the SCHC C/D does not respond.
	TODO: again, we are assuming that no compression rule is equivalent
	to the device not providing the service.
	5. Traceroute		5. Traceroute
	The traceroute6 program sends successive probe packets destined to a		The traceroute6 program sends successive probe packets destined to a
	chosen target but with the Hop Limit value successively incremented		chosen target but with the Hop Limit value successively incremented
	from the initial value 1.		from the initial value 1.
	It expects to receive a "Time Exceeded" (Type = 3) "Hop Limit" (Code		It expects to receive a "Time Exceeded" (Type = 3) "Hop Limit" (Code
	= 0) ICMPv6 error message back from the successive routers along the		= 0) ICMPv6 error message back from the successive routers along the
	path to the destination.		path to the destination.
	skipping to change at page 10, line 10 ¶		skipping to change at page 11, line 7 ¶
	datagram or even an ICMPv6 message. The destination port is chosen		datagram or even an ICMPv6 message. The destination port is chosen
	in the unassigned range in hope that the destination, when eventually		in the unassigned range in hope that the destination, when eventually
	reached, will respond with a "Destination Unreachable" (Type = 1)		reached, will respond with a "Destination Unreachable" (Type = 1)
	"Port Unreachable" (Code = 4) ICMPv6 error message.		"Port Unreachable" (Code = 4) ICMPv6 error message.
	It is not anticipated that a Device will want to traceroute a		It is not anticipated that a Device will want to traceroute a
	destination on the Internet.		destination on the Internet.
	By contrast, a host on the Internet may attempt to traceroute an IPv6		By contrast, a host on the Internet may attempt to traceroute an IPv6
	address that is assigned to an LPWAN device. This is described in		address that is assigned to an LPWAN device. This is described in
	Figure 6.		Figure 8.
	Device NGW core SCHC C/D Internet		Device NGW core SCHC C/D Internet
	| | | Hop Limit=1, Dest Port=XXX |		| | | Hop Limit=1, Dest Port=XXX |
	| | |<---------------------------|		| | |<---------------------------|
	| | | |		| | | |
	| | |--------------------------->|		| | |--------------------------->|
	| | | ICMPv6 Hop Limit error |		| | | ICMPv6 Hop Limit error |
	| | | |		| | | |
	| | | |		| | | |
	| | | Hop Limit=2, Dest Port=XXX |		| | | Hop Limit=2, Dest Port=XXX |
	| | |<---------------------------|		| | |<---------------------------|
	| | | |		| | | |
	| | |--------------------------->|		| | |--------------------------->|
	| | | ICMPv6 Port Unreachable |		| | | ICMPv6 Port Unreachable |
	Figure 6: Example of traceroute to the LPWAN Device		Figure 8: Example of traceroute to the LPWAN Device
	When the probe packet first reaches the core SCHC C/D, its remaining		When the probe packet first reaches the core SCHC C/D, its remaining
	Hop Limit is 1. The core SCHC C/D will respond back with a "Time		Hop Limit is 1. The core SCHC C/D will respond back with a "Time
	Exceeded" (Type = 3) "Hop Limit" (Code = 0) ICMPv6 error message.		Exceeded" (Type = 3) "Hop Limit" (Code = 0) ICMPv6 error message.
	Later on, when the probe packet reaches the code SCHC C/D with a Hop		Later on, when the probe packet reaches the code SCHC C/D with a Hop
	Limit value of 2, the core SCHC C/D will, as explained in		Limit value of 2, the core SCHC C/D will, as explained in
	Section 4.1, answer back with a "Destination Unreachable" (Type = 1)		Section 4.3, answer back with a "Destination Unreachable" (Type = 1)
	"Port Unreachable" (Code = 4) ICMPv6 error message. This is what the		"Port Unreachable" (Code = 4) ICMPv6 error message. This is what the
	traceroute6 command expects. Therefore, the traceroute6 command will		traceroute6 command expects. Therefore, the traceroute6 command will
	work with LPWAN IPv6 destinations, except for the time displayed for		work with LPWAN IPv6 destinations, except for the time displayed for
	the destination, which is actually the time to its proxy.		the destination, which is actually the time to its proxy.
	However, if the probe packet happens to hit a port that matches a		However, if the probe packet happens to hit a port that matches a
	SCHC rule for that Device, the packet will be compressed with this		SCHC rule for that Device, the packet will be compressed with this
	rule and sent over the LPWAN, which is unfortunate. Forwarding of		rule and sent over the LPWAN, which is unfortunate. Forwarding of
	packets to the Device over the LPWAN should only be done from		packets to the Device over the LPWAN should only be done from
	authenticated/trusted sources anyway. Rate-limitation on top of		authenticated/trusted sources anyway. Rate-limitation on top of
	skipping to change at page 11, line 19 ¶		skipping to change at page 12, line 15 ¶
	7. IANA Considerations		7. IANA Considerations
	TODO		TODO
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[I-D.ietf-lpwan-ipv6-static-context-hc]		[I-D.ietf-lpwan-ipv6-static-context-hc]
	Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.		Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
	Zuniga, "LPWAN Static Context Header Compression (SCHC)		Zuniga, "Static Context Header Compression (SCHC) and
	and fragmentation for IPv6 and UDP", draft-ietf-lpwan-		fragmentation for LPWAN, application to UDP/IPv6", draft-
	ipv6-static-context-hc-18 (work in progress), December		ietf-lpwan-ipv6-static-context-hc-24 (work in progress),
	2018.		December 2019.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997, <https://www.rfc-		DOI 10.17487/RFC2119, March 1997,
	editor.org/info/rfc2119>.		<https://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", STD 89,		Protocol Version 6 (IPv6) Specification", STD 89,
	RFC 4443, DOI 10.17487/RFC4443, March 2006,		RFC 4443, DOI 10.17487/RFC4443, March 2006,
	<https://www.rfc-editor.org/info/rfc4443>.		<https://www.rfc-editor.org/info/rfc4443>.
	[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, <https://www.rfc-		DOI 10.17487/RFC4861, September 2007,
	editor.org/info/rfc4861>.		<https://www.rfc-editor.org/info/rfc4861>.
	[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,		[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
	"Extended ICMP to Support Multi-Part Messages", RFC 4884,		"Extended ICMP to Support Multi-Part Messages", RFC 4884,
	DOI 10.17487/RFC4884, April 2007, <https://www.rfc-		DOI 10.17487/RFC4884, April 2007,
	editor.org/info/rfc4884>.		<https://www.rfc-editor.org/info/rfc4884>.
	[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,		[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
	D., and S. Mansfield, "Guidelines for the Use of the "OAM"		D., and S. Mansfield, "Guidelines for the Use of the "OAM"
	Acronym in the IETF", BCP 161, RFC 6291,		Acronym in the IETF", BCP 161, RFC 6291,
	DOI 10.17487/RFC6291, June 2011, <https://www.rfc-		DOI 10.17487/RFC6291, June 2011,
	editor.org/info/rfc6291>.		<https://www.rfc-editor.org/info/rfc6291>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017, <https://www.rfc-		DOI 10.17487/RFC8200, July 2017,
	editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
	8.2. Informative References		8.2. Informative References
	[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)		[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
	Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,		Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
	<https://www.rfc-editor.org/info/rfc8376>.		<https://www.rfc-editor.org/info/rfc8376>.
	Authors' Addresses		Authors' Addresses
	Dominique Barthel		Dominique Barthel
	Orange SA		Orange SA
	28 chemin du Vieux Chene		28 chemin du Vieux Chene
	BP 98		BP 98
	38243 Meylan Cedex		38243 Meylan Cedex
	France		France
	Email: dominique.barthel@orange.com		Email: dominique.barthel@orange.com
	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
	Arunprabhu Kandasamy		Arunprabhu Kandasamy
	Acklio		Acklio
	1137A avenue des Champs Blancs		1137A avenue des Champs Blancs
End of changes. 32 change blocks.
	136 lines changed or deleted		186 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/