idnits 2.17.00 (12 Aug 2021) /tmp/idnits14335/draft-ietf-6lo-ghc-02.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 (July 21, 2014) is 2861 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCthis' is mentioned on line 410, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track July 21, 2014 5 Expires: January 22, 2015 7 6LoWPAN Generic Compression of Headers and Header-like Payloads 8 draft-ietf-6lo-ghc-02 10 Abstract 12 This short specification provides a simple addition to 6LoWPAN Header 13 Compression that enables the compression of generic headers and 14 header-like payloads, without a need to define a new header 15 compression scheme for each new such header or header-like payload. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 22, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. The Header Compression Coupling Problem . . . . . . . . . 2 53 1.2. Compression Approach . . . . . . . . . . . . . . . . . . 3 54 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.4. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2. 6LoWPAN-GHC . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Integrating 6LoWPAN-GHC into 6LoWPAN-HC . . . . . . . . . . . 6 58 3.1. Compressing payloads (UDP and ICMPv6) . . . . . . . . . . 6 59 3.2. Compressing extension headers . . . . . . . . . . . . . . 6 60 3.3. Indicating GHC capability . . . . . . . . . . . . . . . . 7 61 3.4. Using the 6CIO Option . . . . . . . . . . . . . . . . . . 8 62 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 9 63 5. Security considerations . . . . . . . . . . . . . . . . . . . 10 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 67 7.2. Informative References . . . . . . . . . . . . . . . . . 12 68 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 71 1. Introduction 73 1.1. The Header Compression Coupling Problem 75 6LoWPAN-HC [RFC6282] defines a scheme for header compression in 76 6LoWPAN [RFC4944] packets. As with most header compression schemes, 77 a new specification is needed for every new kind of header that needs 78 to be compressed. In addition, [RFC6282] does not define an 79 extensibility scheme like the ROHC profiles defined in ROHC [RFC3095] 80 [RFC5795]. This leads to the difficult situation that 6LoWPAN-HC 81 tended to be reopened and reexamined each time a new header receives 82 consideration (or an old header is changed and reconsidered) in the 83 6LoWPAN/roll/CoRE cluster of IETF working groups. While [RFC6282] 84 finally got completed, the underlying problem remains unsolved. 86 The purpose of the present contribution is to plug into [RFC6282] as 87 is, using its NHC (next header compression) concept. We add a 88 slightly less efficient, but vastly more general form of compression 89 for headers of any kind and even for header-like payloads such as 90 those exhibited by routing protocols, DHCP, etc. The objective is an 91 extremely simple specification that can be defined on a single page 92 and implemented in a small number of lines of code, as opposed to a 93 general data compression scheme such as that defined in [RFC1951]. 95 1.2. Compression Approach 97 The basic approach of GHC's compression function is to define a 98 bytecode for LZ77-style compression [LZ77]. The bytecode is a series 99 of simple instructions for the decompressor to reconstitute the 100 uncompressed payload. These instructions include: 102 o appending bytes to the reconstituted payload that are literally 103 given with the instruction in the compressed data 105 o appending a given number of zero bytes to the reconstituted 106 payload 108 o appending bytes to the reconstituted payload by copying a 109 contiguous sequence from the payload being reconstituted 110 ("backreferencing") 112 o an ancillary instruction for setting up parameters for the 113 backreferencing instruction in "decompression variables" 115 o a stop code (optional, see Section 3.2) 117 The buffer for the reconstituted payload ("destination buffer") is 118 prefixed by a predefined dictionary that can be used in the 119 backreferencing as if it were a prefix of the payload. This 120 predefined dictionary is built from the IPv6 addresses of the packet 121 being reconstituted, followed by a static component, the "static 122 dictionary". 124 As usual, this specification defines the decompressor operation in 125 detail, but leaves the detailed operation of the compressor open to 126 implementation. The compressor can be implemented as with a 127 classical LZ77 compressor, or it can be a simple protocol encoder 128 that just makes use of known compression opportunities. 130 1.3. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in RFC 135 2119 [RFC2119]. 137 The term "byte" is used in its now customary sense as a synonym for 138 "octet". 140 1.4. Notation 142 This specification uses a trivial notation for code bytes and the 143 bitfields in them the meaning of which should be mostly obvious. 144 More formally speaking, the meaning of the notation is: 146 Potential values for the code bytes themselves are expressed by 147 templates that represent 8-bit most-significant-bit-first binary 148 numbers (without any special prefix), where 0 stands for 0, 1 for 1, 149 and variable segments in these code byte templates are indicated by 150 sequences of the same letter such as kkkkkkk or ssss, the length of 151 which indicates the length of the variable segment in bits. 153 In the notation of values derived from the code bytes, 0b is used as 154 a prefix for expressing binary numbers in most-significant-bit first 155 notation (akin to the use of 0x for most-significant-digit-first 156 hexadecimal numbers in the C programming language). Where the above- 157 mentioned sequences of letters are then referenced in such a binary 158 number in the text, the intention is that the value from these 159 bitfields in the actual code byte be inserted. 161 Example: The code byte template 163 101nssss 165 stands for a byte that starts (most-significant-bit-first) with the 166 bits 1, 0, and 1, and continues with five variable bits, the first of 167 which is referenced as "n" and the next four are referenced as 168 "ssss". Based on this code byte template, a reference to 170 0b0ssss000 172 means a binary number composed from a zero bit, the four bits that 173 are in the "ssss" field (for 101nssss, the four least significant 174 bits) in the actual byte encountered, kept in the same order, and 175 three more zero bits. 177 2. 6LoWPAN-GHC 179 The format of a GHC-compressed header or payload is a simple 180 bytecode. A compressed header consists of a sequence of pieces, each 181 of which begins with a code byte, which may be followed by zero or 182 more bytes as its argument. Some code bytes cause bytes to be laid 183 out in the destination buffer, some simply modify some decompression 184 variables. 186 At the start of decompressing a header or payload within a L2 packet 187 (= fragment), the decompression variables "sa" and "na" are 188 initialized as zero. 190 The code bytes are defined as follows (Table 1): 192 +----------+---------------------------------------------+----------+ 193 | code | Action | Argument | 194 | byte | | | 195 +----------+---------------------------------------------+----------+ 196 | 0kkkkkkk | Append k = 0b0kkkkkkk bytes of data in the | k bytes | 197 | | bytecode argument (k < 96) | of data | 198 | | | | 199 | 1000nnnn | Append 0b0000nnnn+2 bytes of zeroes | | 200 | | | | 201 | 10010000 | STOP code (end of compressed data, see | | 202 | | Section 3.2) | | 203 | | | | 204 | 101nssss | Set up extended arguments for a | | 205 | | backreference: sa += 0b0ssss000, na += | | 206 | | 0b0000n000 | | 207 | | | | 208 | 11nnnkkk | Backreference: n = na+0b00000nnn+2; s = | | 209 | | 0b00000kkk+sa+n; append n bytes from | | 210 | | previously output bytes, starting s bytes | | 211 | | to the left of the current output pointer; | | 212 | | set sa = 0, na = 0 | | 213 +----------+---------------------------------------------+----------+ 215 Table 1: Bytecodes for generic header compression 217 Note that the following bit combinations are reserved at this time: 218 011xxxxx, and 1001nnnn (where 0b0000nnnn > 0). 220 For the purposes of the backreferences, the expansion buffer is 221 initialized with a predefined dictionary, at the end of which the 222 reconstituted payload begins. This dictionary is composed of the 223 source and destination IPv6 addresses of the packet being 224 reconstituted, followed by a 16-byte static dictionary (Figure 1). 226 These 48 dictionary bytes are therefore available for 227 backreferencing, but not copied into the final reconstituted payload. 229 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 231 Figure 1: The 16 bytes of static dictionary (in hex) 233 3. Integrating 6LoWPAN-GHC into 6LoWPAN-HC 235 6LoWPAN-GHC plugs in as an NHC format for 6LoWPAN-HC [RFC6282]. 237 3.1. Compressing payloads (UDP and ICMPv6) 239 GHC is by definition generic and can be applied to different kinds of 240 packets. Many of the examples given in Appendix A are for ICMPv6 241 packets; a single NHC value suffices to define an NHC format for 242 ICMPv6 based on GHC (see below). 244 In addition it is useful to include an NHC format for UDP, as many 245 headerlike payloads (e.g., DHCPv6, DTLS) are carried in UDP. 246 [RFC6282] already defines an NHC format for UDP (11110CPP). GHC uses 247 an analogous NHC byte formatted as shown in Figure 2. The difference 248 to the existing UDP NHC specification is that for 0b11010cpp NHC 249 bytes, the UDP payload is not supplied literally but compressed by 250 6LoWPAN-GHC. 252 0 1 2 3 4 5 6 7 253 +---+---+---+---+---+---+---+---+ 254 | 1 | 1 | 0 | 1 | 0 | C | P | 255 +---+---+---+---+---+---+---+---+ 257 Figure 2: NHC byte for UDP GHC (to be allocated by IANA) 259 To stay in the same general numbering space, we use 0b11011111 as the 260 NHC byte for ICMPv6 GHC (Figure 3). 262 0 1 2 3 4 5 6 7 263 +---+---+---+---+---+---+---+---+ 264 | 1 | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 265 +---+---+---+---+---+---+---+---+ 267 Figure 3: NHC byte for ICMPv6 GHC (to be allocated by IANA) 269 3.2. Compressing extension headers 271 Compression of specific extension headers is added in a similar way 272 (Figure 4) (however, probably only EID 0 to 3 need to be assigned). 273 As there is no easy way to extract the length field from the GHC- 274 encoded header before decoding, this would make detecting the end of 275 the extension header somewhat complex. The easiest (and most 276 efficient) approach is to completely elide the length field (in the 277 same way NHC already elides the next header field in certain cases) 278 and reconstruct it only on decompression. To serve as a terminator 279 for the extension header, the reserved bytecode 0b10010000 has been 280 assigned as a stop marker. Note that the stop marker is only needed 281 for extension headers, not for the final payloads discussed in the 282 previous subsection, the decompression of which is automatically 283 stopped by the end of the packet. 285 0 1 2 3 4 5 6 7 286 +---+---+---+---+---+---+---+---+ 287 | 1 | 0 | 1 | 1 | EID |NH | 288 +---+---+---+---+---+---+---+---+ 290 Figure 4: NHC byte for extension header GHC 292 3.3. Indicating GHC capability 294 The 6LoWPAN baseline includes just [RFC4944], [RFC6282], [RFC6775] 295 (see [I-D.bormann-6lo-6lowpan-roadmap]). To enable the use of GHC 296 towards a neighbor, a 6LoWPAN node needs to know that the neighbor 297 implements it. While this can also simply be administratively 298 required, a transition strategy as well as a way to support mixed 299 networks is required. 301 One way to know a neighbor does implement GHC is receiving a packet 302 from that neighbor with GHC in it ("implicit capability detection"). 303 However, there needs to be a way to bootstrap this, as nobody ever 304 would start sending packets with GHC otherwise. 306 To minimize the impact on [RFC6775], we define an ND option 6LoWPAN 307 Capability Indication (6CIO), as illustrated in Figure 5. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | Type | Length = 1 |_____________________________|G| 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 |_______________________________________________________________| 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 5: 6LoWPAN Capability Indication Option (6CIO) 319 The G bit indicates whether the node sending the option is GHC 320 capable. 322 Once a node receives either an explicit or an implicit indication of 323 GHC capability from another node, it may send GHC-compressed packets 324 to that node. Where that capability has not been recently confirmed, 325 similar to the way PLPMTUD [RFC4821] finds out about changes in the 326 network, a node SHOULD make use of NUD (neighbor unreachability 327 detection) failures to switch back to basic 6LoWPAN header 328 compression [RFC6282]. 330 3.4. Using the 6CIO Option 332 The 6CIO option will typically only be ever sent in 6LoWPAN-ND RS 333 packets (which cannot itself be GHC compressed unless the host 334 desires to limit itself to talking to GHC capable routers). The 335 resulting 6LoWPAN-ND RA can then already make use of GHC and thus 336 indicate GHC capability implicitly, which in turn allows both nodes 337 to use GHC in the 6LoWPAN-ND NS/NA exchange. 339 6CIO can also be used for future options that need to be negotiated 340 between 6LoWPAN peers; an IANA registry is used to assign the flags. 341 Bits marked by underscores in Figure 5 are unassigned and available 342 for future assignment. They MUST be sent as zero and MUST be ignored 343 on reception until assigned by IANA. Length values larger than 1 344 MUST be accepted by implementations in order to enable future 345 extensions; the additional bits in the option are then deemed 346 unassigned in the same way. For the purposes of the IANA registry, 347 the bits are numbered in most-significant-bit-first order from the 348 16th bit of the option onward, i.e., the G bit is flag number 15. 349 (Additional bits may also be used by a follow-on version of this 350 document if some bit combinations that have been left unassigned here 351 are then used in an upward compatible manner.) 353 Flag numbers 0 to 7 are reserved for experiments. They MUST NOT be 354 used for actual deployments. 356 Where the use of this option by other specifications or by 357 experiments is envisioned, the following items have to be kept in 358 mind: 360 o The option can be used in any ND packet. 362 o Specific bits are set in the option to indicate that a capability 363 is present in the sender. (There may be other ways to infer this 364 information, as is the case in this specification.) Bit 365 combinations may be used as desired. The absence of the 366 capability _indication_ is signaled by setting these bits to zero; 367 this does not necessarily mean that the capability is absent. 369 o The intention is not to modify the semantics of the specific ND 370 packet carrying the option, but to provide the general capability 371 indication described above. 373 o Specifications have to be designed such that receivers that do not 374 receive or do not process such a capability indication can still 375 interoperate (presumably without exploiting the indicated 376 capability). 378 o The option is meant to be used sparsely, i.e. once a sender has 379 reason to believe the capability indication has been received, 380 there no longer is a need to continue sending it. 382 4. IANA considerations 384 [This section to be removed/replaced by the RFC Editor.] 386 In the IANA registry for the "LOWPAN_NHC Header Type" (in the "IPv6 387 Low Power Personal Area Network Parameters"), IANA is requested to 388 add the assignments in Figure 6. 390 10110IIN: Extension header GHC [RFCthis] 391 11010CPP: UDP GHC [RFCthis] 392 11011111: ICMPv6 GHC [RFCthis] 394 Figure 6: IANA assignments for the NHC byte 396 IANA is requested to allocate an ND option number for the 6CIO ND 397 option format in the Registry "IPv6 Neighbor Discovery Option 398 Formats" [RFC4861]. 400 IANA is requested to create a subregistry for "6LoWPAN capability 401 bits" within the "Internet Control Message Protocol version 6 402 (ICMPv6) Parameters". The bits are assigned by giving their numbers 403 as small non-negative integers as defined in section Section 3.4, 404 preferably in the range 0..47. The policy is "IETF Review" or "IESG 405 Approval" [RFC5226]. The initial content of the registry is as in 406 Figure 7: 408 0..7: reserved for experiments [RFCthis] 409 8..14: unassigned 410 15: GHC capable bit (G bit) [RFCthis] 411 16..47: unassigned 413 Figure 7: IANA assignments for the 6LoWPAN capability bits 415 5. Security considerations 417 The security considerations of [RFC4944] and [RFC6282] apply. As 418 usual in protocols with packet parsing/construction, care must be 419 taken in implementations to avoid buffer overflows and in particular 420 (with respect to the back-referencing) out-of-area references during 421 decompression. 423 One additional consideration is that an attacker may send a forged 424 packet that makes a second node believe a third victim node is GHC- 425 capable. If it is not, this may prevent packets sent by the second 426 node from reaching the third node (at least until robustness features 427 such as those discussed in Section 3.3 kick in). 429 No mitigation is proposed (or known) for this attack, except that a 430 victim node that does implement GHC is not vulnerable. However, with 431 unsecured ND, a number of attacks with similar outcomes are already 432 possible, so there is little incentive to make use of this additional 433 attack. With secured ND, 6CIO is also secured; nodes relying on 434 secured ND therefore should use 6CIO bidirectionally (and limit the 435 implicit capability detection to secured ND packets carrying GHC) 436 instead of basing their neighbor capability assumptions on receiving 437 any kind of unprotected packet. 439 6. Acknowledgements 441 Colin O'Flynn has repeatedly insisted that some form of compression 442 for ICMPv6 and ND packets might be beneficial. He actually wrote his 443 own draft, [I-D.oflynn-6lowpan-icmphc], which compresses better, but 444 addresses basic ICMPv6/ND only and needs a much longer spec (around 445 17 pages of detailed spec, as compared to the single page of core 446 spec here). This motivated the author to try something simple, yet 447 general. Special thanks go to Colin for indicating that he indeed 448 considers his draft superseded by the present one. 450 The examples given are based on pcap files that Colin O'Flynn, Owen 451 Kirby, Olaf Bergmann and others provided. 453 The static dictionary was developed, and the bit allocations 454 validated, based on research by Sebastian Dominik. 456 Erik Nordmark provided input that helped shaping the 6CIO option. 457 Thomas Bjorklund proposed simplifying the predefined dictionary. 459 Yoshihiro Ohba insisted on clarifying the notation used for the 460 definition of the bytecodes and their bitfields. Ulrich Herberg 461 provided some additional review and suggested expanding the 462 introductory material, and with Hannes Tschofenig and Brian Haberman 463 he helped come up with the IANA policy for the "6LoWPAN capability 464 bits" assignments in the 6CIO option. 466 7. References 468 7.1. Normative References 470 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", BCP 14, RFC 2119, March 1997. 473 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 474 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 475 September 2007. 477 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 478 "Transmission of IPv6 Packets over IEEE 802.15.4 479 Networks", RFC 4944, September 2007. 481 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 482 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 483 May 2008. 485 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 486 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 487 September 2011. 489 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 490 "Neighbor Discovery Optimization for IPv6 over Low-Power 491 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 492 November 2012. 494 7.2. Informative References 496 [I-D.bormann-6lo-6lowpan-roadmap] 497 Bormann, C., "6LoWPAN Roadmap and Implementation Guide", 498 draft-bormann-6lo-6lowpan-roadmap-00 (work in progress), 499 October 2013. 501 [I-D.oflynn-6lowpan-icmphc] 502 O'Flynn, C., "ICMPv6/ND Compression for 6LoWPAN Networks", 503 draft-oflynn-6lowpan-icmphc-00 (work in progress), July 504 2010. 506 [LZ77] Ziv, J. and A. Lempel, "A Universal Algorithm for 507 Sequential Data Compression", IEEE Transactions on 508 Information Theory, Vol. 23, No. 3, pp. 337-343, May 1977. 510 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 511 version 1.3", RFC 1951, May 1996. 513 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 514 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 515 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 516 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 517 Compression (ROHC): Framework and four profiles: RTP, UDP, 518 ESP, and uncompressed", RFC 3095, July 2001. 520 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 521 Discovery", RFC 4821, March 2007. 523 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 524 Header Compression (ROHC) Framework", RFC 5795, March 525 2010. 527 Appendix A. Examples 529 This section demonstrates some relatively realistic examples derived 530 from actual PCAP dumps taken at previous interops. 532 Figure 8 shows an RPL DODAG Information Solicitation, a quite short 533 RPL message that obviously cannot be improved much. 535 IP header: 536 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 537 02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00 538 00 00 00 00 00 00 00 1a 539 Payload: 540 9b 00 6b de 00 00 00 00 541 Dictionary: 542 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24 543 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 544 00 00 00 08 00 00 00 3a 16 fe fd 17 fe fd 00 01 545 00 00 00 00 00 01 00 00 546 copy: 04 9b 00 6b de 547 4 nulls: 82 548 Compressed: 549 04 9b 00 6b de 82 550 Was 8 bytes; compressed to 6 bytes, compression factor 1.33 552 Figure 8: A simple RPL example 554 Figure 9 shows an RPL DODAG Information Object, a longer RPL control 555 message that is improved a bit more. Note that the compressed output 556 exposes an inefficiency in the simple-minded compressor used to 557 generate it; this does not devalue the example since constrained 558 nodes are quite likely to make use of simple-minded compressors. 560 IP header: 561 60 00 00 00 00 5c 3a ff fe 80 00 00 00 00 00 00 562 02 1c da ff fe 00 30 23 ff 02 00 00 00 00 00 00 563 00 00 00 00 00 00 00 1a 564 Payload: 565 9b 01 7a 5f 00 f0 01 00 88 00 00 00 20 02 0d b8 566 00 00 00 00 00 00 00 ff fe 00 fa ce 04 0e 00 14 567 09 ff 00 00 01 00 00 00 00 00 00 00 08 1e 80 20 568 ff ff ff ff ff ff ff ff 00 00 00 00 20 02 0d b8 569 00 00 00 00 00 00 00 ff fe 00 fa ce 03 0e 40 00 570 ff ff ff ff 20 02 0d b8 00 00 00 00 571 Dictionary: 572 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 573 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 574 00 00 00 5c 00 00 00 3a 16 fe fd 17 fe fd 00 01 575 00 00 00 00 00 01 00 00 576 copy: 06 9b 01 7a 5f 00 f0 577 ref(9): 01 00 -> ref 11nnnkkk 0 7: c7 578 copy: 01 88 579 3 nulls: 81 580 copy: 04 20 02 0d b8 581 7 nulls: 85 582 ref(68): ff fe 00 -> ref 101nssss 0 8/11nnnkkk 1 1: a8 c9 583 copy: 08 fa ce 04 0e 00 14 09 ff 584 ref(39): 00 00 01 00 00 -> ref 101nssss 0 4/11nnnkkk 3 2: a4 da 585 5 nulls: 83 586 copy: 06 08 1e 80 20 ff ff 587 ref(2): ff ff -> ref 11nnnkkk 0 0: c0 588 ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0 589 4 nulls: 82 590 ref(48): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 fa ce 591 -> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0 592 copy: 03 03 0e 40 593 ref(9): 00 ff -> ref 11nnnkkk 0 7: c7 594 ref(28): ff ff ff -> ref 101nssss 0 3/11nnnkkk 1 1: a3 c9 595 ref(24): 20 02 0d b8 00 00 00 00 596 -> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0 597 Compressed: 598 06 9b 01 7a 5f 00 f0 c7 01 88 81 04 20 02 0d b8 599 85 a8 c9 08 fa ce 04 0e 00 14 09 ff a4 da 83 06 600 08 1e 80 20 ff ff c0 d0 82 b4 f0 03 03 0e 40 c7 601 a3 c9 a2 f0 602 Was 92 bytes; compressed to 52 bytes, compression factor 1.77 604 Figure 9: A longer RPL example 606 Similarly, Figure 10 shows an RPL DAO message. One of the embedded 607 addresses is copied right out of the pseudo-header, the other one is 608 effectively converted from global to local by providing the prefix 609 FE80 literally, inserting a number of nulls, and copying (some of) 610 the IID part again out of the pseudo-header. Note that a simple 611 implementation would probably emit fewer nulls and copy the entire 612 IID; there are multiple ways to encode this 50-byte payload into 27 613 bytes. 615 IP header: 616 60 00 00 00 00 32 3a ff 20 02 0d b8 00 00 00 00 617 00 00 00 ff fe 00 33 44 20 02 0d b8 00 00 00 00 618 00 00 00 ff fe 00 11 22 619 Payload: 620 9b 02 58 7d 01 80 00 f1 05 12 00 80 20 02 0d b8 621 00 00 00 00 00 00 00 ff fe 00 33 44 06 14 00 80 622 f1 00 fe 80 00 00 00 00 00 00 00 00 00 ff fe 00 623 11 22 624 Dictionary: 625 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 626 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22 627 00 00 00 32 00 00 00 3a 16 fe fd 17 fe fd 00 01 628 00 00 00 00 00 01 00 00 629 copy: 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 630 ref(68): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 631 -> ref 101nssss 1 6/11nnnkkk 6 4: b6 f4 632 copy: 08 06 14 00 80 f1 00 fe 80 633 9 nulls: 87 634 ref(74): ff fe 00 11 22 -> ref 101nssss 0 8/11nnnkkk 3 5: a8 dd 635 Compressed: 636 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 b6 f4 08 637 06 14 00 80 f1 00 fe 80 87 a8 dd 638 Was 50 bytes; compressed to 27 bytes, compression factor 1.85 640 Figure 10: An RPL DAO message 642 Figure 11 shows the effect of compressing a simple ND neighbor 643 solicitation. 645 IP header: 646 60 00 00 00 00 30 3a ff 20 02 0d b8 00 00 00 00 647 00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00 648 02 1c da ff fe 00 30 23 649 Payload: 650 87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00 651 02 1c da ff fe 00 30 23 01 01 3b d3 00 00 00 00 652 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 653 Dictionary: 654 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 655 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 656 00 00 00 30 00 00 00 3a 16 fe fd 17 fe fd 00 01 657 00 00 00 00 00 01 00 00 658 copy: 04 87 00 a7 68 659 4 nulls: 82 660 ref(48): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 661 -> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0 662 copy: 04 01 01 3b d3 663 4 nulls: 82 664 copy: 02 1f 02 665 5 nulls: 83 666 copy: 02 06 00 667 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 668 copy: 02 20 24 669 Compressed: 670 04 87 00 a7 68 82 b4 f0 04 01 01 3b d3 82 02 1f 671 02 83 02 06 00 a2 db 02 20 24 672 Was 48 bytes; compressed to 26 bytes, compression factor 1.85 674 Figure 11: An ND neighbor solicitation 676 Figure 12 shows the compression of an ND neighbor advertisement. 678 IP header: 679 60 00 00 00 00 30 3a fe fe 80 00 00 00 00 00 00 680 02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00 681 00 00 00 ff fe 00 3b d3 682 Payload: 683 88 00 26 6c c0 00 00 00 fe 80 00 00 00 00 00 00 684 02 1c da ff fe 00 30 23 02 01 fa ce 00 00 00 00 685 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 686 Dictionary: 687 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 688 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 689 00 00 00 30 00 00 00 3a 16 fe fd 17 fe fd 00 01 690 00 00 00 00 00 01 00 00 691 copy: 05 88 00 26 6c c0 692 3 nulls: 81 693 ref(64): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 694 -> ref 101nssss 1 6/11nnnkkk 6 0: b6 f0 695 copy: 04 02 01 fa ce 696 4 nulls: 82 697 copy: 02 1f 02 698 5 nulls: 83 699 copy: 02 06 00 700 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 701 copy: 02 20 24 702 Compressed: 703 05 88 00 26 6c c0 81 b6 f0 04 02 01 fa ce 82 02 704 1f 02 83 02 06 00 a2 db 02 20 24 705 Was 48 bytes; compressed to 27 bytes, compression factor 1.78 707 Figure 12: An ND neighbor advertisement 709 Figure 13 shows the compression of an ND router solicitation. Note 710 that the relatively good compression is not caused by the many zero 711 bytes in the link-layer address of this particular capture (which are 712 unlikely to occur in practice): 7 of these 8 bytes are copied from 713 the pseudo-header (the 8th byte cannot be copied as the universal/ 714 local bit needs to be inverted). 716 IP header: 717 60 00 00 00 00 18 3a ff fe 80 00 00 00 00 00 00 718 ae de 48 00 00 00 00 01 ff 02 00 00 00 00 00 00 719 00 00 00 00 00 00 00 02 720 Payload: 721 85 00 90 65 00 00 00 00 01 02 ac de 48 00 00 00 722 00 01 00 00 00 00 00 00 723 Dictionary: 724 fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 725 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 726 00 00 00 18 00 00 00 3a 16 fe fd 17 fe fd 00 01 727 00 00 00 00 00 01 00 00 728 copy: 04 85 00 90 65 729 ref(11): 00 00 00 00 01 -> ref 11nnnkkk 3 6: de 730 copy: 02 02 ac 731 ref(58): de 48 00 00 00 00 01 732 -> ref 101nssss 0 6/11nnnkkk 5 3: a6 eb 733 6 nulls: 84 734 Compressed: 735 04 85 00 90 65 de 02 02 ac a6 eb 84 736 Was 24 bytes; compressed to 12 bytes, compression factor 2.00 738 Figure 13: An ND router solicitation 740 Figure 14 shows the compression of an ND router advertisement. The 741 indefinite lifetime is compressed to four bytes by backreferencing; 742 this could be improved (at the cost of minor additional decompressor 743 complexity) by including some simple runlength mechanism. 745 IP header: 746 60 00 00 00 00 60 3a ff fe 80 00 00 00 00 00 00 747 10 34 00 ff fe 00 11 22 fe 80 00 00 00 00 00 00 748 ae de 48 00 00 00 00 01 749 Payload: 750 86 00 55 c9 40 00 0f a0 1c 5a 38 17 00 00 07 d0 751 01 01 11 22 00 00 00 00 03 04 40 40 ff ff ff ff 752 ff ff ff ff 00 00 00 00 20 02 0d b8 00 00 00 00 753 00 00 00 00 00 00 00 00 20 02 40 10 00 00 03 e8 754 20 02 0d b8 00 00 00 00 21 03 00 01 00 00 00 00 755 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22 756 Dictionary: 757 fe 80 00 00 00 00 00 00 10 34 00 ff fe 00 11 22 758 fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 759 00 00 00 60 00 00 00 3a 16 fe fd 17 fe fd 00 01 760 00 00 00 00 00 01 00 00 761 copy: 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 762 2 nulls: 80 763 copy: 06 07 d0 01 01 11 22 764 4 nulls: 82 765 copy: 06 03 04 40 40 ff ff 766 ref(2): ff ff -> ref 11nnnkkk 0 0: c0 767 ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0 768 4 nulls: 82 769 copy: 04 20 02 0d b8 770 12 nulls: 8a 771 copy: 04 20 02 40 10 772 ref(38): 00 00 03 -> ref 101nssss 0 4/11nnnkkk 1 3: a4 cb 773 copy: 01 e8 774 ref(24): 20 02 0d b8 00 00 00 00 775 -> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0 776 copy: 02 21 03 777 ref(84): 00 01 00 00 00 00 778 -> ref 101nssss 0 9/11nnnkkk 4 6: a9 e6 779 ref(40): 20 02 0d b8 00 00 00 00 00 00 00 780 -> ref 101nssss 1 3/11nnnkkk 1 5: b3 cd 781 ref(136): ff fe 00 11 22 782 -> ref 101nssss 0 15/101nssss 0 1/11nnnkkk 3 3: af a1 db 783 Compressed: 784 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 80 06 07 785 d0 01 01 11 22 82 06 03 04 40 40 ff ff c0 d0 82 786 04 20 02 0d b8 8a 04 20 02 40 10 a4 cb 01 e8 a2 787 f0 02 21 03 a9 e6 b3 cd af a1 db 788 Was 96 bytes; compressed to 59 bytes, compression factor 1.63 790 Figure 14: An ND router advertisement 792 Figure 15 shows the compression of a DTLS application data packet 793 with a net payload of 13 bytes of cleartext, and 8 bytes of 794 authenticator (note that the IP header is not relevant for this 795 example and has been set to 0). This makes good use of the static 796 dictionary, and is quite effective crunching out the redundancy in 797 the TLS_PSK_WITH_AES_128_CCM_8 header, leading to a net reduction by 798 15 bytes. 800 IP header: 801 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 802 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 803 00 00 00 00 00 00 00 00 804 Payload: 805 17 fe fd 00 01 00 00 00 00 00 01 00 1d 00 01 00 806 00 00 00 00 01 09 b2 0e 82 c1 6e b6 96 c5 1f 36 807 8d 17 61 e2 b5 d4 22 d4 ed 2b 808 Dictionary: 809 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 811 00 00 00 2a 00 00 00 00 16 fe fd 17 fe fd 00 01 812 00 00 00 00 00 01 00 00 813 ref(13): 17 fe fd 00 01 00 00 00 00 00 01 00 814 -> ref 101nssss 1 0/11nnnkkk 2 1: b0 d1 815 copy: 01 1d 816 ref(10): 00 01 00 00 00 00 00 01 -> ref 11nnnkkk 6 2: f2 817 copy: 15 09 b2 0e 82 c1 6e b6 96 c5 1f 36 8d 17 61 e2 818 copy: b5 d4 22 d4 ed 2b 819 Compressed: 820 b0 d1 01 1d f2 15 09 b2 0e 82 c1 6e b6 96 c5 1f 821 36 8d 17 61 e2 b5 d4 22 d4 ed 2b 822 Was 42 bytes; compressed to 27 bytes, compression factor 1.56 824 Figure 15: A DTLS application data packet 826 Figure 16 shows that the compression is slightly worse in a 827 subsequent packet (containing 6 bytes of cleartext and 8 bytes of 828 authenticator, yielding a net compression of 13 bytes). The total 829 overhead does stay at a quite acceptable 8 bytes. 831 IP header: 832 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 833 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 834 00 00 00 00 00 00 00 00 835 Payload: 836 17 fe fd 00 01 00 00 00 00 00 05 00 16 00 01 00 837 00 00 00 00 05 ae a0 15 56 67 92 4d ff 8a 24 e4 838 cb 35 b9 839 Dictionary: 840 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 841 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 842 00 00 00 23 00 00 00 00 16 fe fd 17 fe fd 00 01 843 00 00 00 00 00 01 00 00 844 ref(13): 17 fe fd 00 01 00 00 00 00 00 845 -> ref 101nssss 1 0/11nnnkkk 0 3: b0 c3 846 copy: 03 05 00 16 847 ref(10): 00 01 00 00 00 00 00 05 -> ref 11nnnkkk 6 2: f2 848 copy: 0e ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 849 Compressed: 850 b0 c3 03 05 00 16 f2 0e ae a0 15 56 67 92 4d ff 851 8a 24 e4 cb 35 b9 852 Was 35 bytes; compressed to 22 bytes, compression factor 1.59 854 Figure 16: Another DTLS application data packet 856 Figure 17 shows the compression of a DTLS handshake message, here a 857 client hello. There is little that can be compressed about the 32 858 bytes of randomness. Still, the net reduction is by 14 bytes. 860 IP header: 861 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 862 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 863 00 00 00 00 00 00 00 00 864 Payload: 865 16 fe fd 00 00 00 00 00 00 00 00 00 36 01 00 00 866 2a 00 00 00 00 00 00 00 2a fe fd 51 52 ed 79 a4 867 20 c9 62 56 11 47 c9 39 ee 6c c0 a4 fe c6 89 2f 868 32 26 9a 16 4e 31 7e 9f 20 92 92 00 00 00 02 c0 869 a8 01 00 870 Dictionary: 871 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 872 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 873 00 00 00 43 00 00 00 00 16 fe fd 17 fe fd 00 01 874 00 00 00 00 00 01 00 00 875 ref(16): 16 fe fd -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd 876 9 nulls: 87 877 copy: 01 36 878 ref(16): 01 00 00 -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd 879 copy: 01 2a 880 7 nulls: 85 881 copy: 23 2a fe fd 51 52 ed 79 a4 20 c9 62 56 11 47 c9 882 copy: 39 ee 6c c0 a4 fe c6 89 2f 32 26 9a 16 4e 31 7e 883 copy: 9f 20 92 92 884 3 nulls: 81 885 copy: 05 02 c0 a8 01 00 886 Compressed: 887 a1 cd 87 01 36 a1 cd 01 2a 85 23 2a fe fd 51 52 888 ed 79 a4 20 c9 62 56 11 47 c9 39 ee 6c c0 a4 fe 889 c6 89 2f 32 26 9a 16 4e 31 7e 9f 20 92 92 81 05 890 02 c0 a8 01 00 891 Was 67 bytes; compressed to 53 bytes, compression factor 1.26 893 Figure 17: A DTLS handshake packet (client hello) 895 Author's Address 897 Carsten Bormann 898 Universitaet Bremen TZI 899 Postfach 330440 900 D-28359 Bremen 901 Germany 903 Phone: +49-421-218-63921 904 Email: cabo@tzi.org