idnits 2.17.1 draft-ietf-6lowpan-hc-05.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 (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 (June 30, 2009) is 5411 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 763, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC4302' is defined on line 770, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 773, 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 (~~), 5 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: January 1, 2010 June 30, 2009 8 Compression Format for IPv6 Datagrams in 6LoWPAN Networks 9 draft-ietf-6lowpan-hc-05 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 January 1, 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. The 50 information that is maintained in that shared context is out of 51 scope. This document specifies compression of multicast addresses 52 and a framework for compressing next headers. This framework 53 specifies UDP compression and is prepared for additional transports. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 59 2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4 60 2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 61 2.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5 62 2.1.2. Context Identifier Extension . . . . . . . . . . . . . 8 63 2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8 64 2.2.1. Traffic Class and Flow Label Compression . . . . . . . 8 65 2.2.2. Stateless Multicast Addresses Compression . . . . . . 10 66 2.2.3. Stateful Multicast Addresses Compression . . . . . . . 11 67 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11 68 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 12 69 3.2. IPv6 Extension Header Compression . . . . . . . . . . . . 12 70 3.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 14 71 3.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 14 72 3.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 14 73 3.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 15 74 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 77 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 83 1. Introduction 85 The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding 86 about 80 octets of actual MAC payload once security is turned on, on 87 a wireless link with a link throughput of 250 kbps or less. The 88 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 89 datagrams over such constrained links, taking into account limited 90 bandwidth, memory, or energy resources that are expected in 91 applications such as wireless Sensor Networks. [RFC4944] defines a 92 Mesh Addressing header to support sub-IP forwarding, a Fragmentation 93 header to support the IPv6 minimum MTU requirement [RFC2460], and 94 stateless header compression for IPv6 datagrams (LOWPAN_HC1 and 95 LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down 96 to (in the best case) several bytes. 98 LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of 99 6LoWPAN networks. LOWPAN_HC1 is most effective for link-local 100 unicast communication, where IPv6 addresses carry the link-local 101 prefix and an Interface Identifier (IID) directly derived from IEEE 102 802.15.4 addresses. In this case, both addresses may be completely 103 elided. However, though link local addresses are commonly used for 104 local protocol interactions such as IPv6 ND [RFC4861], DHCPv6 105 [RFC3315] or routing protocols, they are usually not used for 106 application layer data traffic, so the actual value of this 107 compression mechanism is limited. 109 Routable addresses must be used when communicating with devices 110 external to the LoWPAN or in a route-over configuration where IP 111 forwarding occurs within the LoWPAN. For routable addresses, 112 LOWPAN_HC1 requires both IPv6 source and destination addresses to 113 carry the prefix in-line. In cases where the Mesh Addressing header 114 is not used, the IID of a routable address must be carried in-line. 115 However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line 116 and cannot be shortened even when it is derived from the IEEE 117 802.15.4 16-bit short address. 119 When the destination is an IPv6 multicast address, LOWPAN_HC1 120 requires the full 128-bit address to be carried in-line. This 121 specification provides an additional mechanism to compress Unique 122 Local, Global and multicast IPv6 Addresses based on shared states 123 within contexts. It also introduces a number of additional 124 improvements over [RFC4944]. 126 LOWPAN_HC1 cannot elide the IPv6 Hop Limit in the IPv6 header, even 127 though a limited set of values are useful in many practical cases. 128 For instance, if the LoWPAN is a mesh-under stub, a Hop Limit of 1 129 for inbound and a default value such as 64 for outbound are usually 130 enough for application layer data traffic. Compressing that field 131 enables saving one octet per packet. 133 LOWPAN_HC1 can be extended to include a LOWPAN_HC2 octet to support 134 compression of UDP, TCP, or ICMPv6; that LOWPAN_HC2 octet is placed 135 right after the LOWPAN_HC1 octet and before the uncompressed IP 136 fields. This specification moves the transport control octet after 137 the uncompressed IP fields for a more properly layered structure. 139 [RFC4944] defines a compression mechanism for UDP, but that mechanism 140 does not enable checksum compression when rendered possible by 141 additional upper layer mechanisms such as upper layer Message 142 Integrity Check (MIC). This specification adds the capability to 143 compress the UDP checksum over the LoWPAN, which enables to save an 144 additional pair of octets. 146 Finally, LOWPAN_HC1 lacks the flexibility to support the compression 147 of additional transport mechanisms that could be introduced in the 148 future. 150 This document specifies a header compression format for IPv6 151 datagrams. This format improves on the header compression format 152 defined in [RFC4944] by generalizing it to support a broader range of 153 communication paradigms, including both mesh-under and route-over 154 configurations; communication to nodes internal and external to the 155 6LoWPAN network; and multicast communication. This document also 156 defines a flexible framework for compressing arbitrary next headers 157 and defines UDP header compression within this framework. This 158 compression format carries forward the design concepts in RFC 4944 159 [RFC4944], minimizing any state and relying on shared context among 160 all nodes in a 6LoWPAN network. 162 1.1. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 2. IPv6 Header Compression 170 In this section, we define the LOWPAN_IPHC encoding format for 171 compressing the IPv6 header. To enable effective compression 172 LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN 173 network. LOWPAN_IPHC assumes the following will be the common case 174 for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label 175 are both zero; Payload Length can be inferred from lower layers from 176 either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; 177 Hop Limit will be set to a well-known value by the source; addresses 178 assigned to 6LoWPAN interfaces will be formed using the link-local 179 prefix or a single routable prefix assigned to the entire 6LoWPAN 180 network; addresses assigned to 6LoWPAN interfaces are formed with an 181 IID derived directly from either the 64-bit extended or 16-bit short 182 IEEE 802.15.4 addresses. 184 +-------------------------------------+------------------------ 185 | Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header 186 +-------------------------------------+------------------------ 188 Figure 1: LOWPAN_IPHC Header 190 The LOWPAN_IPHC encoding utilizes 11 bits, 3 of which are taken from 191 the rightmost bit of the dispatch type. The encoding may be extended 192 by another octet to support additional contexts. Uncompressed IPv6 193 header fields follow the LOWPAN_IPHC encoding, as shown in Figure 1. 194 With the above scenario, the LOWPAN_IPHC can compress the IPv6 header 195 down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) 196 with link-local communication. When routing over multiple IP hops, 197 LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet 198 dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source 199 Address, and 2-octet Destination Address). 201 2.1. LOWPAN_IPHC Encoding Format 203 2.1.1. Base Format 205 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 206 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 207 | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | 208 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 210 Figure 2: LOWPAN_IPHC Encoding 212 TF: Traffic Class, Flow Label: 213 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) 214 01: ECN + 2-bit Pad + Flow Label (3 bytes) 215 10: Traffic Class (1 byte) 216 11: Version, Traffic Class, and Flow Label are compressed. 218 NH: Next Header: 219 0: Full 8 bits for Next Header are carried in-line. 220 1: The Next Header field is compressed and the next header is 221 compressed using LOWPAN_NHC, which is discussed in Section 3. 223 HLIM: Hop Limit: 224 00: The Hop Limit field is carried in-line. 225 01: The Hop Limit field is elided and the the hop limit is 1. 226 10: The Hop Limit field is elided and the the hop limit is 64. 227 11: The Hop Limit field is elided and the hop limit is 255. 229 CID: Context Identifier Extension: 230 0: No additional 8-bit Context Identifier Extension is used. If 231 context-based compression is specified in either SC or DC, 232 context 0 is used. 233 1: An additional 8-bit Context Identifier Extension field 234 immediately follows the DAM field. 236 SAC: Source Address Compression 237 0: Source address compression uses stateless compression. 238 1: Source address compression uses stateful, context-based 239 compression. 241 SAM: Source Address Mode: 242 If SAC=0: 243 00: 128 bits. The full address is carried in-line. 244 01: 64 bits. The first 64-bits of the address are elided. 245 The value of those bits is the link-local prefix padded with 246 zeros. The remaining 64 bits are carried inline. 247 10: 16 bits. The first 112 bits of the address are elided. 248 The value of those bits is the link-local prefix padded with 249 zeros. The remaining 16 bits are carried inline. 250 11: 0 bits. The address is fully elided. The first 64 bits 251 of the address are the link-local prefix padded with zeros. 252 The remaining 64 bits are computed from the link-layer 253 address as defined in [RFC4944]. 254 If SAC=1: 255 00: Reserved. 256 01: 64 bits. The address is derived using context information 257 and the 64 bits carried inline. 258 10: 16 bits. The address is derived using context information 259 and the 16 bits carried inline. 260 11: 0 bits. The address is derived using context information 261 and possibly link-layer addresses. 263 M: Multicast Compression 264 0: Destination address does not use multicast compression. 265 1: Destination address uses multicast compression. 267 DAC: Destination Address Compression 268 0: Destination address compression uses stateless compression. 269 1: Destination address compression uses stateful, context-based 270 compression. 272 DAM: Destination Address Mode: 273 If M=0: 274 If DAC=0: 275 00: 128 bits. The full address is carried in-line. 276 01: 64 bits. The first 64-bits of the address are elided. 277 The value of those bits is the link-local prefix padded 278 with zeros. The remaining 64 bits are carried inline. 279 10: 16 bits. The first 112 bits of the address are elided. 280 The value of those bits is the link-local prefix padded 281 with zeros. The remaining 16 bits are carried inline. 282 11: 0 bits. The address is fully elided. The first 64 283 bits of the address are the link-local prefix padded with 284 zeros. The remaining 64 bits are computed from the link- 285 layer address as defined in [RFC4944]. 286 If DAC=1: 287 00: Reserved. 288 01: 64 bits. The address is derived using context 289 information and the 64 bits carried inline. 290 10: 16 bits. The address is derived using context 291 information and the 16 bits carried inline. 292 11: 0 bits. The address is derived using context 293 information and possibly link-layer addresses. 294 If M=1 and DAC=0: 295 00: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX. 296 01: 32 bits. The address takes the form FFXX::00XX:XXXX. 297 10: 16 bits. The address takes the form FF0X::0XXX. 298 11: 8 bits. The address takes the form FF02::00XX. 299 If M=1 and DAC=1: 300 00: 128 bits. The full address is carried in-line. 301 01: 48 bits. The address takes the form FFXX::XXLL:PPPP:PPPP: 302 XXXX:XXXX. L denotes nibbles used to encode the prefix 303 length. P denotes nibbles used to encode the prefix itself. 304 The prefix information is taken from the specified context. 305 10: reserved 306 11: reserved 308 2.1.2. Context Identifier Extension 310 This specification expects that a concept of context is shared 311 between the node that compresses a packet and the node(s) that need 312 to expand it. The specification enables a node to use of up to 16 313 contexts. How the contexts are shared and maintained is out of 314 scope. What the context information is is out of scope. Actions in 315 response to unknown and/or invalid contexts are out of scope. 317 If the CIF field is set to '1' in the LOWPAN_IPHC encoding, then an 318 additional octet extends the LOWPAN_IPHC encoding following the DAM 319 bits but before the IPv6 header fields that are carried in-line. The 320 additional octet identifies the prefix when the IPv6 source and/or 321 destination address is compressed. The context identifier is 4 bits 322 for each address, supporting up to 16 contexts. The encoding is 323 shown in Figure 3. 325 0 1 2 3 4 5 6 7 326 +---+---+---+---+---+---+---+---+ 327 | SCI | DCI | 328 +---+---+---+---+---+---+---+---+ 330 Figure 3: LOWPAN_IPHC Encoding 332 SCI: Source Context Identifier Identifies the prefix that is used 333 when the IPv6 source address is compressed. 334 DCI: Destination Context Identifier Identifies the prefix that is 335 used when the IPv6 destination address is compressed. 337 2.2. IPv6 Header Encoding 339 Fields carried in-line (in part or in whole) appear in the same order 340 as they do in the IPv6 header format [RFC2460]. The Version field is 341 always elided. Unicast IPv6 addresses may be compressed to 64 or 16 342 bits or completely elided. Multicast IPv6 addresses may be 343 compressed to 8, 16, or 24 bits. The IPv6 Payload Length field MUST 344 always be elided and inferred from lower layers using the 6LoWPAN 345 Fragmentation header or the IEEE 802.15.4 header. 347 2.2.1. Traffic Class and Flow Label Compression 349 The Traffic Class field in the IPv6 header comprises 6 bits of 350 diffserv extension [RFC2474] and 2 bits of Explicit Congestion 351 Notification (ECN) [RFC3168]. If the ECN information is carried by 352 the Lower Layers in a compatible fashion then it can be elided from 353 the 6LoWPAN header. Otherwise, it has to be transported in one of 354 the following encodings. 356 The TF field in the LOWPAN_IPHC encoding indicate whether the Traffic 357 Class and Flow Label are carried in-line in the compressed IPv6 358 header. When Flow Label is included while the Traffic Class is 359 compressed, an additional 4 bits are included to maintain byte- 360 alignment. Two of the 4 bits contain the ECN bits from the Traffic 361 Class field. 363 To ensure that the ECN bits appear in the same location for all 364 encodings that include them, the Traffic Class field is rotated right 365 by 2 bits in the compressed IPv6 header. The encodings are shown 366 below: 368 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 |ECN| DSCP | rsv | Flow Label | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 TF = 00: Traffic Class and Flow Label carried in-line. 376 1 2 377 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 |ECN|rsv| Flow Label | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 TF = 01: Flow Label carried in-line. 384 0 1 2 3 4 5 6 7 385 +-+-+-+-+-+-+-+-+ 386 |ECN| DSCP | 387 +-+-+-+-+-+-+-+-+ 389 TF = 10: Traffic Class carried in-line. 391 2.2.2. Stateless Multicast Addresses Compression 393 LOWPAN_IPHC supports stateless compression of multicast address when 394 M = 1 and SAC = 0. An IPv6 multicast address may be compressed down 395 to 48, 32, 16, or 8 bits using stateless compression. The format 396 supports compression of the Solicited-Node Multicast Address (FF02:: 397 1:FFXX:XXXX) as well as any IPv6 multicast address where the upper 398 bits of the multicast group identifier are zero. The compressed 399 forms only carry the least-significant bits of the multicast group 400 identifier. All compressed forms carry the multicast scope in-line 401 and all (except DAM=10) carry the multicast flags as well. 403 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Flags | Scope | Group Identifier | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Group Identifier | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 DAM = 00. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg) 413 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Flags | Scope | Group Identifier | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 DAM = 01. 32-bit Compressed Multicast Address (FFfs:00gg:gggg). 421 1 422 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Scope | Group Identifier | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 DAM = 10. 16-bit Compressed Multicast Address (FF0s::0ggg). 429 0 1 2 3 4 5 6 7 430 +-+-+-+-+-+-+-+-+ 431 | Group ID | 432 +-+-+-+-+-+-+-+-+ 434 DAM = 11. 8-bit Compressed Multicast Address (FF02::gg). 436 2.2.3. Stateful Multicast Addresses Compression 438 LOWPAN_IPHC supports stateful compression of multicast addresses when 439 M = 1 and SAC = 1. This document currently defines SAM = 01: 440 context-based compression of Unicast-Prefix-based IPv6 Multicast 441 Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and 442 Network Prefix can be taken from a context. As a result, LOWPAN_IPHC 443 can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 444 octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and 445 32-bit Group Identifier in-line. 447 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Flags | Scope | Reserved | Group Identifier | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Group Identifier | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression 457 Note that the Reserved field MUST carry the reserved bits from the 458 multicast address format as described in [RFC3306]. When a 459 Rendezvous Point is encoded in the multicast address as described in 460 [RFC3956], the Reserved field carries the RIID bits in-line. 462 3. IPv6 Next Header Compression 464 LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set 465 to 1. It also indicates the use of 6LoWPAN next header compression, 466 LOWPAN_NHC. The value of IPv6 Next Header is recovered from the 467 first bits in the LOWPAN_NHC encoding. The following bits are 468 specific to the IPv6 Next Header value. Figure 4 shows the structure 469 of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. 471 +-------------+-------------+-------------+-----------------+-------- 472 | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload 473 | Encoding | IP Fields | Encoding | Header Fields | 474 +-------------+-------------+-------------+-----------------+-------- 476 Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration 478 3.1. LOWPAN_NHC Format 480 Compression formats for different next headers are identified by a 481 variable length bit-pattern immediately following the LOWPAN_IPHC 482 compressed header. When defining a next header compression format, 483 the number of bits used SHOULD be determined by the perceived 484 frequency of using that format. However, the number of bits and any 485 remaining encoding bits SHOULD respect octet alignment. The 486 following bits are specific to the next header compression format. 487 In this document, we define a compression format for UDP headers. 489 +----------------+--------------------------- 490 | var-len NHC ID | compressed next header... 491 +----------------+--------------------------- 493 Figure 5: LOWPAN_NHC Encoding 495 3.2. IPv6 Extension Header Compression 497 A necessary property of encoding headers using LOWPAN_NHC is that the 498 immediately preceding header must either be encoded using LOWPAN_IPHC 499 or LOWPAN_NHC. In other words, all headers compressed using the 500 6LoWPAN header compression format defined in this document must be 501 contiguous. As a result, this document defines a set of LOWPAN_NHC 502 encodings for selected IPv6 Extension Headers such that the UDP 503 Header Compression defined in Section 3.3 may be used in the presence 504 of those extension headers. 506 The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a 507 single LOWPAN_NHC octet followed by the IPv6 Extension Header. The 508 format of the LOWPAN_NHC octet is shown in Figure 6. The first 7 509 bits serve as an identifier for the IPv6 Extension Header immediately 510 following the LOWPAN_NHC octet. The remaining bit indicates whether 511 or not the following header utilizes LOWPAN_NHC encoding. 513 0 1 2 3 4 5 6 7 514 +---+---+---+---+---+---+---+---+ 515 | 1 | 1 | 1 | 0 | EID |NH | 516 +---+---+---+---+---+---+---+---+ 518 Figure 6: IPv6 Extension Header Encoding 520 EID: IPv6 Extension Header ID: 521 0: IPv6 Hop-by-Hop Options [RFC2460] 522 1: IPv6 Routing [RFC2460] 523 2: IPv6 Fragment [RFC2460] 524 3: IPv6 Destination Options [RFC2460] 525 4: IPv6 Mobility Header [RFC3775] 526 5: Reserved 527 6: Reserved 528 7: IPv6 Header 530 NH: Next Header: 531 0: Full 8 bits for Next Header are carried in-line. 532 1: The Next Header field is compressed and the next header is 533 compressed using LOWPAN_NHC, which is discussed in Section 3. 535 For the most part, the IPv6 Extension Header is carried verbatim in 536 the bytes immediately following the LOWPAN_NHC octet, with two 537 important exceptions: Length Field and Next Header Field. 539 The Next Header Field contained in IPv6 Extension Headers is elided 540 when the NH bit is set in the LOWPAN_NHC encoding octet. Note that 541 doing so allows LOWPAN_NHC to utilize no more overhead than the non- 542 encoded IPv6 Extension Header. 544 The Length Field contained in IPv6 Extension Headers indicate the 545 length of the IPv6 Extension Header in octets, not including the 546 LOWPAN_NHC byte. Note that this changes the standard Length Field 547 definition from indicating the header size in 8-octet units, not 548 including the first 8 octets. Changing the Length Field to be in 549 units of octets removes wasteful internal fragmentation. However, 550 specifying units in octets also means that LOWPAN_NHC CANNOT be used 551 to encode IPv6 Extension Headers that exceed 255 octets. 553 IPv6 Hop-by-Hop and Destination Options Headers may use Pad1 and PadN 554 to pad out the header to a multiple of 8 octets in length. When 555 using LOWPAN_NHC, those Pad1 and PadN options MAY be elided and the 556 length of the header reduced by the size of those Pad1 and PadN 557 options. When converting from the LOWPAN_NHC encoding back to the 558 standard IPv6 encoding, Pad1 and PadN options MUST be used to pad out 559 the containing header to a multiple of 8 octets in length if 560 necessary. Note that Pad1 and PadN options that do not appear at the 561 end of the containing header MUST NOT be elided as they are used to 562 align subsequent options. 564 When the identified next header is an IPv6 Header (EID=7), the NH bit 565 of the LOWPAN_NHC encoding is unused and SHOULD be set to zero. The 566 bytes following follow the LOWPAN_IPHC encoding as defined in 567 Section 2. 569 3.3. UDP Header Compression 571 This document defines a compression format for UDP headers using 572 LOWPAN_NHC. The UDP compression format is shown in Figure 7. Bits 0 573 through 4 represent the NHC ID and '11110' indicates the specific UDP 574 header compression encoding defined in this section. 576 3.3.1. Compressing UDP ports 578 This specification introduces a range of well-known port (0xF0Bx) 579 that can be compressed to 4 bits. Considering that this represents 580 only 16 contiguous ports, it can be expected that many incompatible 581 applications will use the same port numbers of their own end-to-end 582 needs. 584 The overloading of the 0xF0Bx ports increases the risk of getting the 585 wrong type of payload and misinterpreting the content compared to 586 ports that reserved at IANA. It is thus recommended that the use of 587 those ports be associated with a mechanism such as a Transport Layer 588 Security (TLS) Message Integrity Check (MIC) that validates that the 589 content is expected and checked for integrity. 591 3.3.2. Compressing UDP checksum 593 The UDP checksum operation is mandatory with IPv6 [RFC2460] for all 594 packets. For that reason [RFC4944] disallows the compression of the 595 UDP checksum. 597 With this specification, a compressor in the source transport 598 endpoint MAY elide the UDP checksum if it authorized by the Upper 599 Layer. The compressor SHOULD NOT set the C bit unless it has 600 received such authorization. The Upper Layer SHOULD only provide the 601 authorization in the following cases: 603 Tunneling: In this case, 6LowPAN is deployed as a wireless pseudo- 604 fieldbus by tunneling existing field protocols over UDP. If the 605 tunneled PDU possesses its own addressing, security and integrity 606 check, the tunneling mechanism MAY authorize to elide the UDP 607 checksum in order to save on the encapsulation overhead. 609 Upper Layer Message Integrity Check: In this case, there is some 610 other form of integrity check in the UDP payload that covers at 611 least the same information as the UDP checksum (pseudo-header, 612 data) and has at least the same strength. 614 A forwarding node MAY imply authorization from the incoming packet 615 being forwarded if the C bit was set there. The forwarding node that 616 can not derive the authorization in an non-ambiguous fashion SHOULD 617 NOT elide the UDP checksum when performing 6LoWPAN compression. The 618 forwarding node that expands a 6LoWPAN packets with the C bit on MUST 619 compute the UDP checksum on behalf of the source node and place that 620 checksum in the restored UDP header as specified in the incumbent 621 standards [RFC0768], [RFC2460]. 623 If a 6LoWPAN termination is also the transport endpoint, and it 624 receives a compressed packet that has the C bit set, then it is 625 entitled to ignore the UDP checksum process completely. If the C bit 626 is not set, the packet might have been forwarded by an edge router, 627 so this is not an indication that the MIC is not present. If the 628 terminating node knows that the message integrity will be validated 629 by the upper layer by some state associated to the Service Access 630 Point, it is entitled to ignore the checksum operation as if the C 631 bit was set. 633 3.3.3. UDP LOWPAN_NHC Format 635 0 1 2 3 4 5 6 7 636 +---+---+---+---+---+---+---+---+ 637 | 1 | 1 | 1 | 1 | 0 | C | P | 638 +---+---+---+---+---+---+---+---+ 640 Figure 7: UDP Header Encoding 642 C: Checksum: 643 0: All 16 bits of Checksum are carried in-line. 644 1: All 16 bits of Checksum are elided. The Checksum is recovered 645 by recomputing it on the 6LoWPAN termination point. 647 P: Ports: 648 00: All 16 bits for both Source Port and Destination Port are 649 carried in-line. 650 01: All 16 bits for Source Port are carried in-line. First 8 651 bits of Destination Port is 0xF0 and elided. The remaining 8 652 bits of Destination Port are carried in-line. 654 10: First 8 bits of Source Port are 0xF0 and elided. The 655 remaining 8 bits of Source Port are carried in-line. All 16 656 bits for Destination Port are carried in-line. 657 11: First 12 bits of both Source Port and Destination Port are 658 0xF0B and elided. The remaining 4 bits for each are carried 659 in-line. 661 Fields carried in-line (in part or in whole) appear in the same order 662 as they do in the IPv6 header format [RFC2460]. IPv6 addresses may 663 be compressed to 64 or 16 bits or completely elided. The UDP Length 664 field MUST always be elided and is inferred from lower layers using 665 the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 667 4. IANA Considerations 669 This document defines a new IPv6 header compression format for 670 6LoWPAN networks. The document allocates Dispatch type values of 671 0x08-0x0F (TBD) for LOWPAN_IPHC. 673 5. Security Considerations 675 The definition of LOWPAN_IPHC permits the compression of header 676 information on communication that could take place in its absence, 677 albeit in a less efficient form. It recognizes that a IEEE 802.15.4 678 PAN may have associated with it a number of prefixes through shared 679 context. How the shared context is assigned and managed is beyond 680 the scope of this document. 682 The overloading of the 0xF0Bx ports increases the risk of getting the 683 wrong type of payload and misinterpreting the content compared to 684 ports that reserved at IANA. It is thus recommended that the use of 685 those ports be associated with a mechanism such as a Transport Layer 686 Security (TLS) Message Integrity Check (MIC) that validates that the 687 content is expected and checked for integrity. 689 6. Acknowledgements 691 Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, Erik 692 Nordmark, Robert Assimiti, Shoishi Sakane, Zach Shelby, Stephen 693 Dawson-Haggerty, Jay Werb and Mathilde Durvy for useful design 694 consideration and implementation feedback. 696 7. Changes 698 Draft 05: 699 - Added LOWPAN_NHC encodings for IPv6 Extension Headers. 700 - Specify use of context 0 when CID is 0. 701 - Indicate that first 64-bits is link-local prefix padded with 702 zeros when link-local prefix is elided. 703 - Made prefix-based multicast encoding format more explicit for 704 clarity. 705 - Changed wording around stateful compression to allow for using 706 the inline bits as an additional index to identify the compressed 707 address. 708 - Removed support for compressing unspecified address. 709 - Full 128-bit addr inline only in stateless encoding. 711 Draft 04: 712 - Fixed typos leftover from the changes in 03. 713 - Gave more details on UDP checksum compression. 714 - Clarify that the context information is out of scope. 715 - Added security concern on 0xF0Bx port overloading. 717 Draft 03: 718 - Decoupled meaning of SAM bits from the destination address. 719 - Have separate bit to indicate multicast address compression. 720 - More extensive support for multicast address compression, 721 including Unicast-Prefix-based Multicast Addresses. 723 Draft 02: 724 - Updated wording with compression mode to clarify that a 725 compression mode does not enforce what kind of destination address 726 is being used. Specifically changed Destination Dependent Field 727 to Compression Mode. 728 - Specify that the configuration and management of contexts is out 729 of scope of this document. 731 Draft 01: 732 - HC back to 1 byte by default by stealing a few bits from the 733 dispatch field. 734 - Added better support for multicast address compression. 735 - Fixed alignment for UDP port compression. 736 - Better support for Traffic Class and Flow Label compression. 737 - Pascal joined as an author. 739 8. References 740 8.1. Normative References 742 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 743 August 1980. 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 749 (IPv6) Specification", RFC 2460, December 1998. 751 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 752 "Definition of the Differentiated Services Field (DS 753 Field) in the IPv4 and IPv6 Headers", RFC 2474, 754 December 1998. 756 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 757 of Explicit Congestion Notification (ECN) to IP", 758 RFC 3168, September 2001. 760 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 761 in IPv6", RFC 3775, June 2004. 763 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 764 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 765 March 2005. 767 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 768 Architecture", RFC 4291, February 2006. 770 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 771 December 2005. 773 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 774 RFC 4303, December 2005. 776 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 777 "Transmission of IPv6 Packets over IEEE 802.15.4 778 Networks", RFC 4944, September 2007. 780 8.2. Informative References 782 [IEEE 802.15.4] 783 IEEE Computer Society, "IEEE Std. 802.15.4-2006", 784 October 2006. 786 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 787 Multicast Addresses", RFC 3306, August 2002. 789 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 790 and M. Carney, "Dynamic Host Configuration Protocol for 791 IPv6 (DHCPv6)", RFC 3315, July 2003. 793 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 794 Point (RP) Address in an IPv6 Multicast Address", 795 RFC 3956, November 2004. 797 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 798 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 799 September 2007. 801 Authors' Addresses 803 Jonathan W. Hui (editor) 804 Arch Rock Corporation 805 501 2nd St. Ste. 410 806 San Francisco, California 94107 807 USA 809 Phone: +415 692 0828 810 Email: jhui@archrock.com 812 Pascal Thubert 813 Cisco Systems 814 Village d'Entreprises Green Side 815 400, Avenue de Roumanille 816 Batiment T3 817 Biot - Sophia Antipolis 06410 818 FRANCE 820 Phone: +33 4 97 23 26 34 821 Email: pthubert@cisco.com