idnits 2.17.1 draft-toutain-lpwan-ipv6-static-context-hc-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 23, 2016) is 2771 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0x4D' is mentioned on line 255, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Minaburo 3 Internet-Draft Acklio 4 Intended status: Informational L. Toutain 5 Expires: March 27, 2017 Institut MINES TELECOM ; TELECOM Bretagne 6 September 23, 2016 8 LPWAN Static Context Header Compression (SCHC) for IPv6 and UDP 9 draft-toutain-lpwan-ipv6-static-context-hc-00 11 Abstract 13 This document describes a header compression scheme for IPv6, IPv6/ 14 UDP based on static contexts. This technique is especially tailored 15 for LPWA networks and could be extended to other protocol stacks. 17 During the IETF history several compression mechanisms have been 18 proposed. First mechanisms, such as RoHC, are using a context to 19 store header field values and send smaller incremental differences on 20 the link. Values in the context evolve dynamically with information 21 contained in the compressed header. The challenge is to maintain 22 sender's and receiver's contexts synchronized even with packet 23 losses. Based on the fact that IPv6 contains only static fields, 24 6LoWPAN developed an efficient context-free compression mechanisms, 25 allowing better flexibility and performance. 27 The Static Context Header Compression (SCHC) combines the advantages 28 of RoHC context which offers a great level of flexibility in the 29 processing of fields, and 6LoWPAN behavior to elide fields that are 30 known from the other side. Static context means that values in the 31 context field do not change during the transmission, avoiding complex 32 resynchronization mechanisms, incompatible with LPWA characteristics. 33 In most of the cases, IPv6/UDP headers are reduced to a small 34 identifier. 36 This document focuses on IPv6/UDP headers compression, but the 37 mechanism can be applied to other protocols such as CoAP. It will be 38 described in a separate document. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on March 27, 2017. 57 Copyright Notice 59 Copyright (c) 2016 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 1. Introduction 74 Headers compression is mandatory to bring the internet protocols to 75 the node within a LPWA network [I-D.minaburo-lp-wan-gap-analysis]. 77 Nevertheless, LPWA networks offer good properties for an efficient 78 header compression: 80 o Topology is star oriented, therefore all the packets follows the 81 same path. For the needs of this draft, the architecture can be 82 summarized to End-Systems (ES) exchanging information with LPWAN 83 Application Server (LA). The exchange goes trhough a single LPWA 84 Compressor (LC). In most of the cases, End Systems and LC form a 85 star topology. ESs and LC maintain a static context for 86 compression. Static context means that context information is not 87 learned during the exchange. 89 o Traffic flows are mostly deterministic, since End-Systems embed 90 built-in applications. Contrary to computers or smartphones, new 91 applications cannot be easily installed. 93 First mechanisms such as RoHC use a context to store header field 94 values and send smaller incremental differences on the link. The 95 first version of RoHC targeted IP/UDP/RTP stack. RoHCv2 extends the 96 principle to any protocol and introduces a formal notation [RFC4997] 97 describing the header and associating compression functions to each 98 field. To be efficient the sender and the receiver must check that 99 the context remains synchronized (i.e. contains the same values). 100 Context synchronization imposes to periodically send a full header or 101 at least dynamic fields. If fully compressed, the header can be 102 compatible with LPWA constraints. However, the first exchanges or 103 context resynchronisations impose to send uncompressed headers, which 104 may be bigger than the original one. This will force the use of 105 inefficient fragmentation mechanisms. For some LPWA technologies, 106 duty cycle limits can also delay the resynchronization. Figure 1 107 illustrates this behavior. 109 sync 110 ^ +-+ sync sync ^ 111 | IPv6 | | +-+ +-+ | IPv6 112 v | | | | | | v 113 +------------+ | +-+-+ | | | | +------------+ 114 | +--+ | | | | | | | | | | +--+ | 115 | | c| | | | | +-+-+-+ +-+-+-+-+ | | | c| | 116 | | t| | | | | | | | | | | | | | | | | t| | 117 | | x| | +-+-+-+-+-+-+-+-+-+-+-+-+ | | x| | 118 | | t| | <----------------------------> | | t| | 119 | +--+ | header size of sent packets | +--+ | 120 +------------+ +------------+ 122 Figure 1: RoHC Compressed Header size evolution. 124 On the other hand, 6LoWPAN [RFC4944] is context-free based on the 125 fact that IPv6, its extensions or UDP headers do not contain 126 incremental fields. The compression mechanism described in [RFC6282] 127 is based on sending a 2-byte bitmap, which describes how the header 128 should be decompressed, either using some standard values or sending 129 information after this bitmap. [RFC6282] also allows for UDP 130 compression. 132 In the best case, when Hop limit is a standard value, flow label, 133 DiffServ fields are set to 0 and Link Local addresses are used over a 134 single hop network, the 6LoWPAN compressed header is reduced to 4 135 bytes. This compression ratio is possible because the IID are 136 derived from the MAC addresses and the link local prefix is known 137 from both sides. In that case, the IPv6 compression is 4 bytes and 138 UDP compression is 2 bytes, which fills half of the payload of a 139 SIGFOX frame, or more than 10% of a LoRaWAN payload (with spreading 140 factor 12). 142 The Static Context Header Compression (SCHC) combines the advantages 143 of RoHC context, which offers a great level of flexibility in the 144 processing of fields, and 6LoWPAN behavior to elide fields that are 145 known from the other side. Static context means that values in the 146 context field do not change during the transmission, avoiding complex 147 resynchronization mechanisms, incompatible with LPWA characteristics. 148 In most of the cases, IPv6/UDP headers are reduced to a small context 149 identifier. 151 2. Static Context Header Compression 153 Static Context Header Compression (SCHC) avoids context 154 synchronization, which is the most bandwidth-consuming operation in 155 RoHC. Based on the fact that the nature of data flows is highly 156 predictable in LPWA networks, a static context may be stored on the 157 End-System (ES). The other end, the LPWA Compressor (LC) can learn 158 the context through a provisioning protocol during the identification 159 phase (for instance, as it learns the encryption key). 161 The context contains a list of rules (cf. Figure 2). Each rule 162 contains itself a list of field descriptions composed of a target 163 value (TV), a matching operator (MO) and a Compression/Decompression 164 Function (CDF). 166 +------------------------------------------------------------------+ 167 | Rule N | 168 +-----------------------------------------------------------------+ | 169 | Rule i | | 170 +----------------------------------------------------------------+ | | 171 | Rule 1 | | | 172 | +--------------+-------------------+-----------------+ | | | 173 | Field 1 | Target Value | Matching Operator | Comp/Decomp Fct | | | | 174 | +--------------+-------------------+-----------------+ | | | 175 | Field 2 | Target Value | Matching Operator | Comp/Decomp Fct | | | | 176 | +--------------+-------------------+-----------------+ | | | 177 | ... | ... | ... | ... | | | | 178 | +--------------+-------------------+-----------------+ | |-+ 179 | Field N | Target Value | Matching Operator | Comp/Decomp Fct | | | 180 | +--------------+-------------------+-----------------+ |-+ 181 | | 182 +----------------------------------------------------------------+ 184 Figure 2: Compression Decompression Context 186 The rule does not describe the compressed/decompressed packet format 187 which must be known from the compressor/decompressor. The rule just 188 describes the compression/decompression behavior for a field. 190 The main idea of the compression scheme is to send the rule number 191 (or rule id) to the other end instead of known field values. 193 Matching a field with a value and header compression are related 194 operations; If a field matches a rule containing the value, it is not 195 necessary to send it on the link. Since contexts are synchronized, 196 reading the rule's value is enough to reconstruct the field's value 197 at the other end. 199 On some other cases, the value need to be sent on the link to inform 200 the other end. The field value may vary from one packet to another, 201 therefore the field cannot be used to select the rule id. 203 2.1. Simple Example 205 A simple header is composed of 3 fields (F1, F2, F3). The compressor 206 receives a packet containing respectively [F1:0x00, F2:0x1230, 207 F3:0xABC0] in those fields. The Matching Operators (as defined in 208 Section 3) allow to select Rule 5 as represented in Figure 3; F1 209 value is ignored and F2 and F3 packet field values are matched with 210 those stored in the rule Target Values. 212 Rule 5 213 Target Value Matching Operator Comp/Decomp Fct 214 +--------------+-------------------+-----------------+ 215 F1 | 0x00 | Ignore | not-sent | 216 +--------------+-------------------+-----------------+ 217 F2 | 0x1230 | Equal | not-sent | 218 +--------------+-------------------+-----------------+ 219 F3 | 0xABC0 | Equal | not-sent | 220 +--------------+-------------------+-----------------+ 222 Figure 3: Matching Rule 224 The Compression/Decompression Function (as defined in Section 4 225 describes how the fields are compressed. In this example, all the 226 fields are elided and only the rule number has to be sent to the 227 other end. 229 The decompressor receives the rule number and reconstructs the header 230 using the values stored in the Target Value column. 232 Note that F1 value will be set to 0x00 by the decompressor, even if 233 the original header field was carrying a different value. 235 To allow a range of values for field F2 and F3, the MSB() Matching 236 Operator and LSB() Compression/Decompression Function can be used (as 237 defined in Section 3 and Section 4). In that case the rule will be 238 rewritten as defined in Figure 4. 240 Rule 5 241 Target Value Matching Operator Comp/Decomp Fct 242 +--------------+-------------------+-----------------+ 243 F1 | 0x00 | Ignore | not-sent | 244 +--------------+-------------------+-----------------+ 245 F2 | 0x1230 | MSB(12) | LSB(4) | 246 +--------------+-------------------+-----------------+ 247 F3 | 0xABC0 | MSB(12) | LSB(4) | 248 +--------------+-------------------+-----------------+ 250 Figure 4: Matching Rule 252 In that case, if a packet with the following header fields [F1:0x00, 253 F2:0x1234, F3:0xABCD] arrives to the compressor, the new rule 5 will 254 be selected and sent to the other end. The compressed header will be 255 composed of the single byte [0x4D]. The decompressor receives the 256 compressed header and follows the rule to reconstruct [0x00, 0x1234, 257 0xABCD] applying a OR operator between the target value stored in the 258 rule and the compressed field value sent. 260 2.2. Packet processing 262 The compression/decompression process follows several steps: 264 o compression rule selection: the goal is to identify which rule 265 will be used to compress the headers. To each field is associated 266 a matching rule for compression. Each header field's value is 267 compared to the corresponding target value stored in the rule for 268 that field using the matching operator. If all the fields 269 satisfied the matching operator, the packet is processed using 270 this Compression Decompression Function functions. Otherwise the 271 next rule is tested. If no eligible rule is found, then the 272 packet is dropped. 274 o sending: The rule number is sent to the other end followed by data 275 resulting from the field compression. The way the rule number is 276 sent depends of the layer two technology and will be specified in 277 a specific document. For exemple, it can either be included in a 278 Layer 2 header or sent in the first byte of the L2 payload. 280 o decompression: The receiver identifies the sender through its 281 device-id (e.g. MAC address) and select the appropriate rule 282 through the rule number. It applies the compression decompression 283 function to reconstruct the original header fields. 285 3. Matching operators 287 It may exist some intermediary cases, where part of the value may be 288 used to select a field and a variable part has to be sent on the 289 link. This is true for Least Significant Bits (LSB) where the most 290 significant bit can be used to select a rule id and the least 291 significant bits have to be sent on the link. 293 Several matching operators are defined: 295 o equal: a field value in a packet matches with a field value in a 296 rule if they are equal. 298 o ignore: no check is done between a field value in a packet and a 299 field value in the rule. The result is always true. 301 o MSB(length): a field value of length T in a packet matches with a 302 field value in a rule if the most significant "length" bits are 303 equal. 305 4. Compression Decompression Functions (CDF) 307 The Compression Decompression Functions (CDF) describe the action 308 taken during the compression and inversely the action taken by the 309 decompressor to restore the original value. 311 /--------------------+-------------+--------------------------\ 312 | Function | Compression | Decompression | 313 | | | | 314 +--------------------+-------------+--------------------------+ 315 |not-sent |elided |use value stored in ctxt | 316 |value-sent |send |build from received value | 317 |LSB(length) |send LSB |ctxt value OR rcvd value | 318 |compute-IPv6-length |elided |compute IPv6 length | 319 |compute-UDP-length |elided |compute UDP length | 320 |compute-UDP-checksum|elided |compute UDP checksum | 321 |ESiid-DID |elided |build IID from L2 ES addr | 322 |LAiid-DID |elided |build IID from L2 LA addr | 323 \--------------------+-------------+--------------------------/ 325 Figure 5: Compression and Decompression Functions 327 Figure 5 lists all the functions defined to compress and decompress a 328 field. The first column gives the function's name. The second and 329 third columns outlines the compression/decompression process. 331 As with 6LoWPAN, the compression process may produce some data, where 332 fields that were not compressed (or were partially compressed) will 333 be sent in the order of the original packet. Information added by 334 the compression phase must be aligned on byte boundaries, but each 335 individual compression function may generate any size. 337 /--------------+-------------------+-----------------------------------\ 338 | Field |Comp Decomp Fct | Behavior | 339 +--------------+-------------------+-----------------------------------+ 340 |IPv6 version |not-sent |The value is not sent, but each | 341 |IPv6 DiffServ | |end agrees on a value, which can | 342 |IPv6 FL | |be different from 0. | 343 |IPv6 NH |value-sent |Depending on the matching operator,| 344 | | |the entire field value is sent or | 345 | | |an adjustment to the context value | 346 +--------------+-------------------+-----------------------------------+ 347 |IPv6 Length |compute-IPv6-length|Dedicated fct to reconstruct value | 348 +--------------+-------------------+-----------------------------------+ 349 |IPv6 Hop Limit|not-sent+MO=ignore |The receiver takes the value stored| 350 | | |in the context. It may be different| 351 | | |from one originally sent, but in a | 352 | | |star topology, there is no risk of | 353 | | |loops | 354 | |not-sent+matching |Receiver and sender agree on a | 355 | | |specific value. | 356 | |value-sent |Explicitly sent | 357 +--------------+-------------------+-----------------------------------+ 358 |IPv6 ESPrefix |not-sent |The 64 bit prefix is stored on | 359 |IPv6 LAPrefix | |the context | 360 | |value-sent |Explicitly send 64 bits on the link| 361 +--------------+-------------------+-----------------------------------+ 362 |IPv6 ESiid |not-sent |IID is not sent, but stored in the | 363 |IPv6 LAiid | |context | 364 | |ESiid-DID|LAiid-DID|IID is built from the ES/LA Dev. ID| 365 | |value-sent |IID is explicitly sent on the link.| 366 | | |Size depends of the L2 technology | 367 +--------------+-------------------+-----------------------------------+ 368 |UDP ESport |not-sent |In the context | 369 |UDP LAport |value-sent |Send the 2 bytes of the port number| 370 | |LSB(length) |or least significant bits if MSB | 371 | | |matching is specified in the | 372 | | |matching operator. | 373 +--------------+-------------------+-----------------------------------+ 374 |UDP length |compute-UDP-length |Dedicated fct to reconstruct value | 375 +--------------+-------------------+-----------------------------------+ 376 |UDP Checksum |compute-UDP-checksum|Dedicated fct to reconstruct value| 377 +--------------+-------------------+-----------------------------------+ 379 Figure 6: SCHC functions' example assignment for IPv6 and UDP 381 Figure 6 gives an example of function assignment to IPv6/UDP fields. 383 4.1. Compression Decompression Functions (CDF) 385 4.1.1. not-sent 387 The compressor do not sent the field value on the link. The 388 decompressor restore the field value with the one stored in the 389 matched rule. 391 4.1.2. value-sent 393 The compressor send the field value on the link, if the matching 394 operator is "=". Otherwise the matching operator indicates the 395 information that will be sent on the link. For a LSB operator only 396 the Least Significant Bits are sent. 398 4.1.3. LSB(length) 400 The compressor sends the "length" Least Significant Bits. The 401 decompressor combines with a OR operator the value received with the 402 Target Value. 404 4.1.4. ESiid-DID, LAiid-DID 406 These functions are used to process respectively the End System and 407 the LA Device Identifier (DID). The IID value is computed from 408 device ID present in the Layer 2 header. The computation depends on 409 the technology and the device ID size. 411 4.1.5. Compute-* 413 These functions compute the field value based on received 414 information. They are elided during the compression and 415 reconstructed during the decompression. 417 o compute-ipv6-length: compute the IPv6 length field as described in 418 [RFC2460]. 420 o compute-udp-length: compute the IPv6 length field as described in 421 [RFC0768]. 423 o compute-udp-checksum: compute the IPv6 length field as described 424 in [RFC0768]. 426 5. Examples 428 This section gives some scenarios of the compression mechanism for 429 IPv6/UDP. The goal is to illustrate the SCHC behavior. 431 5.1. IPv6/UDP compression in a star topology 433 The most common case will be a LPWA end-system embeds some 434 applications running over CoAP. In this example, the first flow is 435 for the device management based on CoAP using Link Local addresses 436 and UDP ports 123 and 124. The second flow will be a CoAP server for 437 measurements done by the end-system (using ports 5683) and Global 438 Addresses alpha::IID/64 to beta::1/64. The last flow is for legacy 439 applications using different ports numbers, the destination is 440 gamma::1/64. 442 Figure 7 presents the protocol stack for this end-system. IPv6 and 443 UDP are represented with dotted lines since these protocols are 444 compressed on the radio link. 446 Managment Data 447 +----------+---------+---------+ 448 | CoAP | CoAP | legacy | 449 +----||----+---||----+---||----+ 450 . UDP . UDP | UDP | 451 ................................ 452 . IPv6 . IPv6 . IPv6 . 453 +------------------------------+ 454 | 6LPWA L2 technologies | 455 +------------------------------+ 456 End System or LPWA GW 458 Figure 7: Simplified Protocol Stack for LP-WAN 460 Note that in some LPWA technologies, only End Systems have a device 461 ID . Therefore it is necessary to define statically an IID for the 462 Link Local address for the LPWA Compressor. 464 Rule 0 465 +----------------+---------+--------+-------------++------+ 466 | Field | Value | Match | Function || Sent | 467 +----------------+---------+----------------------++------+ 468 |IPv6 version |6 | equal | not-sent || | 469 |IPv6 DiffServ |0 | equal | not-sent || | 470 |IPv6 Flow Label |0 | equal | not-sent || | 471 |IPv6 Length | | ignore | comp-IPv6-l || | 472 |IPv6 Next Header|17 | equal | not-sent || | 473 |IPv6 Hop Limit |255 | ignore | not-sent || | 474 |IPv6 ESprefix |FE80::/64| equal | not-sent || | 475 |IPv6 ESiid | | ignore | ESiid-DID || | 476 |IPv6 LCprefix |FE80::/64| equal | not-sent || | 477 |IPv6 LAiid |::1 | equal | not-sent || | 478 +================+=========+========+=============++======+ 479 |UDP ESport |123 | equal | not-sent || | 480 |UDP LAport |124 | equal | not-sent || | 481 |UDP Length | | ignore | comp-UDP-l || | 482 |UDP checksum | | ignore | comp-UDP-c || | 483 +================+=========+========+=============++======+ 485 Rule 1 486 +----------------+---------+--------+-------------++------+ 487 | Field | Value | Match | Function || Sent | 488 +----------------+---------+--------+-------------++------+ 489 |IPv6 version |6 | equal | not-sent || | 490 |IPv6 DiffServ |0 | equal | not-sent || | 491 |IPv6 Flow Label |0 | equal | not-sent || | 492 |IPv6 Length | | ignore | comp-IPv6-l || | 493 |IPv6 Next Header|17 | equal | not-sent || | 494 |IPv6 Hop Limit |255 | ignore | not-sent || | 495 |IPv6 ESprefix |alpha/64 | equal | not-sent || | 496 |IPv6 ESiid | | ignore | ESiid-DID || | 497 |IPv6 LAprefix |beta/64 | equal | not-sent || | 498 |IPv6 LAiid |::1000 | equal | not-sent || | 499 +================+=========+========+=============++======+ 500 |UDP ESport |5683 | equal | not-sent || | 501 |UDP LAport |5683 | equal | not-sent || | 502 |UDP Length | | ignore | comp-UDP-l || | 503 |UDP checksum | | ignore | comp-UDP-c || | 504 +================+=========+========+=============++======+ 506 Rule 2 507 +----------------+---------+--------+-------------++------+ 508 | Field | Value | Match | Function || Sent | 509 +----------------+---------+--------+-------------++------+ 510 |IPv6 version |6 | equal | not-sent || | 511 |IPv6 DiffServ |0 | equal | not-sent || | 512 |IPv6 Flow Label |0 | equal | not-sent || | 513 |IPv6 Length | | ignore | comp-IPv6-l || | 514 |IPv6 Next Header|17 | equal | not-sent || | 515 |IPv6 Hop Limit |255 | ignore | not-sent || | 516 |IPv6 ESprefix |alpha/64 | equal | not-sent || | 517 |IPv6 ESiid | | ignore | ESiid-DID || | 518 |IPv6 LAprefix |gamma/64 | equal | not-sent || | 519 |IPv6 LAiid |::1000 | equal | not-sent || | 520 +================+=========+========+=============++======+ 521 |UDP ESport |8720 | MSB(12)| LSB(4) || lsb | 522 |UDP LAport |8720 | MSB(12)| LSB(4) || lsb | 523 |UDP Length | | ignore | comp-UDP-l || | 524 |UDP checksum | | ignore | comp-UDP-c || | 525 +================+=========+========+=============++======+ 527 Figure 8: Context rules 529 All the fields described in the three rules Figure 8 are present in 530 the IPv6 and UDP headers. The ESDevice-ID value is found in the L2 531 header. 533 The second and third rules use global addresses. The way the ES 534 learn the prefix is not in the scope of the document. One possible 535 way is to use a management protocol to set up in both end rules the 536 prefix used on the LPWA network. 538 The third rule compresses port numbers on 4 bits. This value is 539 selected to maintain alignment on byte boundaries for the compressed 540 header. 542 6. Acknowledgements 544 Thanks to Dominique Barthel, Arunprabhu Kandasamy, Antony Markovski, 545 Alexander Pelov, Juan Carlos Zuniga for useful design consideration. 547 7. Normative References 549 [I-D.minaburo-lp-wan-gap-analysis] 550 Minaburo, A., Pelov, A., and L. Toutain, "LP-WAN GAP 551 Analysis", draft-minaburo-lp-wan-gap-analysis-01 (work in 552 progress), February 2016. 554 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 555 DOI 10.17487/RFC0768, August 1980, 556 . 558 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 559 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 560 December 1998, . 562 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 563 "Transmission of IPv6 Packets over IEEE 802.15.4 564 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 565 . 567 [RFC4997] Finking, R. and G. Pelletier, "Formal Notation for RObust 568 Header Compression (ROHC-FN)", RFC 4997, 569 DOI 10.17487/RFC4997, July 2007, 570 . 572 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 573 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 574 DOI 10.17487/RFC6282, September 2011, 575 . 577 Authors' Addresses 579 Ana Minaburo 580 Acklio 581 2bis rue de la Chataigneraie 582 35510 Cesson-Sevigne Cedex 583 France 585 Email: ana@ackl.io 587 Laurent Toutain 588 Institut MINES TELECOM ; TELECOM Bretagne 589 2 rue de la Chataigneraie 590 CS 17607 591 35576 Cesson-Sevigne Cedex 592 France 594 Email: Laurent.Toutain@telecom-bretagne.eu