< draft-barthel-lpwan-oam-schc-01.txt		draft-barthel-lpwan-oam-schc-02.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: September 11, 2020 IMT Atlantique		Expires: 6 May 2021 IMT Atlantique
	A. Kandasamy		A. Kandasamy
	Acklio		Acklio
	D. Dujovne		D. Dujovne
	Universidad Diego Portales		Universidad Diego Portales
	JC. Zuniga		JC. Zuniga
	SIGFOX		SIGFOX
	March 10, 2020		2 November 2020
	OAM for LPWAN using Static Context Header Compression (SCHC)		OAM for LPWAN using Static Context Header Compression (SCHC)
	draft-barthel-lpwan-oam-schc-01		draft-barthel-lpwan-oam-schc-02
	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
	sent is these messages. Network parameters are obtained from the		sent is these messages. Network parameters are obtained from the
	analysis of these specific messages.		analysis of these specific messages.
	This can be used:		This can be used:
	o To detect if a host is up or down.		* To detect if a host is up or down.
	o To measure the RTT and its variation over time.		* To measure the RTT and its variation over time.
	o To learn the path used by packets to reach a destination.		* To learn the path used by packets to reach a destination.
	OAM in LPWAN is a little bit trickier since the bandwidth is limited		OAM in LPWAN is a little bit trickier since the bandwidth is limited
	and extra traffic added by OAM can introduce perturbation on regular		and extra traffic added by OAM can introduce perturbation on regular
	transmission.		transmission.
	Two scenarios can be investigated:		Two scenarios can be investigated:
	o OAM coming from internet. In that case, the NGW should act as a		* OAM coming from internet. In that case, the NGW should act as a
	proxy and handle specifically the OAM traffic.		proxy and handle specifically the OAM traffic.
	o OAM coming from LPWAN devices: This can be included into regular		* OAM coming from LPWAN devices: This can be included into regular
	devices but some specific devices may be installed in the LPWAN		devices but some specific devices may be installed in the LPWAN
	network to measure its quality.		network to measure its quality.
	The primitive functionalities of OAM are achieved with the ICMPv6		The primitive functionalities of OAM are achieved with the ICMPv6
	protocol.		protocol.
	ICMPv6 defines messages that inform the source of IPv6 packets of		ICMPv6 defines messages that inform the source of IPv6 packets of
	errors during packet delivery. It also defines the Echo Request/		errors during packet delivery. It also defines the Echo Request/
	Reply messages that are used for basic network troubleshooting (ping		Reply messages that are used for basic network troubleshooting (ping
	command). ICMPv6 messages are transported on IPv6.		command). ICMPv6 messages are transported on IPv6.
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	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 https://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 September 11, 2020.		This Internet-Draft will expire on 6 May 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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 (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		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 does a ping . . . . . . . . . . . . . . . . . . . 4		4.1. Device does a ping . . . . . . . . . . . . . . . . . . . 4
	4.1.1. Rule example . . . . . . . . . . . . . . . . . . . . 6		4.1.1. Rule example . . . . . . . . . . . . . . . . . . . . 6
	4.2. Device is ping'ed . . . . . . . . . . . . . . . . . . . . 6		4.2. Device is ping'ed . . . . . . . . . . . . . . . . . . . . 6
	4.2.1. Rule example . . . . . . . . . . . . . . . . . . . . 7		4.2.1. Rule example . . . . . . . . . . . . . . . . . . . . 7
	4.3. Device is the source of an ICMPv6 error message . . . . . 7		4.3. Device is the source of an ICMPv6 error message . . . . . 7
	4.4. Device is the destination of an ICMPv6 error message . . 8		4.4. Device is the destination of an ICMPv6 error message . . 9
	4.4.1. ICMPv6 error message compression. . . . . . . . . . . 9		4.4.1. ICMPv6 error message compression. . . . . . . . . . . 9
	5. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security considerations . . . . . . . . . . . . . . . . . . . 11		6. Security considerations . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . 12		8.1. Normative References . . . . . . . . . . . . . . . . . . 12
	8.2. Informative References . . . . . . . . . . . . . . . . . 13		8.2. Informative References . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		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.
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	This document focuses on using Static Context Header Compression		This document focuses on using Static Context Header Compression
	(SCHC) to compress [RFC4443] messages that need to be transmitted		(SCHC) to compress [RFC4443] messages that need to be transmitted
	over the LPWAN network, and on having the LPWAN gateway proxying the		over the LPWAN network, and on having the LPWAN gateway proxying the
	Device to save it the unwanted traffic.		Device to save it the unwanted traffic.
	LPWANs' salient characteristics are described in [RFC8376].		LPWANs' salient characteristics are described in [RFC8376].
	2. Terminology		2. Terminology
	This draft re-uses the Terminology defined in		This draft re-uses the Terminology defined in [RFC8724].
	[I-D.ietf-lpwan-ipv6-static-context-hc].
	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		* the Device is the originator of an Echo Request message, and
	therefore the destination of the Echo Reply message.		therefore the destination of the Echo Reply message.
	o the Device is the destination of an Echo Request message, and		* the Device is the destination of an Echo Request message, and
	therefore the purported source of an Echo Reply message.		therefore the purported source of an Echo Reply message.
	o the Device is the (purported) source of an ICMP error message,		* 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		* 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 4.4.1
	Section 4.4.1 what SCHC compression should be applied.		what SCHC compression should be applied.
	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 does a ping		4.1. Device does a ping
	If a ping request is generated by a Device, then SCHC compression		If a ping request is generated by a Device, then SCHC compression
	applies.		applies.
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 15 ¶
	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 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Identifier | Sequence Number |		| Identifier | Sequence Number |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Data ...		| Data ...
	+-+-+-+-+-		+-+-+-+-+-
	Figure 1: ICMPv6 Echo Request message format		Figure 1: ICMPv6 Echo Request message format
	If we assume that one rule will be devoted to compressing Echo		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		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.		and 0 and can therefore be elided with the not-sent CDA.
	Checksum can be reconstructed with the compute-checksum CDA and		Checksum can be reconstructed with the compute-checksum CDA and
	therefore is not transmitted.		therefore is not transmitted.
	[RFC4443] states that Identifier and Sequence Number are meant to		[RFC4443] states that Identifier and Sequence Number are meant to
	"aid in matching Echo Replies to this Echo Request" and that they		"aid in matching Echo Replies to this Echo Request" and that they
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	4.1.1. Rule example		4.1.1. Rule example
	The following rule gives an example of a SCHC compression. The type		The following rule gives an example of a SCHC compression. The type
	can be elided if the direction is taken into account. Identifier is		can be elided if the direction is taken into account. Identifier is
	ignored and generated as 0 at decompression. This implies that only		ignored and generated as 0 at decompression. This implies that only
	one single ping can be launched at any given time on a device.		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		Finally, only the least significant 8 bits of the sequence number are
	sent on the LPWAN, allowing a serie of 255 consecutive pings.		sent on the LPWAN, allowing a serie of 255 consecutive pings.
	+----------------+--+--+--+---------+--------+------------++------+		+============+====+====+====+=======+==========+==========+==+======+
	| Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent |		|Field | FL | FP | DI | Value | Matching | CDA | | Sent |
	| | | | | | Opera. | Action ||(bits)|		| | | | | | Operator | | | bits |
	+----------------+--+--+--+---------+---------------------++------+		+============+====+====+====+=======+==========+==========+==+======+
	|ICMPv6 Type |8 |1 |Up|128 | equal | not-sent || |		|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 Type | 8 | 1 | Dw | 129 | equal | not-sent | | |
	|ICMPv6 Identif. |16|1 |Bi|0 | ignore | not-sent || |		+------------+----+----+----+-------+----------+----------+--+------+
	|ICMPv6 Sequence |16|1 |Bi|0 | MSB(24)| LSB || 8 |		|ICMPv6 Code | 8 | 1 | Bi | 0 | equal | not-sent | | |
	+================+==+==+==+=========+========+============++======+		+------------+----+----+----+-------+----------+----------+--+------+
			|ICMPv6 | 16 | 1 | Bi | 0 | ignore | not-sent | | |
			|Identifier | | | | | | | | |
			+------------+----+----+----+-------+----------+----------+--+------+
			|ICMPv6 | 16 | 1 | Bi | 0 | MSB(24) | LSB | | 8 |
			|Sequence | | | | | | | | |
			+------------+----+----+----+-------+----------+----------+--+------+
	Figure 2: Example of compression rule for a ping from the device		Table 1: Example of compression rule for a ping from the device
	4.2. Device is ping'ed		4.2. Device is ping'ed
	If the Device is ping'ed (i.e., is the destination of an Echo Request		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		message), the default behavior is to avoid propagating the Echo
	Request message over the LPWAN.		Request message over the LPWAN.
	This is done by proxying the ping request on the core SCHC C/D. This		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		requires to add an action when the rule is selected. Instead of been
	processed by the compressor, the packet description is processed by a		processed by the compressor, the packet description is processed by a
	ping proxy. The rule is used for the selection, so CDAs are not		ping proxy. The rule is used for the selection, so CDAs are not
	necessary.		necessary.
	The resulting behavior is shown on Figure 3 and described below:		The resulting behavior is shown on Figure 2 and described below:
	Device NGW core SCHC C/D Internet Host		Device NGW core SCHC C/D Internet Host
	| | | Echo Request, Code=0 |		| | | Echo Request, Code=0 |
	| | |<---------------------------|		| | |<---------------------------|
	| | | |		| | | |
	| | |--------------------------->|		| | |--------------------------->|
	| | | Echo Reply, Code=0 |		| | | Echo Reply, Code=0 |
	Figure 3: Examples of ICMPv6 Echo Request/Reply		Figure 2: Examples of ICMPv6 Echo Request/Reply
	4.2.1. Rule example		4.2.1. Rule example
	The following rule shows an example of a compression rule for pinging		The following rule shows an example of a compression rule for pinging
	a device.		a device.
	+----------------+--+--+--+---------+--------+------------++------+		+============+====+====+====+=======+==========+==========+==+======+
	| Field |FL|FP|DI| Value | Match | Comp Decomp|| Sent |		|Field | FL | FP | DI | Value | Matching | CDA | | Sent |
	| | | | | | Opera. | Action ||(bits)|		| | | | | | Operator | | | bits |
	+----------------+--+--+--+---------+---------------------++------+		+============+====+====+====+=======+==========+==========+==+======+
	|ICMPv6 Type |8 |1 |Dw|128 | equal | not-sent || |		|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 Type | 8 | 1 | Up | 129 | equal | not-sent | | |
	|ICMPv6 Identif. |16|1 |Bi|0 | ignore | value-sent || |		+------------+----+----+----+-------+----------+----------+--+------+
	|ICMPv6 Sequence |16|1 |Bi|0 | MSB(24)| LSB || 8 |		|ICMPv6 Code | 8 | 1 | Bi | 0 | equal | not-sent | | |
	+================+==+==+==+=========+========+============++======+		+------------+----+----+----+-------+----------+----------+--+------+
			|ICMPv6 | 16 | 1 | Bi | 0 | ignore | not-sent | | |
			|Identifier | | | | | | | | |
			+------------+----+----+----+-------+----------+----------+--+------+
			|ICMPv6 | 16 | 1 | Bi | 0 | MSB(24) | LSB | | 8 |
			|Sequence | | | | | | | | |
			+------------+----+----+----+-------+----------+----------+--+------+
	Figure 4: Example of compression rule for a ping to a device		Table 2: Example of compression rule for a ping to a device
	In this example, type and code are elided, the identifer has to be		In this example, type and code are elided, the identifer has to be
	sent, and the sequence number is limited to one byte.		sent, and the sequence number is limited to one byte.
	4.3. Device is the source of an ICMPv6 error message		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.
	skipping to change at page 7, line 47 ¶		skipping to change at page 8, line 15 ¶
	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 5: Example of ICMPv6 error message sent back to the Internet		Figure 3: Example of ICMPv6 error message sent back to the Internet
	Figure 5 shows an example of an IPv6 packet trying to reach a Device.		Figure 3 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		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		IPv6 address to generate an ICMPv6 message. when compressing a packet
	containing an IPv6 header, no compression rules are found and: * if a		containing an IPv6 header, no compression rules are found and: * if a
	skipping to change at page 9, line 16 ¶		skipping to change at page 9, line 27 ¶
	| | | |		| | | |
	| SCHC compressed IPv6 | |		| SCHC compressed IPv6 | |
	|~~~~~~~~~~~|----------->|----------------------X |		|~~~~~~~~~~~|----------->|----------------------X |
	| | | <--------------------- |		| | | <--------------------- |
	|<~~~~~~~~~~|------------| ICMPv6 Host unreachable |		|<~~~~~~~~~~|------------| ICMPv6 Host unreachable |
	|SCHC compressed ICMPv6 | |		|SCHC compressed ICMPv6 | |
	| | | |		| | | |
	| | | |		| | | |
	Figure 6: Example of ICMPv6 error message sent back to the Device		Figure 4: Example of ICMPv6 error message sent back to the Device
	Figure 6 illustrates this behavior. The ICMPv6 error message is		Figure 4 illustrates this behavior. The ICMPv6 error message is
	compressed as described in Section 4.4.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.4.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 7.		shown in Figure 5.
	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 7: ICMPv6 Error Message format		Figure 5: 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 11, line 7 ¶		skipping to change at page 11, line 20 ¶
	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 8.		Figure 6.
	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 8: Example of traceroute to the LPWAN Device		Figure 6: 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.3, 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
	skipping to change at page 12, line 13 ¶		skipping to change at page 12, line 20 ¶
	TODO		TODO
	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]
	Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and J.
	Zuniga, "Static Context Header Compression (SCHC) and
	fragmentation for LPWAN, application to UDP/IPv6", draft-
	ietf-lpwan-ipv6-static-context-hc-24 (work in progress),
	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,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-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>.
	skipping to change at page 13, line 10 ¶		skipping to change at page 13, line 10 ¶
	[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,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
			[RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC.
			Zúñiga, "SCHC: Generic Framework for Static Context Header
			Compression and Fragmentation", RFC 8724,
			DOI 10.17487/RFC8724, April 2020,
			<https://www.rfc-editor.org/info/rfc8724>.
	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
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 15 ¶
	Universidad Diego Portales		Universidad Diego Portales
	Vergara 432		Vergara 432
	Santiago		Santiago
	Chile		Chile
	Email: diego.dujovne@mail.udp.cl		Email: diego.dujovne@mail.udp.cl
	Juan Carlos Zuniga		Juan Carlos Zuniga
	SIGFOX		SIGFOX
	425 rue Jean Rostand		425 rue Jean Rostand
	Labege 31670		31670 Labege
	France		France
	Email: JuanCarlos.Zuniga@sigfox.com		Email: JuanCarlos.Zuniga@sigfox.com
End of changes. 36 change blocks.
	68 lines changed or deleted		77 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/