idnits 2.17.1 draft-ietf-6lo-ghc-03.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 3561 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-03 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 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 545 copy: 04 9b 00 6b de 546 4 nulls: 82 547 Compressed: 548 04 9b 00 6b de 82 549 Was 8 bytes; compressed to 6 bytes, compression factor 1.33 551 Figure 8: A simple RPL example 553 Figure 9 shows an RPL DODAG Information Object, a longer RPL control 554 message that is improved a bit more. Note that the compressed output 555 exposes an inefficiency in the simple-minded compressor used to 556 generate it; this does not devalue the example since constrained 557 nodes are quite likely to make use of simple-minded compressors. 559 IP header: 560 60 00 00 00 00 5c 3a ff fe 80 00 00 00 00 00 00 561 02 1c da ff fe 00 30 23 ff 02 00 00 00 00 00 00 562 00 00 00 00 00 00 00 1a 563 Payload: 564 9b 01 7a 5f 00 f0 01 00 88 00 00 00 20 02 0d b8 565 00 00 00 00 00 00 00 ff fe 00 fa ce 04 0e 00 14 566 09 ff 00 00 01 00 00 00 00 00 00 00 08 1e 80 20 567 ff ff ff ff ff ff ff ff 00 00 00 00 20 02 0d b8 568 00 00 00 00 00 00 00 ff fe 00 fa ce 03 0e 40 00 569 ff ff ff ff 20 02 0d b8 00 00 00 00 570 Dictionary: 571 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 572 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 573 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 574 copy: 06 9b 01 7a 5f 00 f0 575 ref(9): 01 00 -> ref 11nnnkkk 0 7: c7 576 copy: 01 88 577 3 nulls: 81 578 copy: 04 20 02 0d b8 579 7 nulls: 85 580 ref(60): ff fe 00 -> ref 101nssss 0 7/11nnnkkk 1 1: a7 c9 581 copy: 08 fa ce 04 0e 00 14 09 ff 582 ref(39): 00 00 01 00 00 -> ref 101nssss 0 4/11nnnkkk 3 2: a4 da 583 5 nulls: 83 584 copy: 06 08 1e 80 20 ff ff 585 ref(2): ff ff -> ref 11nnnkkk 0 0: c0 586 ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0 587 4 nulls: 82 588 ref(48): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 fa ce 589 -> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0 590 copy: 03 03 0e 40 591 ref(9): 00 ff -> ref 11nnnkkk 0 7: c7 592 ref(28): ff ff ff -> ref 101nssss 0 3/11nnnkkk 1 1: a3 c9 593 ref(24): 20 02 0d b8 00 00 00 00 594 -> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0 595 Compressed: 596 06 9b 01 7a 5f 00 f0 c7 01 88 81 04 20 02 0d b8 597 85 a7 c9 08 fa ce 04 0e 00 14 09 ff a4 da 83 06 598 08 1e 80 20 ff ff c0 d0 82 b4 f0 03 03 0e 40 c7 599 a3 c9 a2 f0 600 Was 92 bytes; compressed to 52 bytes, compression factor 1.77 602 Figure 9: A longer RPL example 604 Similarly, Figure 10 shows an RPL DAO message. One of the embedded 605 addresses is copied right out of the pseudo-header, the other one is 606 effectively converted from global to local by providing the prefix 607 FE80 literally, inserting a number of nulls, and copying (some of) 608 the IID part again out of the pseudo-header. Note that a simple 609 implementation would probably emit fewer nulls and copy the entire 610 IID; there are multiple ways to encode this 50-byte payload into 27 611 bytes. 613 IP header: 614 60 00 00 00 00 32 3a ff 20 02 0d b8 00 00 00 00 615 00 00 00 ff fe 00 33 44 20 02 0d b8 00 00 00 00 616 00 00 00 ff fe 00 11 22 617 Payload: 618 9b 02 58 7d 01 80 00 f1 05 12 00 80 20 02 0d b8 619 00 00 00 00 00 00 00 ff fe 00 33 44 06 14 00 80 620 f1 00 fe 80 00 00 00 00 00 00 00 00 00 ff fe 00 621 11 22 622 Dictionary: 623 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 624 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22 625 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 626 copy: 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 627 ref(60): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 628 -> ref 101nssss 1 5/11nnnkkk 6 4: b5 f4 629 copy: 08 06 14 00 80 f1 00 fe 80 630 9 nulls: 87 631 ref(66): ff fe 00 11 22 -> ref 101nssss 0 7/11nnnkkk 3 5: a7 dd 632 Compressed: 633 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 b5 f4 08 634 06 14 00 80 f1 00 fe 80 87 a7 dd 635 Was 50 bytes; compressed to 27 bytes, compression factor 1.85 637 Figure 10: An RPL DAO message 639 Figure 11 shows the effect of compressing a simple ND neighbor 640 solicitation. 642 IP header: 643 60 00 00 00 00 30 3a ff 20 02 0d b8 00 00 00 00 644 00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00 645 02 1c da ff fe 00 30 23 646 Payload: 647 87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00 648 02 1c da ff fe 00 30 23 01 01 3b d3 00 00 00 00 649 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 650 Dictionary: 651 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 652 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 653 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 654 copy: 04 87 00 a7 68 655 4 nulls: 82 656 ref(40): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 657 -> ref 101nssss 1 3/11nnnkkk 6 0: b3 f0 658 copy: 04 01 01 3b d3 659 4 nulls: 82 660 copy: 02 1f 02 661 5 nulls: 83 662 copy: 02 06 00 663 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 664 copy: 02 20 24 665 Compressed: 666 04 87 00 a7 68 82 b3 f0 04 01 01 3b d3 82 02 1f 667 02 83 02 06 00 a2 db 02 20 24 668 Was 48 bytes; compressed to 26 bytes, compression factor 1.85 670 Figure 11: An ND neighbor solicitation 672 Figure 12 shows the compression of an ND neighbor advertisement. 674 IP header: 675 60 00 00 00 00 30 3a fe fe 80 00 00 00 00 00 00 676 02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00 677 00 00 00 ff fe 00 3b d3 678 Payload: 679 88 00 26 6c c0 00 00 00 fe 80 00 00 00 00 00 00 680 02 1c da ff fe 00 30 23 02 01 fa ce 00 00 00 00 681 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 682 Dictionary: 683 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 684 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 685 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 686 copy: 05 88 00 26 6c c0 687 3 nulls: 81 688 ref(56): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 689 -> ref 101nssss 1 5/11nnnkkk 6 0: b5 f0 690 copy: 04 02 01 fa ce 691 4 nulls: 82 692 copy: 02 1f 02 693 5 nulls: 83 694 copy: 02 06 00 695 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 696 copy: 02 20 24 697 Compressed: 698 05 88 00 26 6c c0 81 b5 f0 04 02 01 fa ce 82 02 699 1f 02 83 02 06 00 a2 db 02 20 24 700 Was 48 bytes; compressed to 27 bytes, compression factor 1.78 702 Figure 12: An ND neighbor advertisement 704 Figure 13 shows the compression of an ND router solicitation. Note 705 that the relatively good compression is not caused by the many zero 706 bytes in the link-layer address of this particular capture (which are 707 unlikely to occur in practice): 7 of these 8 bytes are copied from 708 the pseudo-header (the 8th byte cannot be copied as the universal/ 709 local bit needs to be inverted). 711 IP header: 712 60 00 00 00 00 18 3a ff fe 80 00 00 00 00 00 00 713 ae de 48 00 00 00 00 01 ff 02 00 00 00 00 00 00 714 00 00 00 00 00 00 00 02 715 Payload: 716 85 00 90 65 00 00 00 00 01 02 ac de 48 00 00 00 717 00 01 00 00 00 00 00 00 718 Dictionary: 719 fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 720 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 721 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 722 copy: 04 85 00 90 65 723 ref(11): 00 00 00 00 01 -> ref 11nnnkkk 3 6: de 724 copy: 02 02 ac 725 ref(50): de 48 00 00 00 00 01 726 -> ref 101nssss 0 5/11nnnkkk 5 3: a5 eb 727 6 nulls: 84 728 Compressed: 729 04 85 00 90 65 de 02 02 ac a5 eb 84 730 Was 24 bytes; compressed to 12 bytes, compression factor 2.00 732 Figure 13: An ND router solicitation 734 Figure 14 shows the compression of an ND router advertisement. The 735 indefinite lifetime is compressed to four bytes by backreferencing; 736 this could be improved (at the cost of minor additional decompressor 737 complexity) by including some simple runlength mechanism. 739 IP header: 740 60 00 00 00 00 60 3a ff fe 80 00 00 00 00 00 00 741 10 34 00 ff fe 00 11 22 fe 80 00 00 00 00 00 00 742 ae de 48 00 00 00 00 01 743 Payload: 744 86 00 55 c9 40 00 0f a0 1c 5a 38 17 00 00 07 d0 745 01 01 11 22 00 00 00 00 03 04 40 40 ff ff ff ff 746 ff ff ff ff 00 00 00 00 20 02 0d b8 00 00 00 00 747 00 00 00 00 00 00 00 00 20 02 40 10 00 00 03 e8 748 20 02 0d b8 00 00 00 00 21 03 00 01 00 00 00 00 749 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22 750 Dictionary: 751 fe 80 00 00 00 00 00 00 10 34 00 ff fe 00 11 22 752 fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 753 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 754 copy: 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 755 2 nulls: 80 756 copy: 06 07 d0 01 01 11 22 757 4 nulls: 82 758 copy: 06 03 04 40 40 ff ff 759 ref(2): ff ff -> ref 11nnnkkk 0 0: c0 760 ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0 761 4 nulls: 82 762 copy: 04 20 02 0d b8 763 12 nulls: 8a 764 copy: 04 20 02 40 10 765 ref(38): 00 00 03 -> ref 101nssss 0 4/11nnnkkk 1 3: a4 cb 766 copy: 01 e8 767 ref(24): 20 02 0d b8 00 00 00 00 768 -> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0 769 copy: 02 21 03 770 ref(84): 00 01 00 00 00 00 771 -> ref 101nssss 0 9/11nnnkkk 4 6: a9 e6 772 ref(40): 20 02 0d b8 00 00 00 00 00 00 00 773 -> ref 101nssss 1 3/11nnnkkk 1 5: b3 cd 774 ref(128): ff fe 00 11 22 775 -> ref 101nssss 0 15/11nnnkkk 3 3: af db 776 Compressed: 777 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 80 06 07 778 d0 01 01 11 22 82 06 03 04 40 40 ff ff c0 d0 82 779 04 20 02 0d b8 8a 04 20 02 40 10 a4 cb 01 e8 a2 780 f0 02 21 03 a9 e6 b3 cd af db 781 Was 96 bytes; compressed to 58 bytes, compression factor 1.66 783 Figure 14: An ND router advertisement 785 Figure 15 shows the compression of a DTLS application data packet 786 with a net payload of 13 bytes of cleartext, and 8 bytes of 787 authenticator (note that the IP header is not relevant for this 788 example and has been set to 0). This makes good use of the static 789 dictionary, and is quite effective crunching out the redundancy in 790 the TLS_PSK_WITH_AES_128_CCM_8 header, leading to a net reduction by 791 15 bytes. 793 IP header: 794 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 795 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 796 00 00 00 00 00 00 00 00 797 Payload: 798 17 fe fd 00 01 00 00 00 00 00 01 00 1d 00 01 00 799 00 00 00 00 01 09 b2 0e 82 c1 6e b6 96 c5 1f 36 800 8d 17 61 e2 b5 d4 22 d4 ed 2b 801 Dictionary: 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 00 00 00 00 00 00 00 00 804 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 805 ref(13): 17 fe fd 00 01 00 00 00 00 00 01 00 806 -> ref 101nssss 1 0/11nnnkkk 2 1: b0 d1 807 copy: 01 1d 808 ref(10): 00 01 00 00 00 00 00 01 -> ref 11nnnkkk 6 2: f2 809 copy: 15 09 b2 0e 82 c1 6e b6 96 c5 1f 36 8d 17 61 e2 810 copy: b5 d4 22 d4 ed 2b 811 Compressed: 812 b0 d1 01 1d f2 15 09 b2 0e 82 c1 6e b6 96 c5 1f 813 36 8d 17 61 e2 b5 d4 22 d4 ed 2b 814 Was 42 bytes; compressed to 27 bytes, compression factor 1.56 816 Figure 15: A DTLS application data packet 818 Figure 16 shows that the compression is slightly worse in a 819 subsequent packet (containing 6 bytes of cleartext and 8 bytes of 820 authenticator, yielding a net compression of 13 bytes). The total 821 overhead does stay at a quite acceptable 8 bytes. 823 IP header: 824 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 825 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 826 00 00 00 00 00 00 00 00 827 Payload: 828 17 fe fd 00 01 00 00 00 00 00 05 00 16 00 01 00 829 00 00 00 00 05 ae a0 15 56 67 92 4d ff 8a 24 e4 830 cb 35 b9 831 Dictionary: 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 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 835 ref(13): 17 fe fd 00 01 00 00 00 00 00 836 -> ref 101nssss 1 0/11nnnkkk 0 3: b0 c3 837 copy: 03 05 00 16 838 ref(10): 00 01 00 00 00 00 00 05 -> ref 11nnnkkk 6 2: f2 839 copy: 0e ae a0 15 56 67 92 4d ff 8a 24 e4 cb 35 b9 840 Compressed: 841 b0 c3 03 05 00 16 f2 0e ae a0 15 56 67 92 4d ff 842 8a 24 e4 cb 35 b9 843 Was 35 bytes; compressed to 22 bytes, compression factor 1.59 845 Figure 16: Another DTLS application data packet 847 Figure 17 shows the compression of a DTLS handshake message, here a 848 client hello. There is little that can be compressed about the 32 849 bytes of randomness. Still, the net reduction is by 14 bytes. 851 IP header: 852 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 853 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 854 00 00 00 00 00 00 00 00 855 Payload: 856 16 fe fd 00 00 00 00 00 00 00 00 00 36 01 00 00 857 2a 00 00 00 00 00 00 00 2a fe fd 51 52 ed 79 a4 858 20 c9 62 56 11 47 c9 39 ee 6c c0 a4 fe c6 89 2f 859 32 26 9a 16 4e 31 7e 9f 20 92 92 00 00 00 02 c0 860 a8 01 00 861 Dictionary: 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 00 00 00 00 00 00 00 00 864 16 fe fd 17 fe fd 00 01 00 00 00 00 00 01 00 00 865 ref(16): 16 fe fd -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd 866 9 nulls: 87 867 copy: 01 36 868 ref(16): 01 00 00 -> ref 101nssss 0 1/11nnnkkk 1 5: a1 cd 869 copy: 01 2a 870 7 nulls: 85 871 copy: 23 2a fe fd 51 52 ed 79 a4 20 c9 62 56 11 47 c9 872 copy: 39 ee 6c c0 a4 fe c6 89 2f 32 26 9a 16 4e 31 7e 873 copy: 9f 20 92 92 874 3 nulls: 81 875 copy: 05 02 c0 a8 01 00 876 Compressed: 877 a1 cd 87 01 36 a1 cd 01 2a 85 23 2a fe fd 51 52 878 ed 79 a4 20 c9 62 56 11 47 c9 39 ee 6c c0 a4 fe 879 c6 89 2f 32 26 9a 16 4e 31 7e 9f 20 92 92 81 05 880 02 c0 a8 01 00 881 Was 67 bytes; compressed to 53 bytes, compression factor 1.26 883 Figure 17: A DTLS handshake packet (client hello) 885 Author's Address 887 Carsten Bormann 888 Universitaet Bremen TZI 889 Postfach 330440 890 D-28359 Bremen 891 Germany 893 Phone: +49-421-218-63921 894 Email: cabo@tzi.org