idnits 2.17.1 draft-bormann-6lowpan-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 (March 14, 2011) is 4763 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 599, but not defined == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-15 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-04) exists of draft-bormann-6lowpan-roadmap-00 == Outdated reference: A later version (-14) exists of draft-ietf-core-link-format-02 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track March 14, 2011 5 Expires: September 15, 2011 7 6LoWPAN Generic Compression of Headers and Header-like Payloads 8 draft-bormann-6lowpan-ghc-02 10 Abstract 12 This short I-D provides a complete design for a simple addition to 13 6LoWPAN Header Compression that enables the compression of generic 14 headers and header-like payloads. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on September 15, 2011. 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. The Header Compression Coupling Problem . . . . . . . . . 3 52 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. 6LoWPAN-GHC . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.1. Nibblecode . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 4. Integrating 6LoWPAN-GHC into 6LoWPAN-HC . . . . . . . . . . . 14 57 4.1. Compressing extension headers . . . . . . . . . . . . . . 14 58 4.2. Indicating GHC capability . . . . . . . . . . . . . . . . 15 59 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 16 60 6. Security considerations . . . . . . . . . . . . . . . . . . . 17 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 63 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 64 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 67 1. Introduction 69 1.1. The Header Compression Coupling Problem 71 [I-D.ietf-6lowpan-hc] defines a scheme for header compression in 72 6LoWPAN [RFC4944] packets. As with most header compression schemes, 73 a new specification is needed for every new kind of header that needs 74 to be compressed. In addition, [I-D.ietf-6lowpan-hc] does not define 75 an extensibility scheme like the ROHC profiles defined in ROHC 76 [RFC3095] [RFC5795]. This leads to the difficult situation that 77 [I-D.ietf-6lowpan-hc] tends to be reopened and reexamined each time a 78 new header receives consideration (or an old header is changed and 79 reconsidered) in the 6lowpan/roll/core cluster of IETF working 80 groups. At this rate, [I-D.ietf-6lowpan-hc] will never get completed 81 (fortunately, by now it has passed WGLC, but the underlying problem 82 remains unsolved). 84 The purpose of the present contribution is to plug into 85 [I-D.ietf-6lowpan-hc] as is, using its NHC (next header compression) 86 concept. We add a slightly less efficient, but vastly more general 87 form of compression for headers of any kind and even for header-like 88 payloads such as those exhibited by routing protocols, DHCP, etc. 89 The objective is to arrive at something that can be defined on a 90 single page and implemented in a couple of lines of code, as opposed 91 to a general data compression scheme such as that defined in 92 [RFC1951]. 94 1.2. Terminology 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in RFC 2119 [RFC2119]. 100 The term "byte" is used in its now customary sense as a synonym for 101 "octet". 103 2. 6LoWPAN-GHC 105 The format of a compressed header or payload is a simple bytecode. A 106 compressed header consists of a sequence of pieces, each of which 107 begins with a code byte, which may be followed by zero or more bytes 108 as its argument. Some code bytes cause bytes to be laid out in the 109 destination buffer, some simply modify some decompression variables. 111 At the start of decompressing a header or payload within a L2 packet 112 (= fragment), variables "sa" and "na" are initialized as zero. 114 The code bytes are defined as follows: 116 +----------+---------------------------------------------+----------+ 117 | code | Action | Argument | 118 | byte | | | 119 +----------+---------------------------------------------+----------+ 120 | 0kkkkkkk | Append k = 0b0kkkkkkk bytes of data in the | k bytes | 121 | | bytecode argument (k < 96) | of data | 122 | | | | 123 | 0110iiii | Append all bytes (possibly filling an | | 124 | | incomplete byte with zero bits) from | | 125 | | Context i | | 126 | | | | 127 | 0111iiii | Append 8 bytes from Context i; i.e., the | | 128 | | context value truncated/extended to 8 | | 129 | | bytes, and then append 0000 00FF FE00 | | 130 | | (i.e., 14 bytes total) | | 131 | | | | 132 | 1000nnnn | Append 0b0000nnnn+2 bytes of zeroes | | 133 | | | | 134 | 10010000 | STOP code (end of compressed data) | | 135 | | | | 136 | 1001nnnn | Enter nibblecode (Section 2.1) | | 137 | | | | 138 | 101nssss | sa += 0b0ssss000, na += 0b0000n000 | | 139 | | | | 140 | 11nnnkkk | n = na+0b00000nnn+2; s = 0b00000kkk+sa+n; | | 141 | | append n bytes from previously output | | 142 | | bytes, starting s bytes to the left of the | | 143 | | current output pointer; set sa = 0, na = 0 | | 144 +----------+---------------------------------------------+----------+ 146 For the purposes of the backreferences, the expansion buffer is 147 initialized with the pseudo-header as defined in [RFC2460], at the 148 end of which the target buffer begins. These pseudo-header bytes are 149 therefore available for backreferencing, but not copied into the 150 final result. 152 2.1. Nibblecode 154 (It is to be decided whether the mechanism described in this section 155 is worth its additional complexity. To make this decision, it would 156 be useful to obtain more packet captures, in particular those that do 157 include ASCII data - the packet-capture-based examples in Section 3 158 currently do not include nibblecode.) 160 Some headers/header-like structures, such as those used in CoAP or 161 DNS, may use ASCII data. There is very little redundancy by 162 repetition in these (DNS actually has its own compression mechanism 163 for repetition), so the backreferencing mechanism provided in the 164 bytecode is not very effective. 166 Efficient stateless compression for small amounts of ASCII data of 167 this kind is pretty much confined to Huffman (or, for even more 168 complexity, arithmetic) coding. The complexity can be reduced 169 significantly by moving to n-ary Huffman coding, i.e., optimizing not 170 to the bit level, but to a larger level of granularity. Informal 171 experiments by the author show that a 16ary Huffman coding is close 172 to optimal at least for a small corpus of URI data. In other words, 173 basing the encoding on nibbles (4-bit half-bytes) is both nearly 174 optimal and relatively inexpensive to implement. 176 The actual letter frequencies that will occur in more general 6LoWPAN 177 ASCII data are hard to predict. As a first indication, the author 178 has analyzed an HTTP-based URI corpus and found the following lower 179 case letters to be the ASCII characters that occur with highest 180 frequency: aeinorst - it is therefore most useful to compress these. 182 In the encoding proposed, each byte representing one of these eight 183 highly-compressed characters is represented by a single 4-bit nibble 184 from the range 0x8 to 0xF. Bytes representing printable ASCII 185 characters, more specifically bytes from 0x20 to 0x7F, are 186 represented by both of their nibbles. Bytes from 0x00 to 0x1F and 187 from 0x80 to 0xFF are represented by a 0x1 nibble followed by both 188 nibbles of the byte. An 0x0 nibble terminates the nibblecode 189 sequence and returns to bytecode on the next byte boundary. 191 The first nibble of the nibblecode is transmitted right in the "enter 192 nibblecode" bytecode (0x9x - note that since it is never useful to 193 immediately return to bytecode, the bytecode 0x90 is allocated for a 194 different purpose). All other nibbles of the nibblecode are 195 transmitted as a sequence of bytes in most-significant-nibble-first 196 order; any unused nibble in the last byte of a nibblecode sequence is 197 set to 0x0. 199 The encoding is summarized in Figure 1. 201 0 1 202 0 1 2 3 4 5 6 7 8 9 0 1 203 +---+---+---+---+ 204 | 8-F | aeinorst 205 +---+---+---+---+ 89ABCDEF 207 +---+---+---+---+---+---+---+---+ 208 | 2-7 | 0-F | other ASCII 209 +---+---+---+---+---+---+---+---+ 211 +---+---+---+---+---+---+---+---+---+---+---+---+ 212 | 1 | 0-F | 0-F | 0xHH 213 +---+---+---+---+---+---+---+---+---+---+---+---+ 215 +---+---+---+---+ 216 | 0 | return to bytecode 217 +---+---+---+---+ 219 Figure 1: A nibble-based encoding 221 As an example for what level of compression can be expected, the 121 222 bytes of ASCII text shown in Figure 2 (taken from 223 [I-D.ietf-core-link-format]) are compressed into 183 nibbles of 224 nibblecode, which (including delimiter and padding overhead) need 93 225 bytes, resulting in a net compression factor of 1.30. (Note that 226 RFC 4944/6LoWPAN-HC supports compression only in the first of a 227 sequence of adaptation layer fragments; 93 bytes may not all fit into 228 the first fragment, so any remaining payload would be sent without 229 the benefit of compression.) 231 ;anchor="/sensors/temp" 232 ;rel=describedby, 233 ;anchor="/sensors/temp";rel=alternate 235 Figure 2: Example input text (line-wrapped) 237 3. Examples 239 This section demonstrates some relatively realistic examples derived 240 from actual PCAP dumps taken at previous interops. Unfortunately, 241 for these dumps, no context information was available, so the 242 relatively powerful effect of context-based compression is not shown. 243 (TBD: Add a couple DHCP examples.) 245 Figure 3 shows an RPL DODAG Information Solicitation, a quite short 246 RPL message that obviously cannot be improved much. 248 IP header: 249 60 00 00 00 00 08 3a ff fe 80 00 00 00 00 00 00 250 02 1c da ff fe 00 20 24 ff 02 00 00 00 00 00 00 251 00 00 00 00 00 00 00 1a 252 Payload: 253 9b 00 6b de 00 00 00 00 254 Pseudoheader: 255 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 20 24 256 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 257 00 00 00 08 00 00 00 3a 258 copy: 04 9b 00 6b de 259 4 nulls: 82 260 Compressed: 261 04 9b 00 6b de 82 262 Was 8 bytes; compressed to 6 bytes, compression factor 1.33 264 Figure 3: A simple RPL example 266 Figure 4 shows an RPL DODAG Information Object, a longer RPL control 267 message that is improved a bit more (but would likely benefit 268 additionally from a context reference). Note that the compressed 269 output exposes an inefficiency in the simple-minded compressor used 270 to generate it; this does not devalue the example since constrained 271 nodes are quite likely to make use of simple-minded compressors. 273 IP header: 274 60 00 00 00 00 5c 3a ff fe 80 00 00 00 00 00 00 275 02 1c da ff fe 00 30 23 ff 02 00 00 00 00 00 00 276 00 00 00 00 00 00 00 1a 277 Payload: 278 9b 01 7a 5f 00 f0 01 00 88 00 00 00 20 02 0d b8 279 00 00 00 00 00 00 00 ff fe 00 fa ce 04 0e 00 14 280 09 ff 00 00 01 00 00 00 00 00 00 00 08 1e 80 20 281 ff ff ff ff ff ff ff ff 00 00 00 00 20 02 0d b8 282 00 00 00 00 00 00 00 ff fe 00 fa ce 03 0e 40 00 283 ff ff ff ff 20 02 0d b8 00 00 00 00 284 Pseudoheader: 285 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 286 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 1a 287 00 00 00 5c 00 00 00 3a 288 copy: 09 9b 01 7a 5f 00 f0 01 00 88 289 3 nulls: 81 290 copy: 04 20 02 0d b8 291 7 nulls: 85 292 ref(52): ff fe 00 -> ref 101nssss 0 6/11nnnkkk 1 1: a6 c9 293 copy: 08 fa ce 04 0e 00 14 09 ff 294 2 nulls: 80 295 copy: 01 01 296 7 nulls: 85 297 copy: 06 08 1e 80 20 ff ff 298 ref(2): ff ff -> ref 11nnnkkk 0 0: c0 299 ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0 300 4 nulls: 82 301 ref(48): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 fa ce 302 -> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0 303 copy: 03 03 0e 40 304 ref(9): 00 ff -> ref 11nnnkkk 0 7: c7 305 ref(28): ff ff ff -> ref 101nssss 0 3/11nnnkkk 1 1: a3 c9 306 ref(24): 20 02 0d b8 00 00 00 00 307 -> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0 308 Compressed: 309 09 9b 01 7a 5f 00 f0 01 00 88 81 04 20 02 0d b8 310 85 a6 c9 08 fa ce 04 0e 00 14 09 ff 80 01 01 85 311 06 08 1e 80 20 ff ff c0 d0 82 b4 f0 03 03 0e 40 312 c7 a3 c9 a2 f0 313 Was 92 bytes; compressed to 53 bytes, compression factor 1.74 315 Figure 4: A longer RPL example 317 Similarly, Figure 5 shows an RPL DAO message. One of the embedded 318 addresses is copied right out of the pseudoheader, the other one is 319 effectively converted from global to local by providing the prefix 320 FE80 literally, inserting a number of nulls, and copying (some of) 321 the IID part again out of the pseudoheader. Note that a simple 322 implementation would probably emit fewer nulls and copy the entire 323 IID; there are multiple ways to encode this 50-byte payload into 27 324 bytes. 326 IP header: 327 60 00 00 00 00 32 3a ff 20 02 0d b8 00 00 00 00 328 00 00 00 ff fe 00 33 44 20 02 0d b8 00 00 00 00 329 00 00 00 ff fe 00 11 22 330 Payload: 331 9b 02 58 7d 01 80 00 f1 05 12 00 80 20 02 0d b8 332 00 00 00 00 00 00 00 ff fe 00 33 44 06 14 00 80 333 f1 00 fe 80 00 00 00 00 00 00 00 00 00 ff fe 00 334 11 22 335 Pseudoheader: 336 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 337 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22 338 00 00 00 32 00 00 00 3a 339 copy: 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 340 ref(52): 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 33 44 341 -> ref 101nssss 1 4/11nnnkkk 6 4: b4 f4 342 copy: 08 06 14 00 80 f1 00 fe 80 343 9 nulls: 87 344 ref(58): ff fe 00 11 22 -> ref 101nssss 0 6/11nnnkkk 3 5: a6 dd 345 Compressed: 346 0c 9b 02 58 7d 01 80 00 f1 05 12 00 80 b4 f4 08 347 06 14 00 80 f1 00 fe 80 87 a6 dd 348 Was 50 bytes; compressed to 27 bytes, compression factor 1.85 350 Figure 5: An RPL DAO message 352 Figure 6 shows the effect of compressing a simple ND neighbor 353 solicitation (again, no context-based compression). 355 IP header: 356 60 00 00 00 00 30 3a ff 20 02 0d b8 00 00 00 00 357 00 00 00 ff fe 00 3b d3 fe 80 00 00 00 00 00 00 358 02 1c da ff fe 00 30 23 359 Payload: 360 87 00 a7 68 00 00 00 00 fe 80 00 00 00 00 00 00 361 02 1c da ff fe 00 30 23 01 01 3b d3 00 00 00 00 362 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 363 Pseudoheader: 364 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 365 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 366 00 00 00 30 00 00 00 3a 367 copy: 04 87 00 a7 68 368 4 nulls: 82 369 ref(32): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 370 -> ref 101nssss 1 2/11nnnkkk 6 0: b2 f0 371 copy: 04 01 01 3b d3 372 4 nulls: 82 373 copy: 02 1f 02 374 5 nulls: 83 375 copy: 02 06 00 376 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 377 copy: 02 20 24 378 Compressed: 379 04 87 00 a7 68 82 b2 f0 04 01 01 3b d3 82 02 1f 380 02 83 02 06 00 a2 db 02 20 24 381 Was 48 bytes; compressed to 26 bytes, compression factor 1.85 383 Figure 6: An ND neighbor solicitation 385 Figure 7 shows the compression of an ND neighbor advertisement. 387 IP header: 388 60 00 00 00 00 30 3a fe fe 80 00 00 00 00 00 00 389 02 1c da ff fe 00 30 23 20 02 0d b8 00 00 00 00 390 00 00 00 ff fe 00 3b d3 391 Payload: 392 88 00 26 6c c0 00 00 00 fe 80 00 00 00 00 00 00 393 02 1c da ff fe 00 30 23 02 01 fa ce 00 00 00 00 394 1f 02 00 00 00 00 00 06 00 1c da ff fe 00 20 24 395 Pseudoheader: 396 fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 397 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 3b d3 398 00 00 00 30 00 00 00 3a 399 copy: 05 88 00 26 6c c0 400 3 nulls: 81 401 ref(48): fe 80 00 00 00 00 00 00 02 1c da ff fe 00 30 23 402 -> ref 101nssss 1 4/11nnnkkk 6 0: b4 f0 403 copy: 04 02 01 fa ce 404 4 nulls: 82 405 copy: 02 1f 02 406 5 nulls: 83 407 copy: 02 06 00 408 ref(24): 1c da ff fe 00 -> ref 101nssss 0 2/11nnnkkk 3 3: a2 db 409 copy: 02 20 24 410 Compressed: 411 05 88 00 26 6c c0 81 b4 f0 04 02 01 fa ce 82 02 412 1f 02 83 02 06 00 a2 db 02 20 24 413 Was 48 bytes; compressed to 27 bytes, compression factor 1.78 415 Figure 7: An ND neighbor advertisement 417 Figure 8 shows the compression of an ND router solicitation. Note 418 that the relatively good compression is not caused by the many zero 419 bytes in the link-layer address of this particular capture (which are 420 unlikely to occur in practice): 7 of these 8 bytes are copied from 421 the pseudo header (the 8th byte cannot be copied as the universal/ 422 local bit needs to be inverted). 424 IP header: 425 60 00 00 00 00 18 3a ff fe 80 00 00 00 00 00 00 426 ae de 48 00 00 00 00 01 ff 02 00 00 00 00 00 00 427 00 00 00 00 00 00 00 02 428 Payload: 429 85 00 90 65 00 00 00 00 01 02 ac de 48 00 00 00 430 00 01 00 00 00 00 00 00 431 Pseudoheader: 432 fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 433 ff 02 00 00 00 00 00 00 00 00 00 00 00 00 00 02 434 00 00 00 18 00 00 00 3a 435 copy: 04 85 00 90 65 436 ref(33): 00 00 00 00 01 -> ref 101nssss 0 3/11nnnkkk 3 4: a3 dc 437 copy: 02 02 ac 438 ref(42): de 48 00 00 00 00 01 439 -> ref 101nssss 0 4/11nnnkkk 5 3: a4 eb 440 6 nulls: 84 441 Compressed: 442 04 85 00 90 65 a3 dc 02 02 ac a4 eb 84 443 Was 24 bytes; compressed to 13 bytes, compression factor 1.85 445 Figure 8 447 Figure 9 shows the compression of an ND router advertisement. The 448 indefinite lifetime is compressed to four bytes by backreferencing; 449 this could be improved (at the cost of minor additional decompressor 450 complexity) by including some simple runlength mechanism. 452 IP header: 453 60 00 00 00 00 60 3a ff fe 80 00 00 00 00 00 00 454 10 34 00 ff fe 00 11 22 fe 80 00 00 00 00 00 00 455 ae de 48 00 00 00 00 01 456 Payload: 457 86 00 55 c9 40 00 0f a0 1c 5a 38 17 00 00 07 d0 458 01 01 11 22 00 00 00 00 03 04 40 40 ff ff ff ff 459 ff ff ff ff 00 00 00 00 20 02 0d b8 00 00 00 00 460 00 00 00 00 00 00 00 00 20 02 40 10 00 00 03 e8 461 20 02 0d b8 00 00 00 00 21 03 00 01 00 00 00 00 462 20 02 0d b8 00 00 00 00 00 00 00 ff fe 00 11 22 463 Pseudoheader: 464 fe 80 00 00 00 00 00 00 10 34 00 ff fe 00 11 22 465 fe 80 00 00 00 00 00 00 ae de 48 00 00 00 00 01 466 00 00 00 60 00 00 00 3a 467 copy: 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 468 2 nulls: 80 469 copy: 06 07 d0 01 01 11 22 470 4 nulls: 82 471 copy: 06 03 04 40 40 ff ff 472 ref(2): ff ff -> ref 11nnnkkk 0 0: c0 473 ref(4): ff ff ff ff -> ref 11nnnkkk 2 0: d0 474 4 nulls: 82 475 copy: 04 20 02 0d b8 476 12 nulls: 8a 477 copy: 04 20 02 40 10 478 ref(38): 00 00 03 -> ref 101nssss 0 4/11nnnkkk 1 3: a4 cb 479 copy: 01 e8 480 ref(24): 20 02 0d b8 00 00 00 00 481 -> ref 101nssss 0 2/11nnnkkk 6 0: a2 f0 482 copy: 02 21 03 483 ref(84): 00 01 00 00 00 -> ref 101nssss 0 9/11nnnkkk 3 7: a9 df 484 ref(40): 00 20 02 0d b8 00 00 00 00 00 00 00 485 -> ref 101nssss 1 3/11nnnkkk 2 4: b3 d4 486 ref(120): ff fe 00 11 22 487 -> ref 101nssss 0 14/11nnnkkk 3 3: ae db 488 Compressed: 489 0c 86 00 55 c9 40 00 0f a0 1c 5a 38 17 80 06 07 490 d0 01 01 11 22 82 06 03 04 40 40 ff ff c0 d0 82 491 04 20 02 0d b8 8a 04 20 02 40 10 a4 cb 01 e8 a2 492 f0 02 21 03 a9 df b3 d4 ae db 493 Was 96 bytes; compressed to 58 bytes, compression factor 1.66 495 Figure 9: An ND router advertisement 497 4. Integrating 6LoWPAN-GHC into 6LoWPAN-HC 499 6LoWPAN-GHC is intended to plug in as an NHC format for 6LoWPAN-HC 500 [I-D.ietf-6lowpan-hc]. This section shows how this can be done 501 (without supplying the detailed normative text yet, although it could 502 be implemented from this page). 504 GHC is by definition generic and can be applied to different kinds of 505 packets. All the examples given above are for ICMPv6 packets; it is 506 trivial to define an NHC format for ICMPv6 based on GHC. 508 In addition it may be useful to include an NHC format for UDP, as 509 many headerlike payloads (e.g., DHCPv6) are carried in UDP. 510 [I-D.ietf-6lowpan-hc] already defines an NHC format for UDP 511 (11110CPP). What remains to be done is to define an analogous NHC 512 byte formatted, e.g. as shown in Figure 10, and simply reference the 513 existing specification, indicating that for 0b11010cpp NHC bytes, the 514 UDP payload is not supplied literally but compressed by 6LoWPAN-GHC. 516 0 1 2 3 4 5 6 7 517 +---+---+---+---+---+---+---+---+ 518 | 1 | 1 | 0 | 1 | 0 | C | P | 519 +---+---+---+---+---+---+---+---+ 521 Figure 10: A possible NHC byte for UDP GHC 523 To stay in the same general numbering space, we propose 0b11011111 as 524 the NHC byte for ICMPv6 GHC. 526 4.1. Compressing extension headers 528 If the compression of specific extension headers is considered 529 desirable, this can be added in a similar way, e.g. as in Figure 11 530 (however, probably only EID 0 to 3 need to be assigned). As there is 531 no easy way to extract the length field from the GHC-encoded header 532 before decoding, this would make detecting the end of the extension 533 header somewhat complex. The easiest (and most efficient) approach 534 is to completely elide the length field (in the same way NHC already 535 elides the next header field in certain cases) and reconstruct it 536 only on decompression. Instead, the reserved bytecode 0b10010000 537 would be assigned as a stop marker. 539 0 1 2 3 4 5 6 7 540 +---+---+---+---+---+---+---+---+ 541 | 1 | 0 | 1 | 1 | EID |NH | 542 +---+---+---+---+---+---+---+---+ 544 Figure 11: A possible NHC byte for extension header GHC 546 4.2. Indicating GHC capability 548 The 6LoWPAN baseline includes just [RFC4944], [I-D.ietf-6lowpan-hc], 549 [I-D.ietf-6lowpan-nd] (see [I-D.bormann-6lowpan-roadmap]). To enable 550 the use of GHC, 6LoWPAN nodes need to know that their neighbors 551 implement it. While this can simply be administratively required, a 552 transition strategy as well as a way to support mixed networks is 553 required. 555 One way to know a neighbor does implement GHC is receiving a packet 556 from that neighbor with GHC in it ("implicit capability detection"). 557 However, there needs to be a way to bootstrap this, as nobody ever 558 would start sending packets with GHC otherwise. 560 To minimize the impact on [I-D.ietf-6lowpan-nd], we propose adding an 561 ND option 6LoWPAN Capability Indication (6CIO), as illustrated in 562 Figure 12. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Type | Length = 1 |_____________________________|G| 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 |_______________________________________________________________| 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 Figure 12: 6LoWPAN Capability Indication (6CIO) 574 The G bit indicates whether the node sending the option is GHC 575 capable. 577 The 6CIO option will typically only be sent in 6LoWPAN-ND RS packets; 578 the resulting 6LoWPAN-ND RA can already make use of GHC and thus 579 indicate GHC capability implicitly, which in turn allows the nodes to 580 use GHC in the 6LoWPAN-ND NS/NA exchange. 582 6CIO can also be used for future options that need to be negotiated 583 between 6LoWPAN peers; an IANA registry will administrate the flags. 584 (Bits marked by underscores in Figure 12 are reserved for future 585 allocation, i.e., they MUST be sent as zero and MUST be ignored on 586 reception until allocated. Length values larger than 1 MUST be 587 supported for future extensions; the additional bits in the option 588 are then reserved in the same way. For the purposes of the IANA 589 registry, the bits are numbered in msb-first order from the 16th bit 590 of the option onwards, i.e., the G bit is flag number 15.) 592 5. IANA considerations 594 In the IANA registry for the 6LOWPAN_NHC header type, IANA would need 595 to add the assignments in Figure 13. 597 10110IIN: Extension header GHC*) [RFCthis] 598 11010CPP: UDP GHC [RFCthis] 599 11011111: ICMPv6 GHC [RFCthis] 601 Figure 13: IANA assignments for the NHC byte 603 *) if the functionality of Section 4.1 is made part of this document. 605 An IANA registry is needed for 6LoWPAN capability flags. (Policy 606 TBD.) 608 IANA needs to allocate an ND option number for 6CIO. 610 6. Security considerations 612 The security considerations of [RFC4944] and [I-D.ietf-6lowpan-hc] 613 apply. As usual in protocols with packet parsing/construction, care 614 must be taken in implementations to avoid buffer overflows and in 615 particular (with respect to the back-referencing) out-of-area 616 references during decompression. 618 One additional consideration is that an attacker may send a forged 619 packet that makes a second node believe a third victim node is GHC- 620 capable. If it is not, this may prevent packets sent by the second 621 node from reaching the third node. 623 No mitigation is proposed (or known) for this attack, except that a 624 node that does implement GHC is not vulnerable. However, with 625 unsecured ND, a number of attacks with similar outcomes are already 626 possible, so there is little incentive to make use of this additional 627 attack. With secured ND, 6CIO is also secured; nodes relying on 628 secured ND therefore should use 6CIO bidirectionally (and limit the 629 implicit capability detection to secured ND packets carrying GHC) 630 instead of basing their neighbor capability assumptions on receiving 631 any kind of unprotected packet. 633 7. Acknowledgements 635 Colin O'Flynn has repeatedly insisted that some form of compression 636 for ICMPv6 and ND packets might be beneficial. He actually wrote his 637 own draft, [I-D.oflynn-6lowpan-icmphc], which compresses better, but 638 addresses basic ICMPv6/ND only and needs a much longer spec (around 639 17 pages of detailed spec, as compared to the single page of core 640 spec here). This motivated the author to try something simple, yet 641 general. Special thanks go to Colin for indicating that he indeed 642 considers his draft superseded by the present one. 644 The examples given are based on pcap files that Colin O'Flynn and 645 Owen Kirby provided. 647 8. References 649 8.1. Normative References 651 [I-D.ietf-6lowpan-hc] 652 Hui, J. and P. Thubert, "Compression Format for IPv6 653 Datagrams in Low Power and Lossy Networks (6LoWPAN)", 654 draft-ietf-6lowpan-hc-15 (work in progress), 655 February 2011. 657 [I-D.ietf-6lowpan-nd] 658 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 659 Discovery Optimization for Low-power and Lossy Networks", 660 draft-ietf-6lowpan-nd-15 (work in progress), 661 December 2010. 663 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 664 Requirement Levels", BCP 14, RFC 2119, March 1997. 666 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 667 (IPv6) Specification", RFC 2460, December 1998. 669 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 670 "Transmission of IPv6 Packets over IEEE 802.15.4 671 Networks", RFC 4944, September 2007. 673 8.2. Informative References 675 [I-D.bormann-6lowpan-roadmap] 676 Bormann, C., "6LoWPAN Roadmap and Implementation Guide", 677 draft-bormann-6lowpan-roadmap-00 (work in progress), 678 March 2011. 680 [I-D.ietf-core-link-format] 681 Shelby, Z., "CoRE Link Format", 682 draft-ietf-core-link-format-02 (work in progress), 683 December 2010. 685 [I-D.oflynn-6lowpan-icmphc] 686 O'Flynn, C., "ICMPv6/ND Compression for 6LoWPAN Networks", 687 draft-oflynn-6lowpan-icmphc-00 (work in progress), 688 July 2010. 690 [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification 691 version 1.3", RFC 1951, May 1996. 693 [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., 694 Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, 695 K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., 696 Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header 697 Compression (ROHC): Framework and four profiles: RTP, UDP, 698 ESP, and uncompressed", RFC 3095, July 2001. 700 [RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, "The RObust 701 Header Compression (ROHC) Framework", RFC 5795, 702 March 2010. 704 Author's Address 706 Carsten Bormann 707 Universitaet Bremen TZI 708 Postfach 330440 709 Bremen D-28359 710 Germany 712 Phone: +49-421-218-63921 713 Fax: +49-421-218-7000 714 Email: cabo@tzi.org