idnits 2.17.1 draft-barthel-lpwan-oam-schc-02.txt: -(555): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (2 November 2020) is 1269 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 419 -- Looks like a reference, but probably isn't: '2' on line 419 -- Looks like a reference, but probably isn't: '3' on line 419 -- Looks like a reference, but probably isn't: '4' on line 419 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan Working Group D. Barthel 3 Internet-Draft Orange SA 4 Intended status: Informational L. Toutain 5 Expires: 6 May 2021 IMT Atlantique 6 A. Kandasamy 7 Acklio 8 D. Dujovne 9 Universidad Diego Portales 10 JC. Zuniga 11 SIGFOX 12 2 November 2020 14 OAM for LPWAN using Static Context Header Compression (SCHC) 15 draft-barthel-lpwan-oam-schc-02 17 Abstract 19 With IP protocols now generalizing to constrained networks, users 20 expect to be able to Operate, Administer and Maintain them with the 21 familiar tools and protocols they already use on less constrained 22 networks. 24 OAM uses specific messages sent into the data plane to measure some 25 parameters of a network. Most of the time, no explicit values are 26 sent is these messages. Network parameters are obtained from the 27 analysis of these specific messages. 29 This can be used: 31 * To detect if a host is up or down. 33 * To measure the RTT and its variation over time. 35 * To learn the path used by packets to reach a destination. 37 OAM in LPWAN is a little bit trickier since the bandwidth is limited 38 and extra traffic added by OAM can introduce perturbation on regular 39 transmission. 41 Two scenarios can be investigated: 43 * OAM coming from internet. In that case, the NGW should act as a 44 proxy and handle specifically the OAM traffic. 46 * OAM coming from LPWAN devices: This can be included into regular 47 devices but some specific devices may be installed in the LPWAN 48 network to measure its quality. 50 The primitive functionalities of OAM are achieved with the ICMPv6 51 protocol. 53 ICMPv6 defines messages that inform the source of IPv6 packets of 54 errors during packet delivery. It also defines the Echo Request/ 55 Reply messages that are used for basic network troubleshooting (ping 56 command). ICMPv6 messages are transported on IPv6. 58 This document describes how basic OAM is performed on Low Power Wide 59 Area Networks (LPWANs) by compressing ICMPv6/IPv6 headers and by 60 protecting the LPWAN network and the Device from undesirable ICMPv6 61 traffic. 63 Status of This Memo 65 This Internet-Draft is submitted in full conformance with the 66 provisions of BCP 78 and BCP 79. 68 Internet-Drafts are working documents of the Internet Engineering 69 Task Force (IETF). Note that other groups may also distribute 70 working documents as Internet-Drafts. The list of current Internet- 71 Drafts is at https://datatracker.ietf.org/drafts/current/. 73 Internet-Drafts are draft documents valid for a maximum of six months 74 and may be updated, replaced, or obsoleted by other documents at any 75 time. It is inappropriate to use Internet-Drafts as reference 76 material or to cite them other than as "work in progress." 78 This Internet-Draft will expire on 6 May 2021. 80 Copyright Notice 82 Copyright (c) 2020 IETF Trust and the persons identified as the 83 document authors. All rights reserved. 85 This document is subject to BCP 78 and the IETF Trust's Legal 86 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 87 license-info) in effect on the date of publication of this document. 88 Please review these documents carefully, as they describe your rights 89 and restrictions with respect to this document. Code Components 90 extracted from this document must include Simplified BSD License text 91 as described in Section 4.e of the Trust Legal Provisions and are 92 provided without warranty as described in the Simplified BSD License. 94 Table of Contents 96 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 97 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 98 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 99 4. Detailed behavior . . . . . . . . . . . . . . . . . . . . . . 4 100 4.1. Device does a ping . . . . . . . . . . . . . . . . . . . 4 101 4.1.1. Rule example . . . . . . . . . . . . . . . . . . . . 6 102 4.2. Device is ping'ed . . . . . . . . . . . . . . . . . . . . 6 103 4.2.1. Rule example . . . . . . . . . . . . . . . . . . . . 7 104 4.3. Device is the source of an ICMPv6 error message . . . . . 7 105 4.4. Device is the destination of an ICMPv6 error message . . 9 106 4.4.1. ICMPv6 error message compression. . . . . . . . . . . 9 107 5. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . 10 108 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 109 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 110 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 111 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 112 8.2. Informative References . . . . . . . . . . . . . . . . . 13 113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 115 1. Introduction 117 The primitive functionalities of OAM [RFC6291] are achieved with the 118 ICMPv6 protocol. 120 ICMPv6 [RFC4443] is a companion protocol to IPv6 [RFC8200]. 122 [RFC4443] defines a generic message format. This format is used for 123 messages to be sent back to the source of an IPv6 packet to inform it 124 about errors during packet delivery. 126 More specifically, [RFC4443] defines 4 error messages: Destination 127 Unreachable, Packet Too Big, Time Exceeded and Parameter Problem. 129 [RFC4443] also defines the Echo Request and Echo Reply messages, 130 which provide support for the ping application. 132 Other ICMPv6 messages are defined in other RFCs, such as an extended 133 format of the same messages [RFC4884] and other messages used by the 134 Neighbor Discovery Protocol [RFC4861]. 136 This document focuses on using Static Context Header Compression 137 (SCHC) to compress [RFC4443] messages that need to be transmitted 138 over the LPWAN network, and on having the LPWAN gateway proxying the 139 Device to save it the unwanted traffic. 141 LPWANs' salient characteristics are described in [RFC8376]. 143 2. Terminology 145 This draft re-uses the Terminology defined in [RFC8724]. 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 149 "OPTIONAL" in this document are to be interpreted as described in BCP 150 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 capitals, as shown here. 153 3. Use cases 155 In the LPWAN architecture, we can distinguish the following cases: 157 * the Device is the originator of an Echo Request message, and 158 therefore the destination of the Echo Reply message. 160 * the Device is the destination of an Echo Request message, and 161 therefore the purported source of an Echo Reply message. 163 * the Device is the (purported) source of an ICMP error message, 164 mainly in response to an incorrect incoming IPv6 message, or in 165 response to a ping request. In this case, as much as possible, 166 the core SCHC C/D should act as a proxy and originate the ICMP 167 message, so that the Device and the LPWAN network are protected 168 from this unwanted traffic. 170 * the Device is the destination of the ICMP message, mainly in 171 response to a packet sent by the Device to the network that 172 generates an error. In this case, we want the ICMP message to 173 reach the Device, and this document describes in Section 4.4.1 174 what SCHC compression should be applied. 176 These cases are further described in Section 4. 178 4. Detailed behavior 180 4.1. Device does a ping 182 If a ping request is generated by a Device, then SCHC compression 183 applies. 185 The format of an ICMPv6 Echo Request message is described in 186 Figure 1, with Type=128 and Code=0. 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Type | Code | Checksum | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Identifier | Sequence Number | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Data ... 196 +-+-+-+-+- 198 Figure 1: ICMPv6 Echo Request message format 200 If we assume that one rule will be devoted to compressing Echo 201 Request messages, then Type and Code are known in the rule to be 128 202 and 0 and can therefore be elided with the not-sent CDA. 204 Checksum can be reconstructed with the compute-checksum CDA and 205 therefore is not transmitted. 207 [RFC4443] states that Identifier and Sequence Number are meant to 208 "aid in matching Echo Replies to this Echo Request" and that they 209 "may be zero". Data is "zero or more bytes of arbitrary data". 211 We recommend that Identifier be zero, Sequence Number be a counter on 212 3 bits, and Data be zero bytes (absent). Therefore, Identifier is 213 elided with the not-sent CDA, Sequence Number is transmitted on 3 214 bits with the LSB CDA and no Data is transmitted. 216 The transmission cost of the Echo Request message is therefore the 217 size of the Rule Id + 3 bits. 219 When the destination receives the Echo Request message, it will 220 respond back with a Echo Reply message. This message bears the same 221 format as the Echo Request message but with Type = 129 (see 222 Figure 1). 224 [RFC4443] states that the Identifier, Sequence Number and Data fields 225 of the Echo Reply message shall contain the same values as the 226 invoking Echo Request message. Therefore, a rule shall be used 227 similar to that used for compressing the Echo Request message. 229 TODO: how about a shared rule for Echo Request and Echo Reply with an 230 LSB(1) CDA on the Type field? Or exploiting the Up/Down direction 231 field in the rule? 233 4.1.1. Rule example 235 The following rule gives an example of a SCHC compression. The type 236 can be elided if the direction is taken into account. Identifier is 237 ignored and generated as 0 at decompression. This implies that only 238 one single ping can be launched at any given time on a device. 239 Finally, only the least significant 8 bits of the sequence number are 240 sent on the LPWAN, allowing a serie of 255 consecutive pings. 242 +============+====+====+====+=======+==========+==========+==+======+ 243 |Field | FL | FP | DI | Value | Matching | CDA | | Sent | 244 | | | | | | Operator | | | bits | 245 +============+====+====+====+=======+==========+==========+==+======+ 246 |ICMPv6 Type | 8 | 1 | Up | 128 | equal | not-sent | | | 247 +------------+----+----+----+-------+----------+----------+--+------+ 248 |ICMPv6 Type | 8 | 1 | Dw | 129 | equal | not-sent | | | 249 +------------+----+----+----+-------+----------+----------+--+------+ 250 |ICMPv6 Code | 8 | 1 | Bi | 0 | equal | not-sent | | | 251 +------------+----+----+----+-------+----------+----------+--+------+ 252 |ICMPv6 | 16 | 1 | Bi | 0 | ignore | not-sent | | | 253 |Identifier | | | | | | | | | 254 +------------+----+----+----+-------+----------+----------+--+------+ 255 |ICMPv6 | 16 | 1 | Bi | 0 | MSB(24) | LSB | | 8 | 256 |Sequence | | | | | | | | | 257 +------------+----+----+----+-------+----------+----------+--+------+ 259 Table 1: Example of compression rule for a ping from the device 261 4.2. Device is ping'ed 263 If the Device is ping'ed (i.e., is the destination of an Echo Request 264 message), the default behavior is to avoid propagating the Echo 265 Request message over the LPWAN. 267 This is done by proxying the ping request on the core SCHC C/D. This 268 requires to add an action when the rule is selected. Instead of been 269 processed by the compressor, the packet description is processed by a 270 ping proxy. The rule is used for the selection, so CDAs are not 271 necessary. 273 The resulting behavior is shown on Figure 2 and described below: 275 Device NGW core SCHC C/D Internet Host 277 | | | Echo Request, Code=0 | 278 | | |<---------------------------| 279 | | | | 280 | | |--------------------------->| 281 | | | Echo Reply, Code=0 | 283 Figure 2: Examples of ICMPv6 Echo Request/Reply 285 4.2.1. Rule example 287 The following rule shows an example of a compression rule for pinging 288 a device. 290 +============+====+====+====+=======+==========+==========+==+======+ 291 |Field | FL | FP | DI | Value | Matching | CDA | | Sent | 292 | | | | | | Operator | | | bits | 293 +============+====+====+====+=======+==========+==========+==+======+ 294 |ICMPv6 Type | 8 | 1 | Dw | 128 | equal | not-sent | | | 295 +------------+----+----+----+-------+----------+----------+--+------+ 296 |ICMPv6 Type | 8 | 1 | Up | 129 | equal | not-sent | | | 297 +------------+----+----+----+-------+----------+----------+--+------+ 298 |ICMPv6 Code | 8 | 1 | Bi | 0 | equal | not-sent | | | 299 +------------+----+----+----+-------+----------+----------+--+------+ 300 |ICMPv6 | 16 | 1 | Bi | 0 | ignore | not-sent | | | 301 |Identifier | | | | | | | | | 302 +------------+----+----+----+-------+----------+----------+--+------+ 303 |ICMPv6 | 16 | 1 | Bi | 0 | MSB(24) | LSB | | 8 | 304 |Sequence | | | | | | | | | 305 +------------+----+----+----+-------+----------+----------+--+------+ 307 Table 2: Example of compression rule for a ping to a device 309 In this example, type and code are elided, the identifer has to be 310 sent, and the sequence number is limited to one byte. 312 4.3. Device is the source of an ICMPv6 error message 314 As stated in [RFC4443], a node should generate an ICMPv6 message in 315 response to an IPv6 packet that is malformed or which cannot be 316 processed due to some incorrect field value. 318 The general intent of this document is to spare both the Device and 319 the LPWAN network this un-necessary traffic. The incorrect packets 320 should be caught at the core SCHC C/D and the ICMPv6 notification 321 should be sent back from there. 323 Device NGW core SCHC C/D Internet Host 325 | | | Destination Port=XXX | 326 | | |<---------------------------| 327 | | | | 328 | | |--------------------------->| 329 | | | ICMPv6 Port Unreachable | 330 | | | | 331 | | | | 333 Figure 3: Example of ICMPv6 error message sent back to the Internet 335 Figure 3 shows an example of an IPv6 packet trying to reach a Device. 336 Let's assume that the port number used as destination port is not 337 "known" (needs better definition) from the core SCHC C/D. Instead of 338 sending the packet over the LPWAN and having this packet rejected by 339 the Device, the core SCHC C/D issues an ICMPv6 error message 340 "Destination Unreachable" (Type 1) with Code 1 ("Port Unreachable") 341 on behalf of the Device. 343 In that case the SCHC C/D acts as a router and MUST have a routable 344 IPv6 address to generate an ICMPv6 message. when compressing a packet 345 containing an IPv6 header, no compression rules are found and: * if a 346 rule contains some extension headers, a parameter problem may be 347 generated (type 4), * no rules contains the IPv6 prefix, a no route 348 to destination ICMPv6 message (type 0, code 0) may be generated, * a 349 prefix is found, but no devIID matches, a address unreachable ICMPv6 350 message (type 0, code 3) may be generated, * a device IPv6 address is 351 found, but no port matches, a port unreachable ICMPv6 message (type 352 0, code 4) may be generated, 354 TODO: This assumes that all ports that the Device listens to will be 355 matched by a SCHC rule. Is this the basic assumption of SCHC that 356 all packets that do not match a rule are rejected? If yes, why do 357 have fragmentation also for uncompressed packets? 359 TODO: discuss the various Type/Code that are expected to be generated 360 in response to various errors. 362 4.4. Device is the destination of an ICMPv6 error message 364 In this situation, we assume that a Device has been configured to 365 send information to a server on the Internet. If this server becomes 366 no longer accessible, an ICMPv6 message will be generated back 367 towards the Device by an intermediate router. This information can 368 be useful to the Device, for example for reducing the reporting rate 369 in case of periodic reporting of data. Therefore, we compress the 370 ICMPv6 message using SCHC and forward it to the Device over the 371 LPWAN. 373 Device NGW core SCHC C/D Internet Server 375 | | | | 376 | SCHC compressed IPv6 | | 377 |~~~~~~~~~~~|----------->|----------------------X | 378 | | | <--------------------- | 379 |<~~~~~~~~~~|------------| ICMPv6 Host unreachable | 380 |SCHC compressed ICMPv6 | | 381 | | | | 382 | | | | 384 Figure 4: Example of ICMPv6 error message sent back to the Device 386 Figure 4 illustrates this behavior. The ICMPv6 error message is 387 compressed as described in Section 4.4.1 and forwarded over the LPWAN 388 to the Device. 390 4.4.1. ICMPv6 error message compression. 392 The ICMPv6 error messages defined in [RFC4443] contain the fields 393 shown in Figure 5. 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Type | Code | Checksum | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Value | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | As much of invoking packet | 403 + as possible without the ICMPv6 packet + 404 | exceeding the minimum IPv6 MTU | 406 Figure 5: ICMPv6 Error Message format 408 [RFC4443] states that Type can take the values 1 to 4, and Code can 409 be set to values between 0 and 6. Value is unused for the 410 Destination Unreachable and Time Exceeded messages. It contains the 411 MTU for the Packet Too Big message and a pointer to the byte causing 412 the error for the Parameter Error message. Therefore, Value is never 413 expected to be greater than 1280 in LPWAN networks. 415 The following generic rule can therefore be used to compress all 416 ICMPv6 error messages as defined today. More specific rules can also 417 be defined to achieve better compression of some error messages. 419 The Type field can be associated to a matching list [1, 2, 3, 4] and 420 is therefore compressed down to 2 bits. Code can be reduced to 3 421 bits using the LSB CDA. Value can be sent on 11 bits using the LSB 422 CDA, but if the Device is known to send smaller packets, then the 423 size of this field can be further reduced. 425 By [RFC4443], the rest of the ICMPv6 message must contain as much as 426 possible of the IPv6 offending (invoking) packet that triggered this 427 ICMPv6 error message. This information is used to try and identify 428 the SCHC rule that was used to decompress the offending IPv6 packet. 429 If the rule can be found then the Rule Id is added at the end of the 430 compressed ICMPv6 message. Otherwise the compressed packet ends with 431 the compressed Value field. 433 [RFC4443] states that the "ICMPv6 error message MUST include as much 434 of the IPv6 offending (invoking) packet ... as possible". In order 435 to comply with this requirement, if there is enough information in 436 the incoming ICMPv6 message for the core SCHC C/D to identify the 437 rule that has been used to decompress the erroneous IPv6 packet, this 438 Rule Id must be sent in the compressed ICMPv6 message to the Device. 439 TODO: the erroneous IPv6 packet header (not just the Rule Id) should 440 be sent back. This includes the Rule Id and the compression residue. 441 This means the SCHC C/D uses the context backwards (in the reverse 442 direction). How does the Device know it must also use the context 443 backwards? 445 TODO: how does one know that the "payload" of a compressed-header 446 packet is in fact another compressed header? 448 5. Traceroute 450 The traceroute6 program sends successive probe packets destined to a 451 chosen target but with the Hop Limit value successively incremented 452 from the initial value 1. 454 It expects to receive a "Time Exceeded" (Type = 3) "Hop Limit" (Code 455 = 0) ICMPv6 error message back from the successive routers along the 456 path to the destination. 458 The probe packet is usually a UDP datagram, but can also be a TCP 459 datagram or even an ICMPv6 message. The destination port is chosen 460 in the unassigned range in hope that the destination, when eventually 461 reached, will respond with a "Destination Unreachable" (Type = 1) 462 "Port Unreachable" (Code = 4) ICMPv6 error message. 464 It is not anticipated that a Device will want to traceroute a 465 destination on the Internet. 467 By contrast, a host on the Internet may attempt to traceroute an IPv6 468 address that is assigned to an LPWAN device. This is described in 469 Figure 6. 471 Device NGW core SCHC C/D Internet 473 | | | Hop Limit=1, Dest Port=XXX | 474 | | |<---------------------------| 475 | | | | 476 | | |--------------------------->| 477 | | | ICMPv6 Hop Limit error | 478 | | | | 479 | | | | 480 | | | Hop Limit=2, Dest Port=XXX | 481 | | |<---------------------------| 482 | | | | 483 | | |--------------------------->| 484 | | | ICMPv6 Port Unreachable | 486 Figure 6: Example of traceroute to the LPWAN Device 488 When the probe packet first reaches the core SCHC C/D, its remaining 489 Hop Limit is 1. The core SCHC C/D will respond back with a "Time 490 Exceeded" (Type = 3) "Hop Limit" (Code = 0) ICMPv6 error message. 491 Later on, when the probe packet reaches the code SCHC C/D with a Hop 492 Limit value of 2, the core SCHC C/D will, as explained in 493 Section 4.3, answer back with a "Destination Unreachable" (Type = 1) 494 "Port Unreachable" (Code = 4) ICMPv6 error message. This is what the 495 traceroute6 command expects. Therefore, the traceroute6 command will 496 work with LPWAN IPv6 destinations, except for the time displayed for 497 the destination, which is actually the time to its proxy. 499 However, if the probe packet happens to hit a port that matches a 500 SCHC rule for that Device, the packet will be compressed with this 501 rule and sent over the LPWAN, which is unfortunate. Forwarding of 502 packets to the Device over the LPWAN should only be done from 503 authenticated/trusted sources anyway. Rate-limitation on top of 504 authentication will mitigate this nuisance. 506 6. Security considerations 508 TODO 510 7. IANA Considerations 512 TODO 514 8. References 516 8.1. Normative References 518 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 519 Requirement Levels", BCP 14, RFC 2119, 520 DOI 10.17487/RFC2119, March 1997, 521 . 523 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 524 Control Message Protocol (ICMPv6) for the Internet 525 Protocol Version 6 (IPv6) Specification", STD 89, 526 RFC 4443, DOI 10.17487/RFC4443, March 2006, 527 . 529 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 530 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 531 DOI 10.17487/RFC4861, September 2007, 532 . 534 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 535 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 536 DOI 10.17487/RFC4884, April 2007, 537 . 539 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 540 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 541 Acronym in the IETF", BCP 161, RFC 6291, 542 DOI 10.17487/RFC6291, June 2011, 543 . 545 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 546 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 547 May 2017, . 549 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 550 (IPv6) Specification", STD 86, RFC 8200, 551 DOI 10.17487/RFC8200, July 2017, 552 . 554 [RFC8724] Minaburo, A., Toutain, L., Gomez, C., Barthel, D., and JC. 555 Zúñiga, "SCHC: Generic Framework for Static Context Header 556 Compression and Fragmentation", RFC 8724, 557 DOI 10.17487/RFC8724, April 2020, 558 . 560 8.2. Informative References 562 [RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN) 563 Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018, 564 . 566 Authors' Addresses 568 Dominique Barthel 569 Orange SA 570 28 chemin du Vieux Chene 571 BP 98 572 38243 Meylan Cedex 573 France 575 Email: dominique.barthel@orange.com 577 Laurent Toutain 578 IMT Atlantique 579 2 rue de la Chataigneraie 580 CS 17607 581 35576 Cesson-Sevigne Cedex 582 France 584 Email: laurent.toutain@imt-atlantique.fr 586 Arunprabhu Kandasamy 587 Acklio 588 1137A avenue des Champs Blancs 589 35510 Cesson-Sevigne Cedex 590 France 592 Email: arun@ackl.io 593 Diego Dujovne 594 Universidad Diego Portales 595 Vergara 432 596 Santiago 597 Chile 599 Email: diego.dujovne@mail.udp.cl 601 Juan Carlos Zuniga 602 SIGFOX 603 425 rue Jean Rostand 604 31670 Labege 605 France 607 Email: JuanCarlos.Zuniga@sigfox.com