idnits 2.17.1 draft-ietf-6lowpan-hc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 746. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 757. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 770. 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 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 (December 8, 2008) is 5618 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 678, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 682, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 9 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: June 11, 2009 December 8, 2008 8 Compression Format for IPv6 Datagrams in 6LoWPAN Networks 9 draft-ietf-6lowpan-hc-04 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 11, 2009. 36 Abstract 38 This document specifies an IPv6 header compression format for IPv6 39 packet delivery in 6LoWPAN networks. The compression format relies 40 on shared context information to allow compression of arbitrary 41 prefixes and addresses. This document specifies an interface to an 42 abstract context database but the content and the management of the 43 database are out of scope. This document specifies compression of 44 multicast addresses and a framework for compressing next headers. 45 This framework specifies UDP compression and is prepared for 46 additional transports. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 52 2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4 53 2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 54 2.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5 55 2.1.2. Context Identifier Extension . . . . . . . . . . . . . 7 56 2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8 57 2.2.1. Traffic Class and Flow Label Compression . . . . . . . 9 58 2.2.2. Stateless Multicast Addresses Compression . . . . . . 10 59 2.2.3. Stateful Multicast Addresses Compression . . . . . . . 11 60 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11 61 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 12 62 3.2. UDP Header Compression . . . . . . . . . . . . . . . . . . 12 63 3.2.1. Compressing UDP ports . . . . . . . . . . . . . . . . 12 64 3.2.2. Compressing UDP checksum . . . . . . . . . . . . . . . 13 65 3.2.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 14 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 69 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 74 Intellectual Property and Copyright Statements . . . . . . . . . . 18 76 1. Introduction 78 The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding 79 about 80 octets of actual MAC payload once security is turned on, on 80 a wireless link with a link throughput of 250 kbps or less. The 81 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 82 datagrams over such constrained links, taking into account limited 83 bandwidth, memory, or energy resources that are expected in 84 applications such as Wireless Sensor Networks. [RFC4944] defines a 85 Mesh Addressing header to support sub-IP forwarding, a Fragmentation 86 header to support the IPv6 minimum MTU requirement [RFC2460], and 87 stateless header compression for IPv6 datagrams (LOWPAN_HC1 and 88 LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down 89 to (in the best case) several bytes. 91 LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of 92 6LoWPAN networks. LOWPAN_HC1 is most effective for link-local 93 unicast communication, where IPv6 addresses carry the link-local 94 prefix and Interface Identifiers (IID) directly derived from IEEE 95 802.15.4 addresses. In this case, both addresses may be completely 96 elided. However, though link-local addresses are commonly used for 97 local protocol interactions such as IPv6 ND [RFC4861], DHCPv6 98 [RFC3315] or routing protocols, they are not normally used for 99 application layer data traffic, so the actual value of this 100 compression mechanism is limited. 102 Routable addresses must be used when communicating with devices 103 external to the LoWPAN or in a route-over configuration where IP 104 forwarding occurs within the LoWPAN. For routable addresses, 105 LOWPAN_HC1 requires both IPv6 source and destination addresses to 106 carry the prefix in-line. In cases where the Mesh Addressing header 107 is not used, the IID of a routable address must be carried in-line. 108 However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line 109 and cannot be shortened even when it is derived from the IEEE 110 802.15.4 16-bit short address. 112 When the destination is an IPv6 multicast address, LOWPAN_HC1 113 requires the full 128-bit address to be carried in-line. This 114 specification provides an additional mechanism to compress Unique 115 Local, Global and multicast IPv6 Addresses based on shared states 116 within contexts. It also introduces a number of additional 117 improvements over [RFC4944]. 119 LOWPAN_HC1 cannot elide the IPv6 Hop Limit in the IPv6 header, even 120 though a limited set of values are useful in many practical cases. 121 For instance, if the LoWPAN is a mesh-under stub, a Hop Limit of 1 122 for inbound and a default value such as 64 for outbound are usually 123 enough for application layer data traffic. Compressing that field 124 enables saving one octet per packet. 126 LOWPAN_HC1 can be extended to include a LOWPAN_HC2 octet to support 127 compression of UDP, TCP, or ICMPv6; that LOWPAN_HC2 octet is placed 128 right after the LOWPAN_HC1 octet and before the uncompressed IP 129 fields. This specification moves the transport control octet after 130 the uncompressed IP fields for a more properly layered structure. 132 [RFC4944] defines a compression mechanism for UDP, but that mechanism 133 does not enable checksum compression when rendered possible by 134 additional upper layer mechanisms such as upper layer Message 135 Integrity Check (MIC). This specification adds the capability to 136 elide the UDP checksum over the LoWPAN, which allows savings of two 137 additional octets. 139 Finally, LOWPAN_HC1 lacks the flexibility to support the compression 140 of additional transport mechanisms that could be introduced in the 141 future. 143 This document specifies a header compression format for IPv6 144 datagrams. This format improves on the header compression format 145 defined in [RFC4944] by generalizing it to support a broader range of 146 communication paradigms, including both mesh-under and route-over 147 configurations; communication to nodes internal and external to the 148 6LoWPAN network; and multicast communication. This document also 149 defines a flexible framework for compressing arbitrary next headers 150 and defines UDP header compression within this framework. This 151 compression format carries forward the design concepts in RFC 4944 152 [RFC4944], minimizing compression state and state maintenance by 153 relying on shared context among all nodes in a 6LoWPAN network. 155 1.1. Requirements Language 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119 [RFC2119]. 161 2. IPv6 Header Compression 163 In this section, we define the LOWPAN_IPHC encoding format for 164 compressing the IPv6 header. To enable effective compression 165 LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN 166 network. LOWPAN_IPHC assumes the following will be the common case 167 for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label 168 are both zero; Payload Length can be inferred from lower layers from 169 either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; 170 Hop Limit will be set to a well-known value by the source; addresses 171 assigned to 6LoWPAN interfaces will be formed using the link-local 172 prefix or a single routable prefix assigned to the entire 6LoWPAN 173 network; addresses assigned to 6LoWPAN interfaces are formed with an 174 IID derived directly from either the 64-bit extended or 16-bit short 175 IEEE 802.15.4 addresses. 177 +-------------------------------------+------------------------ 178 | Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header 179 +-------------------------------------+------------------------ 181 Figure 1: LOWPAN_IPHC Header 183 The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from 184 the rightmost bits of the dispatch type. The encoding may be 185 extended by another octet to support additional contexts. 186 Uncompressed IPv6 header fields follow the LOWPAN_IPHC encoding, as 187 shown in Figure 1. With the above scenario, the LOWPAN_IPHC can 188 compress the IPv6 header down to two octets (the dispatch octet and 189 the LOWPAN_IPHC encoding) with link-local communication. When 190 routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 191 header down to 7 octets (2-octets dispatch/LOWPAN_IPHC, 1-octet Hop 192 Limit, 2-octet Source Address, and 2-octet Destination Address). 194 2.1. LOWPAN_IPHC Encoding Format 196 2.1.1. Base Format 198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 199 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 200 | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | 201 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 203 Figure 2: LOWPAN_IPHC Encoding 205 TF: Traffic Class, Flow Label: 206 00: Traffic Class + 4-bit Pad + Flow Label (4 bytes) 207 01: ECN + 2-bit Pad + Flow Label (3 bytes) 208 10: Traffic Class (1 byte) 209 11: Version, Traffic Class, and Flow Label are compressed. 211 NH: Next Header: 212 0: Full 8 bits for Next Header are carried in-line. 213 1: The Next Header field is compressed and the next header is 214 compressed using LOWPAN_NHC, which is discussed in Section 3. 216 HLIM: Hop Limit: 217 00: The Hop Limit field is carried in-line. 218 01: The Hop Limit field is elided and the the hop limit is 1. 219 10: The Hop Limit field is elided and the the hop limit is 64. 220 11: The Hop Limit field is elided and the hop limit is 255. 222 CID: Context Identifier Extension: 223 0: No additional 8-bit Context Identifier Extension is used. If 224 context-based compression is specified in either SC or DC, the 225 default context is used. 226 1: An additional 8-bit Context Identifier Extension field 227 immediately follows the DAM field. 229 SAC: Source Address Compression 230 0: Source address compression uses stateless compression. 231 1: Source address compression uses stateful, context-based 232 compression. 234 SAM: Source Address Mode: 235 If SAC=0: 236 00: 0 bits. The address is the unspecified address. 237 01: 64 bits. The first 64-bits of the address are elided. 238 The value of those bits is the link-local prefix padded with 239 zeros. The remaining 64 bits are carried inline. 240 10: 16 bits. The first 112 bits of the address are elided. 241 The value of those bits is the link-local prefix padded with 242 zeros. The remaining 16 bits are carried inline. 243 11: 0 bits. The address is fully elided. The first 64 bits 244 of the address are elided. The remaining 64 bits are 245 computed from the link-layer address as defined in 246 [RFC4944]. 247 If SAC=1: 248 00: 128 bits. The full address is carried in-line. 249 01: 64 bits. The first 64-bits of the address are elided. 250 The value of those bits is taken from the context and padded 251 with zeros. The remaining 64 bits are carried inline. 252 10: 16 bits. The first 112 bits of the address are elided. 253 The value of those bits is taken from the context and padded 254 with zeros. The remaining 16 bits are carried inline. 256 11: 0 bits. The address is fully elided. The first 64 bits 257 are taken from the context. The remaining 64 bits are 258 computed from the link-layer address as defined in 259 [RFC4944]. 261 M: Multicast Compression 262 0: Destination address does not use multicast compression. 263 1: Destination address uses multicast compression. 265 DAC: Destination Address Compression 266 0: Destination address compression uses stateless compression. 267 1: Destination address compression uses stateful, context-based 268 compression. 270 DAM: Destination Address Mode: 271 If M=0: When DAC=0, any elided prefix bits are the link-local 272 prefix padded by zeros. When DAC=1, any elided prefix bits are 273 taken from the context and padded by zeros. 274 00: 128 bits. The full address is carried in-line. 275 01: 64 bits. The first 64-bits of the address are elided. 276 The remaining 64 bits are carried inline. 277 10: 16 bits. The first 112 bits of the address are elided. 278 The remaining 16 bits are carried inline. 279 11: 0 bits. The address is fully elided. The first 64 bits 280 of the address are elided. The remaining 64 bits are 281 computed from the link-layer address as defined in 282 [RFC4944]. 283 If M=1 and DAC=0: 284 00: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX. 285 01: 32 bits. The address takes the form FFXX::00XX:XXXX. 286 10: 16 bits. The address takes the form FF0X::0XXX. 287 11: 8 bits. The address takes the form FF02::00XX. 288 If M=1 and DAC=1: 289 00: 128 bits. The full address is carried in-line. 290 01: 48 bits. The address takes the form FFXX::XX[plen]: 291 [prefix]:XXXX:XXXX. The values of plen and prefix are taken 292 from the specified context. 293 10: reserved 294 11: reserved 296 2.1.2. Context Identifier Extension 298 This specification expects that an abstract set of states called 299 contexts is shared between the node that compresses a packet and the 300 node(s) that need to expand it. The specification enables the 301 transport of an opaque index that is used to lookup the abstract 302 context database. The index in encoded with 4 bits enabling to 303 address up to 16 contexts. 305 This specification requires that services associated to the abstract 306 context database implement an interface to the 6LoWPAN compressor to 307 help compress and uncompress an address based on the parameters 308 passed by the compressor and the information in the abstract context 309 database. 311 The interface MUST provide the methods to lookup a context ID from a 312 prefix and a prefix length for encoding, and reversely lookup a 313 prefix and a prefix length from a context ID for decoding. 315 How the contexts are shared and maintained is out of scope. The 316 actual context information is out of scope. Actions in response to 317 unknown and/or invalid contexts are out of scope. 319 The interface might be extended to allow for further stateful 320 compression, for instance for SAC = 11, additional context 321 information might be used to store the full IPv6 address using the 322 Link layer Address as an additional index. 324 If the CID field is set to '1' in the LOWPAN_HC encoding, then an 325 additional octet extends the LOWPAN_HC encoding following the DAM 326 bits but before the IPv6 header fields that are carried in-line. The 327 additional octet identifies the prefix when the IPv6 source and/or 328 destination address is compressed. The context identifier is 4 bits 329 for each address, supporting up to 16 contexts. The encoding is 330 shown in Figure 3. 332 0 1 2 3 4 5 6 7 333 +---+---+---+---+---+---+---+---+ 334 | SCI | DCI | 335 +---+---+---+---+---+---+---+---+ 337 Figure 3: LOWPAN_IPHC Encoding 339 SCI: Source Context Identifier Identifies the prefix that is used 340 when the IPv6 source address is compressed. 341 DCI: Destination Context Identifier Identifies the prefix that is 342 used when the IPv6 destination address is compressed. 344 2.2. IPv6 Header Encoding 346 Fields carried in-line (in part or in whole) appear in the same order 347 as they do in the IPv6 header format [RFC2460]. The Version field is 348 always elided. The IPv6 Payload Length field MUST always be elided 349 and inferred from lower layers using the 6LoWPAN Fragmentation header 350 or the IEEE 802.15.4 header. Unicast IPv6 addresses may be 351 compressed to 64 or 16 bits or completely elided. Multicast IPv6 352 addresses may be compressed to 8, 16, or 24 bits. 354 2.2.1. Traffic Class and Flow Label Compression 356 The Traffic Class field in the IPv6 header comprises 6 bits of 357 diffserv extension [RFC2474] and 2 bits of Explicit Congestion 358 Notification (ECN) [RFC3168]. If the ECN information is carried by 359 the Lower Layers in a compatible fashion then it can be elided from 360 the 6LoWPAN header. Otherwise, it has to be transported in one of 361 the following encodings. 363 The TF field in the LOWPAN_HC encoding indicate whether the Traffic 364 Class and Flow Label are carried in-line in the compressed IPv6 365 header. When Flow Label is included while the Traffic Class is 366 compressed, an additional 4 bits are included to maintain byte- 367 alignment. Two of the 4 bits contain the ECN bits from the Traffic 368 Class field. 370 To ensure that the ECN bits appear in the same location for all 371 encodings that include them, the Traffic Class field is rotated right 372 by 2 bits in the compressed IPv6 header. The encodings are shown 373 below: 375 1 2 3 376 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 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 |ECN| DSCP | rsv | Flow Label | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 TF = 00: Traffic Class and Flow Label carried in-line. 383 1 2 384 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |ECN|rsv| Flow Label | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 TF = 01: Flow Label carried in-line. 391 0 1 2 3 4 5 6 7 392 +-+-+-+-+-+-+-+-+ 393 |ECN| DSCP | 394 +-+-+-+-+-+-+-+-+ 396 TF = 10: Traffic Class carried in-line. 398 2.2.2. Stateless Multicast Addresses Compression 400 LOWPAN_HC supports stateless compression of multicast address when M 401 = 1 and SAC = 0. An IPv6 multicast address may be compressed down to 402 48, 32, 16, or 8 bits using stateless compression. The format 403 supports compression of the Solicited-Node Multicast Address (FF02:: 404 1:FFXX:XXXX) as well as any IPv6 multicast address where the upper 405 bits of the multicast group identifier are zero. The compressed 406 forms only carry the least-significant bits of the multicast group 407 identifier. 409 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Flags | Scope | Group Identifier | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Group Identifier | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 DAM = 00. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg) 419 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Flags | Scope | Group Identifier | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 DAM = 01. 32-bit Compressed Multicast Address (FFfs:00gg:gggg). 427 1 428 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Scope | Group Identifier | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 DAM = 10. 16-bit Compressed Multicast Address (FF0s::0ggg). 435 0 1 2 3 4 5 6 7 436 +-+-+-+-+-+-+-+-+ 437 | Group ID | 438 +-+-+-+-+-+-+-+-+ 440 DAM = 11. 8-bit Compressed Multicast Address (FF02::gg). 442 2.2.3. Stateful Multicast Addresses Compression 444 LOWPAN_HC supports stateful compression of multicast addresses when M 445 = 1 and SAC = 1. This document currently defines SAM = 01: context- 446 based compression of Unicast-Prefix-based IPv6 Multicast Addresses 447 [RFC3306][RFC3956]. In particular, the Prefix Length and Network 448 Prefix can be taken from a context. As a result, LOWPAN_HC can 449 compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 450 octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and 451 32-bit Group Identifier in-line. 453 1 2 3 454 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 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Flags | Scope | Reserved | Group Identifier | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Group Identifier | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression 463 The Reserved field MUST carry the reserved bits from the multicast 464 address format as described in [RFC3306]. When a Rendezvous Point is 465 encoded in the multicast address as described in [RFC3956], the 466 Reserved field carries the RIID bits in-line. 468 3. IPv6 Next Header Compression 470 LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set 471 to 1. It also indicates the use of 6LoWPAN next header compression, 472 LOWPAN_NHC. The value of IPv6 Next Header is recovered from the 473 first bits in the LOWPAN_NHC encoding. The following bits are 474 specific to the IPv6 Next Header value. Figure 4 shows the structure 475 of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. 477 +-------------+-------------+-------------+-----------------+-------- 478 | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload 479 | Encoding | IP Fields | Encoding | Header Fields | 480 +-------------+-------------+-------------+-----------------+-------- 482 Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration 484 3.1. LOWPAN_NHC Format 486 Compression formats for different next headers are identified by a 487 variable length bit-pattern immediately following the LOWPAN_IPHC 488 compressed header. When defining a next header compression format, 489 the number of bits used SHOULD be determined by the perceived 490 frequency of using that format. However, the number of bits and any 491 remaining encoding bits SHOULD respect octet alignment. The 492 following bits are specific to the next header compression format. 493 In this document, we define a compression format for UDP headers. 495 +----------------+--------------------------- 496 | var-len NHC ID | compressed next header... 497 +----------------+--------------------------- 499 Figure 5: LOWPAN_NHC Encoding 501 3.2. UDP Header Compression 503 This document defines a compression format for UDP headers using 504 LOWPAN_NHC. The UDP compression format is shown in Figure 6. Bits 0 505 through 4 represent the NHC ID and '11110' indicates the specific UDP 506 header compression encoding defined in this section. 508 3.2.1. Compressing UDP ports 510 This specification introduces a range of well-known port (0xF0Bx) 511 that can be compressed to 4 bits. Considering that this represents 512 only 16 contiguous ports, it can be expected that many incompatible 513 applications will use the same port numbers of their own end-to-end 514 needs. 516 The overloading of the 0xF0Bx ports increases the risk of getting the 517 wrong type of payload and misinterpreting the content compared to 518 ports that reserved at IANA. It is thus recommended that the use of 519 those ports be associated with a mechanism such as a Transport Layer 520 Security (TLS) Message Integrity Check (MIC) that validates that the 521 content is expected and checked for integrity. 523 3.2.2. Compressing UDP checksum 525 The UDP checksum operation is mandatory with IPv6 [RFC2460] for all 526 packets. For that reason [RFC4944] disallows the compression of the 527 UDP checksum. 529 With this specification, a compressor in the source transport 530 endpoint MAY elide the UDP checksum in certain cases for instance: 532 Upper Layer Message Integrity Check: In this case, there is some 533 other form of integrity check in the UDP payload that covers at 534 least the same information as the UDP checksum (pseudo-header, 535 data) and has at least the same strength. 536 Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo- 537 fieldbus by tunneling existing field protocols over UDP. If the 538 tunneled PDU possesses its own addressing, security and integrity 539 check, the tunneling mechanism MAY authorize to elide the UDP 540 checksum in order to save on the encapsulation overhead. 542 This elision is indicated by setting the 'C' bit in the LOWPAN_NHC 543 header. 545 A 6LoWPAN endpoint that compresses the LOWPAN_NHC header MUST NOT 546 elide the UDP checksum (set the C bit) unless it has been authorized 547 to do so by the source of the packet. In the source transport 548 endpoint, this authorization can come from upper layer transport or 549 application protocol instance that originated the packet. In a 550 forwarding node, this authorization is implied when the incoming 551 packet had the optimization applied (had the C bit set). 553 A 6LoWPAN endpoint that expands the LOWPAN_NHC header MUST 554 reconstitute the UDP checksum by computing the valid value for the 555 datagram as specified in [RFC0768] and [RFC2460], and place the 556 result of that computation in the restored UDP header, unless it has 557 been authorized to ignore the checksum operation. In the destination 558 transport endpoint this authorization can come from upper layer 559 transport that will receive the packet and would ignore the UDP 560 checksum should it be restored. 562 3.2.3. UDP LOWPAN_NHC Format 564 0 1 2 3 4 5 6 7 565 +---+---+---+---+---+---+---+---+ 566 | 1 | 1 | 1 | 1 | 0 | C | P | 567 +---+---+---+---+---+---+---+---+ 569 Figure 6: UDP Header Encoding 571 C: Checksum: 572 0: All 16 bits of Checksum are carried in-line. 573 1: All 16 bits of Checksum are elided. The Checksum is recovered 574 by recomputing it on the 6LoWPAN termination point. 576 P: Ports: 577 00: All 16 bits for both Source Port and Destination Port are 578 carried in-line. 579 01: All 16 bits for Source Port are carried in-line. First 8 580 bits of Destination Port is 0xF0 and elided. The remaining 8 581 bits of Destination Port are carried in-line. 582 10: First 8 bits of Source Port are 0xF0 and elided. The 583 remaining 8 bits of Source Port are carried in-line. All 16 584 bits for Destination Port are carried in-line. 585 11: First 12 bits of both Source Port and Destination Port are 586 0xF0B and elided. The remaining 4 bits for each are carried 587 in-line. 589 Fields carried in-line (in part or in whole) appear in the same order 590 as they do in the IPv6 header format [RFC2460]. IPv6 addresses may 591 be compressed to 64 or 16 bits or completely elided. The UDP Length 592 field MUST always be elided and is inferred from lower layers using 593 the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 595 4. IANA Considerations 597 This document defines a new IPv6 header compression format for 598 6LoWPAN networks. The document allocates Dispatch type values of 599 0x08-0x0F (TBD) for LOWPAN_IPHC. 601 5. Security Considerations 603 The definition of LOWPAN_IPHC permits the compression of header 604 information on communication that could take place in its absence, 605 albeit in a less efficient form. It recognizes that a IEEE 802.15.4 606 PAN may have associated with it a number of prefixes through shared 607 context. How the shared context is assigned and managed is beyond 608 the scope of this document. 610 The overloading of the 0xF0Bx ports increases the risk of getting the 611 wrong type of payload and misinterpreting the content compared to 612 ports that reserved at IANA. It is thus recommended that the use of 613 those ports be associated with a mechanism such as a Transport Layer 614 Security (TLS) Message Integrity Check (MIC) that validates that the 615 content is expected and checked for integrity. 617 6. Acknowledgements 619 Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, Erik 620 Nordmark, Robert Assimiti, Shoishi Sakane, Zach Shelby, Stephen 621 Dawson-Haggerty, Jay Werb, and Mathilde Durvy for useful design 622 consideration and implementation feedback. 624 7. Changes 626 Draft 04: 627 - Fixed typos leftover from the changes in 03. 628 - Gave more details on UDP checksum compression. 629 - Greater discussion on the use of context information and 630 clarification that its details are out of scope. 631 - Added security concern on 0xF0Bx port overloading. 633 Draft 03: 634 - Decoupled meaning of SAM bits from the destination address. 635 - Have separate bit to indicate multicast address compression. 636 - More extensive support for multicast address compression, 637 including Unicast-Prefix-based Multicast Addresses. 639 Draft 02: 640 - Updated wording with compression mode to clarify that a 641 compression mode does not enforce what kind of destination address 642 is being used. Specifically changed Destination Dependent Field 643 to Compression Mode. 644 - Specify that the configuration and management of contexts is out 645 of scope of this document. 647 Draft 01: 649 - HC back to 1 byte by default by stealing a few bits from the 650 dispatch field. 651 - Added better support for multicast address compression. 652 - Fixed alignment for UDP port compression. 653 - Better support for Traffic Class and Flow Label compression. 654 - Pascal joined as an author. 656 8. References 658 8.1. Normative References 660 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 661 August 1980. 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 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 670 "Definition of the Differentiated Services Field (DS 671 Field) in the IPv4 and IPv6 Headers", RFC 2474, 672 December 1998. 674 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 675 of Explicit Congestion Notification (ECN) to IP", 676 RFC 3168, September 2001. 678 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 679 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 680 March 2005. 682 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 683 Architecture", RFC 4291, February 2006. 685 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 686 "Transmission of IPv6 Packets over IEEE 802.15.4 687 Networks", RFC 4944, September 2007. 689 8.2. Informative References 691 [IEEE 802.15.4] 692 IEEE Computer Society, "IEEE Std. 802.15.4-2006", 693 October 2006. 695 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 696 Multicast Addresses", RFC 3306, August 2002. 698 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 699 and M. Carney, "Dynamic Host Configuration Protocol for 700 IPv6 (DHCPv6)", RFC 3315, July 2003. 702 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 703 Point (RP) Address in an IPv6 Multicast Address", 704 RFC 3956, November 2004. 706 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 707 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 708 September 2007. 710 Authors' Addresses 712 Jonathan W. Hui (editor) 713 Arch Rock Corporation 714 501 2nd St. Ste. 410 715 San Francisco, California 94107 716 USA 718 Phone: +415 692 0828 719 Email: jhui@archrock.com 721 Pascal Thubert 722 Cisco Systems 723 Village d'Entreprises Green Side 724 400, Avenue de Roumanille 725 Batiment T3 726 Biot - Sophia Antipolis 06410 727 FRANCE 729 Phone: +33 4 97 23 26 34 730 Email: pthubert@cisco.com 732 Full Copyright Statement 734 Copyright (C) The IETF Trust (2008). 736 This document is subject to the rights, licenses and restrictions 737 contained in BCP 78, and except as set forth therein, the authors 738 retain all their rights. 740 This document and the information contained herein are provided on an 741 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 742 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 743 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 744 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 745 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 746 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 748 Intellectual Property 750 The IETF takes no position regarding the validity or scope of any 751 Intellectual Property Rights or other rights that might be claimed to 752 pertain to the implementation or use of the technology described in 753 this document or the extent to which any license under such rights 754 might or might not be available; nor does it represent that it has 755 made any independent effort to identify any such rights. Information 756 on the procedures with respect to rights in RFC documents can be 757 found in BCP 78 and BCP 79. 759 Copies of IPR disclosures made to the IETF Secretariat and any 760 assurances of licenses to be made available, or the result of an 761 attempt made to obtain a general license or permission for the use of 762 such proprietary rights by implementers or users of this 763 specification can be obtained from the IETF on-line IPR repository at 764 http://www.ietf.org/ipr. 766 The IETF invites any interested party to bring to its attention any 767 copyrights, patents or patent applications, or other proprietary 768 rights that may cover technology that may be required to implement 769 this standard. Please address the information to the IETF at 770 ietf-ipr@ietf.org.