idnits 2.17.00 (12 Aug 2021) /tmp/idnits14536/draft-barthel-icmpv6-schc-00.txt: 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: ---------------------------------------------------------------------------- No issues found here. 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 (October 28, 2017) is 1666 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 237 -- Looks like a reference, but probably isn't: '2' on line 237 -- Looks like a reference, but probably isn't: '3' on line 237 -- Looks like a reference, but probably isn't: '4' on line 237 == Outdated reference: draft-ietf-lpwan-ipv6-static-context-hc has been published as RFC 8724 == Outdated reference: draft-ietf-lpwan-overview has been published as RFC 8376 Summary: 0 errors (**), 0 flaws (~~), 3 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: May 1, 2018 Institut MINES TELECOM; IMT Atlantique 6 A. Kandasamy 7 Acklio 8 October 28, 2017 10 LPWAN Static Context Header Compression (SCHC) for ICMPv6 11 draft-barthel-icmpv6-schc-00 13 Abstract 15 ICMPv6 is a companion protocol to IPv6. It defines messages that 16 inform the source of IPv6 packets of errors during packet delivery. 17 It also defines the Echo Request/Reply messages that are used for 18 basic network troubleshooting (ping command). ICMPv6 messages are 19 transported on IPv6. 21 This document describes how to adapt ICMPv6 to Low Power Wide Area 22 Networks (LPWANs) by compressing ICMPv6/IPv6 headers and by 23 protecting the LPWAN network and the Device from undesirable ICMPv6 24 traffic. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 1, 2018. 43 Copyright Notice 45 Copyright (c) 2017 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Detailed behavior . . . . . . . . . . . . . . . . . . . . . . 4 64 4.1. Device is the source of an ICMPv6 error message . . . . . 4 65 4.2. Device is the destination of an ICMPv6 error message . . 4 66 4.2.1. ICMPv6 error message compression. . . . . . . . . . . 5 67 4.3. Device does a ping . . . . . . . . . . . . . . . . . . . 6 68 4.4. Device is ping'ed . . . . . . . . . . . . . . . . . . . . 8 69 5. Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 8.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 ICMPv6 [RFC4443] is a companion protocol to IPv6 [RFC8200]. 81 [RFC4443] defines a generic message format. This format is used for 82 messages to be sent back to the source of an IPv6 packet to inform it 83 about errors during packet delivery. 85 More specifically, [RFC4443] defines 4 error messages: Destination 86 Unreachable, Packet Too Big, Time Exceeded and Parameter Problem. 88 [RFC4443] also defines the Echo Request and Echo Reply messages, 89 which provide support for the ping application. 91 Other ICMPv6 messages are defined in other RFCs, such as an extended 92 format of the same messages [RFC4884] and other messages used by the 93 Neighbor Discovery Protocol [RFC4861]. 95 This document focuses on using Static Context Header Compression 96 (SCHC) to compress [RFC4443] messages that need to be transmitted 97 over the LPWAN network, and on having the LPWAN gateway proxying the 98 Device to save it the unwanted traffic. 100 LPWANs' salient characteristics are described in 101 [I-D.ietf-lpwan-overview] 103 2. Terminology 105 This draft re-uses the Terminology defined in 106 [I-D.ietf-lpwan-ipv6-static-context-hc]. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described in BCP 111 14 [RFC2119] [RFC8174] when, and only when, they appear in all 112 capitals, as shown here. 114 3. Use cases 116 In the LPWAN architecture, we can distinguish the following cases: 118 o the Device is the (purported) source of an ICMP error message, 119 mainly in response to an incorrect incoming IPv6 message, or in 120 response to a ping request. In this case, as much as possible, 121 the core SCHC C/D should act as a proxy and originate the ICMP 122 message, so that the Device and the LPWAN network are protected 123 from this unwanted traffic. 125 o the Device is the destination of the ICMP message, mainly in 126 response to a packet sent by the Device to the network that 127 generates an error. In this case, we want the ICMP message to 128 reach the Device, and this document describes in section 129 Section 4.2.1 what SCHC compression should be applied. 131 o the Device is the originator of an Echo Request message, and 132 therefore the destination of the Echo Reply message. 134 o the Device is the destination of an Echo Request message, and 135 therefore the purported source of an Echo Reply message. 137 These cases are further described in Section 4. 139 4. Detailed behavior 141 4.1. Device is the source of an ICMPv6 error message 143 As stated in [RFC4443], a node should generate an ICMPv6 message in 144 response to an IPv6 packet that is malformed or which cannot be 145 processed due to some incorrect field value. 147 The general intent of this document is to spare both the Device and 148 the LPWAN network this un-necessary traffic. The incorrect packets 149 should be caught at the core SCHC C/D and the ICMPv6 notification 150 should be sent back from there. 152 Device NGW core SCHC C/D Internet Host 154 | | | Destination Port=XXX | 155 | | |<---------------------------| 156 | | | | 157 | | |--------------------------->| 158 | | | ICMPv6 Port Unreachable | 159 | | | | 160 | | | | 162 Figure 1: Example of ICMPv6 error message sent back to the Internet 164 Figure 1 shows an example of an IPv6 packet trying to reach a Device. 165 Let's assume that the port number used as destination port is not 166 "known" (needs better definition) from the core SCHC C/D. Instead of 167 sending the packet over the LPWAN and having this packet rejected by 168 the Device, the core SCHC C/D issues an ICMPv6 error message 169 "Destination Unreachable" (Type 1) with Code 1 ("Port Unreachable") 170 on behalf of the Device. 172 TODO: This assumes that all ports that the Device listens to will be 173 matched by a SCHC rule. Is this the basic assumption of SCHC that 174 all packets that do not match a rule are rejected? If yes, why do 175 have fragmentation also for uncompressed packets? 177 TODO: discuss the various Type/Code that are expected to be generated 178 in response to various errors. 180 4.2. Device is the destination of an ICMPv6 error message 182 In this situation, we assume that a Device has been configured to 183 send information to a server on the Internet. If this server becomes 184 no longer accessible, an ICMPv6 message will be generated back 185 towards the Device by an intermediate router. This information can 186 be useful to the Device, for example for reducing the reporting rate 187 in case of periodic reporting of data. Therefore, we compress the 188 ICMPv6 message using SCHC and forward it to the Device over the 189 LPWAN. 191 Device NGW core SCHC C/D Internet Server 193 | | | | 194 | SCHC compressed IPv6 | | 195 |~~~~~~~~~~~|----------->|----------------------X | 196 | | | <--------------------- | 197 |<~~~~~~~~~~|------------| ICMPv6 Host unreachable | 198 |SCHC compressed ICMPv6 | | 199 | | | | 200 | | | | 202 Figure 2: Example of ICMPv6 error message sent back to the Device 204 Figure 2 illustrates this behavior. The ICMPv6 error message is 205 compressed as described in Section 4.2.1 and forwarded over the LPWAN 206 to the Device. 208 4.2.1. ICMPv6 error message compression. 210 The ICMPv6 error messages defined in [RFC4443] contain the fields 211 shown in Figure 3. 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type | Code | Checksum | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Value | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | As much of invoking packet | 221 + as possible without the ICMPv6 packet + 222 | exceeding the minimum IPv6 MTU | 224 Figure 3: ICMPv6 Error Message format 226 [RFC4443] states that Type can take the values 1 to 4, and Code can 227 be set to values between 0 and 6. Value is unused for the 228 Destination Unreachable and Time Exceeded messages. It contains the 229 MTU for the Packet Too Big message and a pointer to the byte causing 230 the error for the Parameter Error message. Therefore, Value is never 231 expected to be greater than 1280 in LPWAN networks. 233 The following generic rule can therefore be used to compress all 234 ICMPv6 error messages as defined today. More specific rules can also 235 be defined to achieve better compression of some error messages. 237 The Type field can be associated to a matching list [1, 2, 3, 4] and 238 is therefore compressed down to 2 bits. Code can be reduced to 3 239 bits using the LSB CDA. Value can be sent on 11 bits using the LSB 240 CDA, but if the Device is known to send smaller packets, then the 241 size of this field can be further reduced. 243 By [RFC4443], the rest of the ICMPv6 message must contain as much as 244 possible of the IPv6 offending (invoking) packet that triggered this 245 ICMPv6 error message. This information is used to try and identify 246 the SCHC rule that was used to decompress the offending IPv6 packet. 247 If the rule can be found then the Rule Id is added at the end of the 248 compressed ICMPv6 message. Otherwise the compressed packet ends with 249 the compressed Value field. 251 [RFC4443] states that the "ICMPv6 error message MUST include as much 252 of the IPv6 offending (invoking) packet ... as possible". In order 253 to comply with this requirement, if there is enough information in 254 the incoming ICMPv6 message for the core SCHC C/D to identify the 255 rule that has been used to decompress the erroneous IPv6 packet, this 256 Rule Id must be sent in the compressed ICMPv6 message to the Device. 257 TODO: the erroneous IPv6 packet header (not just the Rule Id) should 258 be sent back. This includes the Rule Id and the compression residue. 259 This means the SCHC C/D uses the context backwards (in the reverse 260 direction). How does the Device know it must also use the context 261 backwards? 263 TODO: how does one know that the "payload" of a compressed-header 264 packet is in fact another compressed header? 266 4.3. Device does a ping 268 If a ping request is generated by a Device, then SCHC compression 269 applies. 271 The format of an ICMPv6 Echo Request message is described in 272 Figure 4, with Type=128 and Code=0. 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type | Code | Checksum | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Identifier | Sequence Number | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Data ... 282 +-+-+-+-+- 284 Figure 4: ICMPv6 Echo Request message format 286 If we assume that one rule will be devoted to compressing Echo 287 Request messages, then Type and Code are known in the rule to be 128 288 and 0 and can therefore be elided with the not-sent CDA. 290 Checksum can be reconstructed with the compute-checksum CDA and 291 therefore is not transmitted. 293 [RFC4443] states that Identifier and Sequence Number are meant to 294 "aid in matching Echo Replies to this Echo Request" and that they 295 "may be zero". Data is "zero or more bytes of arbitrary data". 297 We recommend that Identifier be zero, Sequence Number be a counter on 298 3 bits, and Data be zero bytes (absent). Therefore, Identifier is 299 elided with the not-sent CDA, Sequence Number is transmitted on 3 300 bits with the LSB CDA and no Data is transmitted. 302 The transmission cost of the Echo Request message is therefore the 303 size of the Rule Id + 3 bits. 305 When the destination receives the Echo Request message, it will 306 respond back with a Echo Reply message. This message bears the same 307 format as the Echo Request message but with Type = 129 (see 308 Figure 4). 310 [RFC4443] states that the Identifier, Sequence Number and Data fields 311 of the Echo Reply message shall contain the same values as the 312 invoking Echo Request message. Therefore, a rule shall be used 313 similar to that used for compressing the Echo Request message. 315 TODO: how about a shared rule for Echo Request and Echo Reply with an 316 LSB(1) CDA on the Type field? Or exploiting the Up/Down direction 317 field in the rule? 319 4.4. Device is ping'ed 321 If the Device is ping'ed (i.e., is the destination of an Echo Request 322 message), the default behavior is to avoid propagating the Echo 323 Request message over the LPWAN. 325 This is the recommended behavior with the Code 0 (default value) of 326 the Echo Request message. In addition, this document defines two 327 other Code values to achieve two other behaviors. 329 The resulting three behaviors are shown on Figure 5 and described 330 below: 332 Device NGW core SCHC C/D Internet Host 334 | | | Echo Request, Code=0 | 335 | | |<---------------------------| 336 | | | | 337 | | |--------------------------->| 338 | | | Echo Reply, Code=0 | 339 | | | | 340 | | | Echo Request, Code=1 | 341 | |<==========>|<---------------------------| 342 | | | | 343 | | |--------------------------->| 344 | | | Echo Reply, Code=1 | 345 | | | last seen | 346 | | | | 347 | | | Echo Request, Code=2 | 348 |<~~~~~~~~~~|------------|<---------------------------| 349 | | | | 350 |~~~~~~~~~~~|----------->|--------------------------->| 351 | | | Echo Reply, Code=2 | 352 | | | last seen | 353 | | | | 355 Figure 5: Examples of ICMPv6 Echo Request/Reply 357 o Code = 0: The Echo Request message is not propagated on the LPWAN 358 to the Device. If the SCHC C/D finds a rule in the context with 359 the IPv6 address of the Device, it responds with an Echo Reply on 360 behalf of the Device. If no rule is found with that IPv6 address, 361 the SCHC C/D does not respond. 363 TODO: again, we are assuming that no compression rule is equivalent 364 to the device not providing the service. 366 o Code = 1: the SCHC C/D queries the NGW (or maintains a local 367 database) and answers with the number of seconds since the Device 368 last transmission. 370 TODO: what does it mean to answer "with the number of seconds ..."? 371 There is no such field in an Echo Reply message. Do we overwrite one 372 of the fields (Identifier, Sequencer Number, Data)? They are all 373 supposed to be copied from the Echo Request. Do we change their 374 definition with Code==1 or Code==2? 376 o Code = 2: the SCHC C/D compresses the ICMPv6 message and forwards 377 it to the Device. The Echo Reply message sent by the Device is 378 also compressed. Since the Echo Request message comes from the 379 Internet, the values of the Identifier, Sequence Number and Data 380 fields cannot be known in advance, and therefore must be 381 transmitted. However, it is likely that the Echo Request with 382 Code 2 will be firewalled from the Internet and restricted to 383 authorized users. Therefore, the Echo Request message can be 384 assumed to have the same content as recommended in Section 4.3, 385 and the same compression rules apply. 387 5. Traceroute 389 The traceroute6 program sends successive probe packets destined to a 390 chosen target but with the Hop Limit value successively incremented 391 from the initial value 1. 393 It expects to receive a "Time Exceeded" (Type = 3) "Hop Limit" (Code 394 = 0) ICMPv6 error message back from the successive routers along the 395 path to the destination. 397 The probe packet is usually a UDP datagram, but can also be a TCP 398 datagram or even an ICMPv6 message. The destination port is chosen 399 in the unassigned range in hope that the destination, when eventually 400 reached, will respond with a "Destination Unreachable" (Type = 1) 401 "Port Unreachable" (Code = 4) ICMPv6 error message. 403 It is not anticipated that a Device will want to traceroute a 404 destination on the Internet. 406 By contrast, a host on the Internet may attempt to traceroute an IPv6 407 address that is assigned to an LPWAN device. This is described in 408 Figure 6. 410 Device NGW core SCHC C/D Internet 412 | | | Hop Limit=1, Dest Port=XXX | 413 | | |<---------------------------| 414 | | | | 415 | | |--------------------------->| 416 | | | ICMPv6 Hop Limit error | 417 | | | | 418 | | | | 419 | | | Hop Limit=2, Dest Port=XXX | 420 | | |<---------------------------| 421 | | | | 422 | | |--------------------------->| 423 | | | ICMPv6 Port Unreachable | 425 Figure 6: Example of traceroute to the LPWAN Device 427 When the probe packet first reaches the core SCHC C/D, its remaining 428 Hop Limit is 1. The core SCHC C/D will respond back with a "Time 429 Exceeded" (Type = 3) "Hop Limit" (Code = 0) ICMPv6 error message. 430 Later on, when the probe packet reaches the code SCHC C/D with a Hop 431 Limit value of 2, the core SCHC C/D will, as explained in 432 Section 4.1, answer back with a "Destination Unreachable" (Type = 1) 433 "Port Unreachable" (Code = 4) ICMPv6 error message. This is what the 434 traceroute6 command expects. Therefore, the traceroute6 command will 435 work with LPWAN IPv6 destinations, except for the time displayed for 436 the destination, which is actually the time to its proxy. 438 However, if the probe packet happens to hit a port that matches a 439 SCHC rule for that Device, the packet will be compressed with this 440 rule and sent over the LPWAN, which is unfortunate. Forwarding of 441 packets to the Device over the LPWAN should only be done from 442 authenticated/trusted sources anyway. Rate-limitation on top of 443 authentication will mitigate this nuisance. 445 6. Security considerations 447 TODO 449 7. IANA Considerations 451 TODO 453 8. References 455 8.1. Normative References 457 [I-D.ietf-lpwan-ipv6-static-context-hc] 458 Minaburo, A., Toutain, L., and C. Gomez, "LPWAN Static 459 Context Header Compression (SCHC) and fragmentation for 460 IPv6 and UDP", draft-ietf-lpwan-ipv6-static-context-hc-07 461 (work in progress), October 2017. 463 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 464 Requirement Levels", BCP 14, RFC 2119, 465 DOI 10.17487/RFC2119, March 1997, . 468 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 469 Control Message Protocol (ICMPv6) for the Internet 470 Protocol Version 6 (IPv6) Specification", STD 89, 471 RFC 4443, DOI 10.17487/RFC4443, March 2006, 472 . 474 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 475 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 476 DOI 10.17487/RFC4861, September 2007, . 479 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 480 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 481 DOI 10.17487/RFC4884, April 2007, . 484 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 485 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 486 May 2017, . 488 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 489 (IPv6) Specification", STD 86, RFC 8200, 490 DOI 10.17487/RFC8200, July 2017, . 493 8.2. Informative References 495 [I-D.ietf-lpwan-overview] 496 Farrell, S., "LPWAN Overview", draft-ietf-lpwan- 497 overview-07 (work in progress), October 2017. 499 Authors' Addresses 501 Dominique Barthel 502 Orange SA 503 28 chemin du Vieux Chene 504 BP 98 505 38243 Meylan Cedex 506 France 508 Email: dominique.barthel@orange.com 510 Laurent Toutain 511 Institut MINES TELECOM; IMT Atlantique 512 2 rue de la Chataigneraie 513 CS 17607 514 35576 Cesson-Sevigne Cedex 515 France 517 Email: laurent.toutain@imt-atlantique.fr 519 Arunprabhu Kandasamy 520 Acklio 521 2bis rue de la Chataigneraie 522 35510 Cesson-Sevigne Cedex 523 France 525 Email: arun@ackl.io