idnits 2.17.1 draft-ietf-6lowpan-hc-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4944, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC4944, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 5, 2009) is 5314 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) == Unused Reference: 'RFC4007' is defined on line 810, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 814, but no explicit reference was found in the text == Unused Reference: 'RFC4302' is defined on line 817, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 820, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hui, Ed. 3 Internet-Draft Arch Rock Corporation 4 Updates: 4944 (if approved) P. Thubert 5 Intended status: Standards Track Cisco 6 Expires: April 8, 2010 October 5, 2009 8 Compression Format for IPv6 Datagrams in 6LoWPAN Networks 9 draft-ietf-6lowpan-hc-06 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 8, 2010. 34 Copyright Notice 36 Copyright (c) 2009 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document specifies an IPv6 header compression format for IPv6 48 packet delivery in 6LoWPAN networks. The compression format relies 49 on shared context to allow compression of arbitrary prefixes. How 50 the information is maintained in that shared context is out of scope. 51 This document specifies compression of multicast addresses and a 52 framework for compressing next headers. This framework specifies UDP 53 compression. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2. Specific Updates to RFC 4944 . . . . . . . . . . . . . . . . . 4 60 3. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 5 61 3.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 62 3.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 6 63 3.1.2. Context Identifier Extension . . . . . . . . . . . . . 8 64 3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 9 65 3.2.1. Traffic Class and Flow Label Compression . . . . . . . 9 66 3.2.2. Stateless Multicast Addresses Compression . . . . . . 10 67 3.2.3. Stateful Multicast Addresses Compression . . . . . . . 11 68 4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 12 69 4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 12 70 4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 12 71 4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 14 72 4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 14 73 4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 15 74 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 15 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 78 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding 87 about 80 octets of actual MAC payload with security enabled, on a 88 wireless link with a link throughput of 250 kbps or less. The 89 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 90 datagrams over such constrained links, taking into account limited 91 bandwidth, memory, or energy resources that are expected in 92 applications such as wireless sensor networks. [RFC4944] defines a 93 Mesh Addressing header to support sub-IP forwarding, a Fragmentation 94 header to support the IPv6 minimum MTU requirement [RFC2460], and 95 stateless header compression for IPv6 datagrams (LOWPAN_HC1 and 96 LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down 97 to (in the best case) several bytes. 99 LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of 100 6LoWPAN networks. LOWPAN_HC1 is most effective for link-local 101 unicast communication, where IPv6 addresses carry the link-local 102 prefix and an Interface Identifier (IID) directly derived from IEEE 103 802.15.4 addresses. In this case, both addresses may be completely 104 elided. However, though link-local addresses are commonly used for 105 local protocol interactions such as IPv6 ND [RFC4861], DHCPv6 106 [RFC3315] or routing protocols, they are usually not used for 107 application-layer data traffic, so the actual value of this 108 compression mechanism is limited. 110 Routable addresses must be used when communicating with devices 111 external to the LoWPAN or in a route-over configuration where IP 112 forwarding occurs within the LoWPAN. For routable addresses, 113 LOWPAN_HC1 requires both IPv6 source and destination addresses to 114 carry the prefix in-line. In cases where the Mesh Addressing header 115 is not used, the IID of a routable address must be carried in-line. 116 However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line 117 and cannot be shortened even when it is derived from the IEEE 118 802.15.4 16-bit short address. When the destination is an IPv6 119 multicast address, LOWPAN_HC1 requires the full 128-bit address to be 120 carried in-line. 122 As a result, this document defines an encoding format, LOWPAN_IPHC, 123 for effective compression of Unique Local, Global, and multicast IPv6 124 Addresses based on shared state within contexts. In addition, this 125 document also introduces a number of additional improvements over the 126 header compression format defined in [RFC4944]. 128 LOWPAN_IPHC allows for compression of some commonly-used IPv6 Hop 129 Limit values. If the LoWPAN is a mesh-under stub, a Hop Limit of 1 130 for inbound and a default value such as 64 for outbound are usually 131 enough for application layer data traffic. Additionally, a hop-limit 132 value of 255 is often used for verify that a communication occurs 133 over a single-hop. This specification enables to compress the IPv6 134 Hop Limit field in those common cases, whereas LOWPAN_HC1 does not. 136 This document also defines LOWPAN_NHC, an encoding format for 137 arbitrary next headers. LOWPAN_IPHC indicates whether the following 138 header is encoded using LOWPAN_NHC. If so, the bits immediately 139 following the compressed IPv6 header start the LOWPAN_NHC encoding. 140 In contrast, LOWPAN_HC1 could be extended to support compression of 141 next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6. 142 Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet 143 and uncompressed IPv6 header fields. This specification moves the 144 next header encoding bits to follow all IPv6-related bits, allowing 145 for a properly layered structure and direct support for IPv6 146 extension headers. 148 Using LOWPAN_NHC, this document defines a compression mechanism for 149 UDP. While [RFC4944] defines a compression mechanism for UDP, that 150 mechanism does not enable checksum compression when rendered possible 151 by additional upper layer mechanisms such as upper layer Message 152 Integrity Check (MIC). This specification adds the capability to 153 elide the UDP checksum over the LoWPAN, which enables to save an 154 additional pair of octets. 156 Also using LOWPAN_NHC, this document defines encoding formats for 157 IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With 158 LOWPAN_HC1 and LOWPAN_HC2, chains of next headers can not be encoded 159 efficiently. 161 1.1. Requirements Language 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 2. Specific Updates to RFC 4944 169 This document specifies a header compression format that is intended 170 to replace that defined in Section 10 of [RFC4944]. Implementation 171 of Section 10 of [RFC4944] is now NOT RECOMMENDED. New 172 implementations MAY implement Section 10 decompression, but SHOULD 173 NOT send section-10-compressed packets. 175 The header compression format defined in this document preempts the 176 ESC dispatch value defined in Section 5.1 of [RFC4944]. Instead, the 177 value of 01 000000 is is reserved as a replacement value for ESC, to 178 be finally assigned with the first assignment of extension bytes. 180 3. IPv6 Header Compression 182 In this section, we define the LOWPAN_IPHC encoding format for 183 compressing the IPv6 header. To enable effective compression 184 LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN 185 network. LOWPAN_IPHC assumes the following will be the common case 186 for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label 187 are both zero; Payload Length can be inferred from lower layers from 188 either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; 189 Hop Limit will be set to a well-known value by the source; addresses 190 assigned to 6LoWPAN interfaces will be formed using the link-local 191 prefix or a single routable prefix assigned to the entire 6LoWPAN 192 network; addresses assigned to 6LoWPAN interfaces are formed with an 193 IID derived directly from either the 64-bit extended or 16-bit short 194 IEEE 802.15.4 addresses. 196 +-------------------------------------+------------------------ 197 | Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header 198 +-------------------------------------+------------------------ 200 Figure 1: LOWPAN_IPHC Header 202 The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from 203 the rightmost bit of the dispatch type. The encoding may be extended 204 by another octet to support additional contexts. Uncompressed IPv6 205 header fields follow the LOWPAN_IPHC encoding, as shown in Figure 1. 206 With the above scenario, the LOWPAN_IPHC can compress the IPv6 header 207 down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) 208 with link-local communication. 210 When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 211 header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC, 212 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination 213 Address). The Hop Limit may not be compressed because it needs to 214 decremented at each hop and may take any value. Stateful address 215 compression must be applied to the source and destination IPv6 216 addresses because they do not statelessly match the source and 217 destination link layer addresses on intermediate hops. 219 3.1. LOWPAN_IPHC Encoding Format 221 This section specifies the format of the LOWPAN_IPHC encoding that 222 describes how an IPv6 header is compressed. The encoding can be 2 223 octets long for the base encoding or 3 octets long when an additional 224 context encoding is present. The IPv6 header fields that are not 225 fully elided are placed immediately after the LOWPAN_IPHC, either in 226 a compressed form if the field is partially elided, or litteraly. 228 3.1.1. Base Format 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 231 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 232 | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | 233 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 235 Figure 2: LOWPAN_IPHC base Encoding 237 TF: Traffic Class, Flow Label: 238 00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes) 239 01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided 240 10: ECN + DSCP (1 byte), Flow Label is elided 241 11: Traffic Class and Flow Label are elided. 243 NH: Next Header: 244 0: Full 8 bits for Next Header are carried in-line. 245 1: The Next Header field is compressed and the next header is 246 encoded using LOWPAN_NHC, which is discussed in Section 4. 248 HLIM: Hop Limit: 249 00: The Hop Limit field is carried in-line. 250 01: The Hop Limit field is compressed and the the hop limit is 1. 251 10: The Hop Limit field is compressed and the the hop limit is 252 64. 253 11: The Hop Limit field is compressed and the hop limit is 255. 255 CID: Context Identifier Extension: 256 0: No additional 8-bit Context Identifier Extension is used. If 257 context-based compression is specified in either SAC or DAC, 258 context 0 is used. 259 1: An additional 8-bit Context Identifier Extension field 260 immediately follows the DAM field. 262 SAC: Source Address Compression 263 0: Source address compression uses stateless compression. 264 1: Source address compression uses stateful, context-based 265 compression. 267 SAM: Source Address Mode: 269 If SAC=0: 270 00: 128 bits. The full address is carried in-line. 271 01: 64 bits. The first 64-bits of the address are elided. 272 The value of those bits is the link-local prefix padded with 273 zeros. The remaining 64 bits are carried inline. 274 10: 16 bits. The first 112 bits of the address are elided. 275 The value of those bits is the link-local prefix padded with 276 zeros. The remaining 16 bits are carried inline. 277 11: 0 bits. The address is fully elided. The first 64 bits 278 of the address are the link-local prefix padded with zeros. 279 The remaining 64 bits are computed from the link-layer 280 address as defined in [RFC4944]. 281 If SAC=1: 282 00: The UNSPECIFIED address, :: 283 01: 64 bits. The address is derived using context information 284 and the 64 bits carried inline. 285 10: 16 bits. The address is derived using context information 286 and the 16 bits carried inline. 287 11: 0 bits. The address is derived using context information 288 and possibly the link-layer addresses. 290 M: Multicast Compression 291 0: Destination address is not a multicast address. 292 1: Destination address is a multicast address. 294 DAC: Destination Address Compression 295 0: Destination address compression uses stateless compression. 296 1: Destination address compression uses stateful, context-based 297 compression. 299 DAM: Destination Address Mode: 300 If M=0 and DAC=0 This case matches SAC=0 but for the destination 301 address: 302 00: 128 bits. The full address is carried in-line. 303 01: 64 bits. The first 64-bits of the address are elided. 304 The value of those bits is the link-local prefix padded with 305 zeros. The remaining 64 bits are carried inline. 306 10: 16 bits. The first 112 bits of the address are elided. 307 The value of those bits is the link-local prefix padded with 308 zeros. The remaining 16 bits are carried inline. 309 11: 0 bits. The address is fully elided. The first 64 bits 310 of the address are the link-local prefix padded with zeros. 311 The remaining 64 bits are computed from the link-layer 312 address as defined in [RFC4944]. 314 If M=0 and DAC=1: 315 00: Reserved. 316 01: 64 bits. The address is derived using context information 317 and the 64 bits carried inline. 318 10: 16 bits. The address is derived using context information 319 and the 16 bits carried inline. 320 11: 0 bits. The address is derived using context information 321 and possibly the link-layer addresses. 322 If M=1 and DAC=0: 323 00: 128 bits. The full address is carried in-line. 324 01: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX. 325 10: 32 bits. The address takes the form FFXX::00XX:XXXX. 326 11: 8 bits. The address takes the form FF02::00XX. 327 If M=1 and DAC=1: 328 00: 48 bits. This format is designed to match Unicast-Prefix- 329 based IPv6 Multicast Addresses as defined in [RFC3306] and 330 [RFC3956]. The multicast address takes the form FFXX:XXLL: 331 PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles 332 that are carried inline, in the order in which they appear 333 in this format. P denotes nibbles used to encode the prefix 334 itself. L denotes nibbles used to encode the prefix length. 335 The prefix information P and L is taken from the specified 336 context. 337 01: reserved 338 10: reserved 339 11: reserved 341 3.1.2. Context Identifier Extension 343 This specification expects that a conceptual context is shared 344 between the node that compresses a packet and the node(s) that need 345 to expand it. How the contexts are shared and maintained is out of 346 scope. What information is contained within a context information is 347 out of scope. Actions in response to unknown and/or invalid contexts 348 are out of scope. The specification enables a node to use up to 16 349 contexts. The context used to encode the source address does not 350 have to be the same as the context used to encode the destination 351 address. 353 If the CID field is set to '1' in the LOWPAN_IPHC encoding, then an 354 additional octet extends the LOWPAN_IPHC encoding following the DAM 355 bits but before the IPv6 header fields that are carried in-line. The 356 additional octet identifies the pair of contexts to be used when the 357 IPv6 source and/or destination address is compressed. The context 358 identifier is 4 bits for each address, supporting up to 16 contexts. 359 Context 0 is the default context. The encoding is shown in Figure 3. 361 0 1 2 3 4 5 6 7 362 +---+---+---+---+---+---+---+---+ 363 | SCI | DCI | 364 +---+---+---+---+---+---+---+---+ 366 Figure 3: LOWPAN_IPHC Encoding 368 SCI: Source Context Identifier Identifies the prefix that is used 369 when the IPv6 source address is statefully compressed. 370 DCI: Destination Context Identifier Identifies the prefix that is 371 used when the IPv6 destination address is statefully compressed. 373 3.2. IPv6 Header Encoding 375 Fields carried in-line (in part or in whole) appear in the same order 376 as they do in the IPv6 header format [RFC2460]. The Version field is 377 always elided. Unicast IPv6 addresses may be compressed to 64 or 16 378 bits or completely elided. Multicast IPv6 addresses may be 379 compressed to 8, 32, or 48 bits. The IPv6 Payload Length field MUST 380 always be elided and inferred from lower layers using the 6LoWPAN 381 Fragmentation header or the IEEE 802.15.4 header. 383 3.2.1. Traffic Class and Flow Label Compression 385 The Traffic Class field in the IPv6 header comprises 6 bits of 386 diffserv extension [RFC2474] and 2 bits of Explicit Congestion 387 Notification (ECN) [RFC3168]. If the ECN information is carried by 388 the Lower Layers in a compatible fashion then it can be elided from 389 the 6LoWPAN header. Otherwise, it has to be transported in one of 390 the following encodings. 392 The TF field in the LOWPAN_IPHC encoding indicates whether the 393 Traffic Class and Flow Label are carried in-line in the compressed 394 IPv6 header. When Flow Label is included while the Traffic Class is 395 compressed, an additional 4 bits are included to maintain byte- 396 alignment. Two of the 4 bits contain the ECN bits from the Traffic 397 Class field. 399 To ensure that the ECN bits appear in the same location for all 400 encodings that include them, the Traffic Class field is rotated right 401 by 2 bits in the compressed IPv6 header. The encodings are shown 402 below: 404 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |ECN| DSCP | rsv | Flow Label | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 TF = 00: Traffic Class and Flow Label carried in-line. 412 1 2 413 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 |ECN|rsv| Flow Label | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 TF = 01: Flow Label carried in-line. 420 0 1 2 3 4 5 6 7 421 +-+-+-+-+-+-+-+-+ 422 |ECN| DSCP | 423 +-+-+-+-+-+-+-+-+ 425 TF = 10: Traffic Class carried in-line. 427 3.2.2. Stateless Multicast Addresses Compression 429 LOWPAN_IPHC supports stateless compression of multicast address when 430 M = 1 and DAC = 0. An IPv6 multicast address may be compressed down 431 to 48, 32, or 8 bits using stateless compression. The format 432 supports compression of the Solicited-Node Multicast Address (FF02:: 433 1:FFXX:XXXX) as well as any IPv6 multicast address where the upper 434 bits of the multicast group identifier are zero. The compressed 435 forms only carry the least-significant bits of the multicast group 436 identifier. The 48 and 32-bit compressed forms carry the multicast 437 scope and flags in-line. 439 1 2 3 440 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 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | Flags | Scope | Group Identifier | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Group Identifier | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 DAM = 01. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg) 449 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Flags | Scope | Group Identifier | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 DAM = 10. 32-bit Compressed Multicast Address (FFfs:00gg:gggg). 457 0 1 2 3 4 5 6 7 458 +-+-+-+-+-+-+-+-+ 459 | Group ID | 460 +-+-+-+-+-+-+-+-+ 462 DAM = 11. 8-bit Compressed Multicast Address (FF02::gg). 464 3.2.3. Stateful Multicast Addresses Compression 466 LOWPAN_IPHC supports stateful compression of multicast addresses when 467 M = 1 and DAC = 1. This document currently defines DAM = 00: 468 context-based compression of Unicast-Prefix-based IPv6 Multicast 469 Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and 470 Network Prefix can be taken from a context. As a result, LOWPAN_IPHC 471 can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 472 octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and 473 32-bit Group Identifier in-line. 475 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Flags | Scope | Rsvd / RIID | Group Identifier | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Group Identifier | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression 485 Note that the Reserved field MUST carry the reserved bits from the 486 multicast address format as described in [RFC3306]. When a 487 Rendezvous Point is encoded in the multicast address as described in 488 [RFC3956], the Reserved field carries the RIID bits in-line. 490 4. IPv6 Next Header Compression 492 LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set 493 to 1. It also indicates the use of 6LoWPAN next header compression, 494 LOWPAN_NHC. The value of IPv6 Next Header is recovered from the 495 first bits in the LOWPAN_NHC encoding. The following bits are 496 specific to the IPv6 Next Header value. Figure 4 shows the structure 497 of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. 499 +-------------+-------------+-------------+-----------------+-------- 500 | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload 501 | Encoding | IP Fields | Encoding | Header Fields | 502 +-------------+-------------+-------------+-----------------+-------- 504 Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration 506 4.1. LOWPAN_NHC Format 508 Compression formats for different next headers are identified by a 509 variable-length bit-pattern immediately following the LOWPAN_IPHC 510 compressed header. When defining a next header compression format, 511 the number of bits used SHOULD be determined by the perceived 512 frequency of using that format. However, the number of bits and any 513 remaining encoding bits SHOULD respect octet alignment. The 514 following bits are specific to the next header compression format. 515 This document defines a compression format for IPv6 Extension and UDP 516 headers. 518 +----------------+--------------------------- 519 | var-len NHC ID | compressed next header... 520 +----------------+--------------------------- 522 Figure 5: LOWPAN_NHC Encoding 524 4.2. IPv6 Extension Header Compression 526 A necessary property of encoding headers using LOWPAN_NHC is that the 527 immediately preceding header must either be encoded using LOWPAN_IPHC 528 or LOWPAN_NHC. In other words, all headers encoded using the 6LoWPAN 529 encoding format defined in this document must be contiguous. As a 530 result, this document defines a set of LOWPAN_NHC encodings for 531 selected IPv6 Extension Headers such that the UDP Header Compression 532 defined in Section 4.3 may be used in the presence of those extension 533 headers. 535 The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a 536 single LOWPAN_NHC octet followed by the IPv6 Extension Header. The 537 format of the LOWPAN_NHC octet is shown in Figure 6. The first 7 538 bits serve as an identifier for the IPv6 Extension Header immediately 539 following the LOWPAN_NHC octet. The remaining bit indicates whether 540 or not the following header utilizes LOWPAN_NHC encoding. 542 0 1 2 3 4 5 6 7 543 +---+---+---+---+---+---+---+---+ 544 | 1 | 1 | 1 | 0 | EID |NH | 545 +---+---+---+---+---+---+---+---+ 547 Figure 6: IPv6 Extension Header Encoding 549 EID: IPv6 Extension Header ID: 550 0: IPv6 Hop-by-Hop Options Header[RFC2460] 551 1: IPv6 Routing Header[RFC2460] 552 2: IPv6 Fragment Header[RFC2460] 553 3: IPv6 Destination Options Header[RFC2460] 554 4: IPv6 Mobility Header [RFC3775] 555 5: Reserved 556 6: Reserved 557 7: IPv6 Header 559 NH: Next Header: 560 0: Full 8 bits for Next Header are carried in-line. 561 1: The Next Header field is elided and the next header is encoded 562 using LOWPAN_NHC, which is discussed in Section 4. 564 For the most part, the IPv6 Extension Header is carried verbatim in 565 the bytes immediately following the LOWPAN_NHC octet, with two 566 important exceptions: Length Field and Next Header Field. 568 The Next Header Field contained in IPv6 Extension Headers is elided 569 when the NH bit is set in the LOWPAN_NHC encoding octet. Note that 570 doing so allows LOWPAN_NHC to utilize no more overhead than the non- 571 encoded IPv6 Extension Header. 573 The Length Field contained in IPv6 Extension Headers indicate the 574 length of the IPv6 Extension Header in octets, not including the 575 LOWPAN_NHC byte. Note that this changes the Length Field definition 576 in [RFC2460] from indicating the header size in 8-octet units, not 577 including the first 8 octets. Changing the Length Field to be in 578 units of octets removes wasteful internal fragmentation. However, 579 specifying units in octets also means that LOWPAN_NHC CANNOT be used 580 to encode IPv6 Extension Headers that exceed 255 octets. 582 IPv6 Hop-by-Hop and Destination Options Headers may use Pad1 and PadN 583 to pad out the header for octet-alignment purposes. When using 584 LOWPAN_NHC, those Pad1 and PadN options MAY be elided and the length 585 of the header reduced by the size of those Pad1 and PadN options. 586 When converting from the LOWPAN_NHC encoding back to the standard 587 IPv6 encoding, Pad1 and PadN options MUST be used to pad out the 588 containing header to a multiple of 8 octets in length if necessary. 589 Note that Pad1 and PadN options that do not appear at the end of the 590 containing header MUST be carried in-line as they are used to align 591 subsequent options. 593 When the identified next header is an IPv6 Header (EID=7), the NH bit 594 of the LOWPAN_NHC encoding is unused and SHOULD be set to zero. The 595 bytes following follow the LOWPAN_IPHC encoding as defined in 596 Section 3. 598 4.3. UDP Header Compression 600 This document defines a compression format for UDP headers using 601 LOWPAN_NHC. The UDP compression format is shown in Figure 7. Bits 0 602 through 4 represent the NHC ID and '11110' indicates the specific UDP 603 header compression encoding defined in this section. 605 4.3.1. Compressing UDP ports 607 This specification introduces a range of well-known ports (0xF0Bx) 608 that can be compressed to 4 bits. Considering that this represents 609 only 16 contiguous ports, it can be expected that many incompatible 610 applications will use the same port numbers of their own end-to-end 611 needs. 613 The overloading of the 0xF0Bx ports increases the risk of getting the 614 wrong type of payload and misinterpreting the content compared to 615 ports that reserved at IANA. It is thus recommended that the use of 616 those ports be associated with a mechanism such as a Transport Layer 617 Security (TLS) Message Integrity Check (MIC) that validates that the 618 content is expected and checked for integrity. 620 4.3.2. Compressing UDP checksum 622 The UDP checksum operation is mandatory with IPv6 [RFC2460] for all 623 packets. For that reason [RFC4944] disallows the compression of the 624 UDP checksum. 626 With this specification, a compressor in the source transport 627 endpoint MAY elide the UDP checksum if it is authorized by the Upper 628 Layer. The compressor SHOULD NOT set the C bit unless it has 629 received such authorization. The Upper Layer SHOULD only provide the 630 authorization in the following cases: 632 Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo- 633 fieldbus by tunneling existing field protocols over UDP. If the 634 tunneled PDU possesses its own addressing, security and integrity 635 check, the tunneling mechanism MAY authorize to elide the UDP 636 checksum in order to save on the encapsulation overhead. 637 Upper Layer Message Integrity Check: In this case, there is some 638 other form of integrity check in the UDP payload that covers at 639 least the same information as the UDP checksum (pseudo-header, 640 data) and has at least the same strength. 642 A forwarding node MAY imply authorization from an incoming packet if 643 the C bit is set. A forwarding node that cannot unambiguously derive 644 such authorization SHOULD NOT elide the UDP checksum when performing 645 6LoWPAN compression. The forwarding node that expands a 6LoWPAN 646 packet with the C bit on MUST compute the UDP checksum on behalf of 647 the source node and place that checksum in the restored UDP header as 648 specified in the incumbent standards [RFC0768], [RFC2460]. 650 If a 6LoWPAN termination is also the transport endpoint and it 651 receives a compressed packet with the C bit set, then it is entitled 652 to ignore the UDP checksum process completely. If the C bit is not 653 set, the packet might have been forwarded by an edge router, so this 654 is not an indication that the MIC is not present. If the terminating 655 node knows that the message integrity will be validated by the upper 656 layer by some state associated to the Service Access Point, it is 657 entitled to ignore the checksum operation as if the C bit was set. 659 4.3.3. UDP LOWPAN_NHC Format 661 0 1 2 3 4 5 6 7 662 +---+---+---+---+---+---+---+---+ 663 | 1 | 1 | 1 | 1 | 0 | C | P | 664 +---+---+---+---+---+---+---+---+ 665 Figure 7: UDP Header Encoding 667 C: Checksum: 668 0: All 16 bits of Checksum are carried in-line. 669 1: All 16 bits of Checksum are elided. The Checksum is recovered 670 by recomputing it on the 6LoWPAN termination point. 672 P: Ports: 673 00: All 16 bits for both Source Port and Destination Port are 674 carried in-line. 675 01: All 16 bits for Source Port are carried in-line. First 8 676 bits of Destination Port is 0xF0 and elided. The remaining 8 677 bits of Destination Port are carried in-line. 678 10: First 8 bits of Source Port are 0xF0 and elided. The 679 remaining 8 bits of Source Port are carried in-line. All 16 680 bits for Destination Port are carried in-line. 681 11: First 12 bits of both Source Port and Destination Port are 682 0xF0B and elided. The remaining 4 bits for each are carried 683 in-line. 685 Fields carried in-line (in part or in whole) appear in the same order 686 as they do in the UDP header format [RFC0768]. The UDP Length field 687 MUST always be elided and is inferred from lower layers using the 688 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 690 5. IANA Considerations 692 This document defines a new IPv6 header compression format for 693 6LoWPAN networks. The document allocates the following 32 Dispatch 694 type field values for LOWPAN_IPHC: 696 01 100000 697 through 698 01 111111 700 This assignment preempts the assignment of 01 111111 for ESC 701 [RFC4944], which is possible as no extension bytes have been 702 allocated yet that would enable the use of ESC. Instead, the value: 704 01 000000 706 is reserved as a replacement value for ESC, to be finally assigned 707 with the first assignment of extension bytes. 709 6. Security Considerations 711 The definition of LOWPAN_IPHC permits the compression of header 712 information on communication that could take place in its absence, 713 albeit in a less efficient form. It recognizes that a IEEE 802.15.4 714 PAN may have associated with it a number of prefixes through shared 715 context. How the shared context is assigned and managed is beyond 716 the scope of this document. 718 The overloading of the 0xF0Bx ports increases the risk of getting the 719 wrong type of payload and misinterpreting the content compared to 720 ports that reserved at IANA. It is thus recommended that the use of 721 those ports be associated with a mechanism such as a Transport Layer 722 Security (TLS) Message Integrity Check (MIC) that validates that the 723 content is expected and checked for integrity. 725 7. Acknowledgements 727 Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, Erik 728 Nordmark, Robert Assimiti, Shoishi Sakane, Zach Shelby, Stephen 729 Dawson-Haggerty, Jay Werb and Mathilde Durvy for useful design 730 consideration and implementation feedback. 732 8. Changes 734 Draft 06: 735 - Reworked introduction. 736 - Fixed description of number of bits used for IPHC encoding. 737 - Specify M=0 only for non-multicast addresses and M=1 only for 738 multicast addresses. 739 - Move 128-bit multicast encoding to DAC=0. 740 - Redefined ESC dispatch value to 01 000000. 741 - Many detailed edits. 743 Draft 05: 744 - Added LOWPAN_NHC encodings for IPv6 Extension Headers. 745 - Specify use of context 0 when CID is 0. 746 - Indicate that first 64-bits is link-local prefix padded with 747 zeros when link-local prefix is elided. 748 - Made prefix-based multicast encoding format more explicit for 749 clarity. 750 - Changed wording around stateful compression to allow for using 751 the inline bits as an additional index to identify the compressed 752 address. 754 - Removed support for compressing unspecified address. 755 - Full 128-bit addr inline only in stateless encoding. 757 Draft 04: 758 - Fixed typos leftover from the changes in 03. 759 - Gave more details on UDP checksum compression. 760 - Clarify that the context information is out of scope. 761 - Added security concern on 0xF0Bx port overloading. 763 Draft 03: 764 - Decoupled meaning of SAM bits from the destination address. 765 - Have separate bit to indicate multicast address compression. 766 - More extensive support for multicast address compression, 767 including Unicast-Prefix-based Multicast Addresses. 769 Draft 02: 770 - Updated wording with compression mode to clarify that a 771 compression mode does not enforce what kind of destination address 772 is being used. Specifically changed Destination Dependent Field 773 to Compression Mode. 774 - Specify that the configuration and management of contexts is out 775 of scope of this document. 777 Draft 01: 778 - HC back to 1 byte by default by stealing a few bits from the 779 dispatch field. 780 - Added better support for multicast address compression. 781 - Fixed alignment for UDP port compression. 782 - Better support for Traffic Class and Flow Label compression. 783 - Pascal joined as an author. 785 9. References 787 9.1. Normative References 789 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 790 August 1980. 792 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 793 Requirement Levels", BCP 14, RFC 2119, March 1997. 795 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 796 (IPv6) Specification", RFC 2460, December 1998. 798 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 799 "Definition of the Differentiated Services Field (DS 800 Field) in the IPv4 and IPv6 Headers", RFC 2474, 801 December 1998. 803 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 804 of Explicit Congestion Notification (ECN) to IP", 805 RFC 3168, September 2001. 807 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 808 in IPv6", RFC 3775, June 2004. 810 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 811 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 812 March 2005. 814 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 815 Architecture", RFC 4291, February 2006. 817 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 818 December 2005. 820 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 821 RFC 4303, December 2005. 823 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 824 "Transmission of IPv6 Packets over IEEE 802.15.4 825 Networks", RFC 4944, September 2007. 827 9.2. Informative References 829 [IEEE 802.15.4] 830 IEEE Computer Society, "IEEE Std. 802.15.4-2006", 831 October 2006. 833 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 834 Multicast Addresses", RFC 3306, August 2002. 836 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 837 and M. Carney, "Dynamic Host Configuration Protocol for 838 IPv6 (DHCPv6)", RFC 3315, July 2003. 840 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 841 Point (RP) Address in an IPv6 Multicast Address", 842 RFC 3956, November 2004. 844 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 845 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 846 September 2007. 848 Authors' Addresses 850 Jonathan W. Hui (editor) 851 Arch Rock Corporation 852 501 2nd St. Ste. 410 853 San Francisco, California 94107 854 USA 856 Phone: +415 692 0828 857 Email: jhui@archrock.com 859 Pascal Thubert 860 Cisco Systems 861 Village d'Entreprises Green Side 862 400, Avenue de Roumanille 863 Batiment T3 864 Biot - Sophia Antipolis 06410 865 FRANCE 867 Phone: +33 4 97 23 26 34 868 Email: pthubert@cisco.com