idnits 2.17.1 draft-ietf-6lowpan-hc-03.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 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 659. 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 (November 17, 2008) is 5632 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 567, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 571, 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: May 21, 2009 November 17, 2008 8 Compression Format for IPv6 Datagrams in 6LoWPAN Networks 9 draft-ietf-6lowpan-hc-03 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 May 21, 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 to allow compression of arbitrary prefixes. This 41 document specifies compression of multicast addresses and a framework 42 for compressing next headers. This framework specifies UDP 43 compression and is prepared for additional transports. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 49 2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4 50 2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 51 2.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 5 52 2.1.2. Context Identifier Extension . . . . . . . . . . . . . 7 53 2.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 8 54 2.2.1. Traffic Class and Flow Label Compression . . . . . . . 8 55 2.2.2. Stateless Multicast Addresses Compression . . . . . . 9 56 2.2.3. Stateful Multicast Addresses Compression . . . . . . . 10 57 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 11 58 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 11 59 3.2. UDP Header Compression . . . . . . . . . . . . . . . . . . 12 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 62 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 63 7. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 68 Intellectual Property and Copyright Statements . . . . . . . . . . 16 70 1. Introduction 72 The [IEEE 802.15.4] standard specifies an MTU of 128 bytes, yielding 73 about 80 octets of actual MAC payload once security is turned on, on 74 a wireless link with a link throughput of 250 kbps or less. The 75 6LoWPAN adaptation format [RFC4944] was specified to carry IPv6 76 datagrams over such constrained links, taking into account limited 77 bandwidth, memory, or energy resources that are expected in 78 applications such as wireless Sensor Networks. [RFC4944] defines a 79 Mesh Addressing header to support sub-IP forwarding, a Fragmentation 80 header to support the IPv6 minimum MTU requirement [RFC2460], and 81 stateless header compression for IPv6 datagrams (LOWPAN_HC1 and 82 LOWPAN_HC2) to reduce the relatively large IPv6 and UDP headers down 83 to (in the best case) several bytes. 85 LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of 86 6LoWPAN networks. LOWPAN_HC1 is most effective for link-local 87 unicast communication, where IPv6 addresses carry the link-local 88 prefix and an Interface Identifier (IID) directly derived from IEEE 89 802.15.4 addresses. In this case, both addresses may be completely 90 elided. However, though link local addresses are commonly used for 91 local protocol interactions such as IPv6 ND [RFC4861], DHCPv6 92 [RFC3315] or routing protocols, they are usually not used for 93 application layer data traffic, so the actual value of this 94 compression mechanism is limited. 96 Routable addresses must be used when communicating with devices 97 external to the LoWPAN or in a route-over configuration where IP 98 forwarding occurs within the LoWPAN. For routable addresses, 99 LOWPAN_HC1 requires both IPv6 source and destination addresses to 100 carry the prefix in-line. In cases where the Mesh Addressing header 101 is not used, the IID of a routable address must be carried in-line. 102 However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line 103 and cannot be shortened even when it is derived from the IEEE 104 802.15.4 16-bit short address. 106 When the destination is an IPv6 multicast address, LOWPAN_HC1 107 requires the full 128-bit address to be carried in-line. This 108 specification provides an additional mechanism to compress Unique 109 Local, Global and multicast IPv6 Addresses based on shared states 110 within contexts. It also introduces a number of additional 111 improvements over [RFC4944]. 113 LOWPAN_HC1 cannot elide the IPv6 Hop Limit in the IPv6 header, even 114 though a limited set of values are useful in many practical cases. 115 For instance, if the LoWPAN is a mesh-under stub, a Hop Limit of 1 116 for inbound and a default value such as 64 for outbound are usually 117 enough for application layer data traffic. Compressing that field 118 enables saving one octet per packet. 120 LOWPAN_HC1 can be extended to include a LOWPAN_HC2 octet to support 121 compression of UDP, TCP, or ICMPv6; that LOWPAN_HC2 octet is placed 122 right after the LOWPAN_HC1 octet and before the uncompressed IP 123 fields. This specification moves the transport control octet after 124 the uncompressed IP fields for a more properly layered structure. 126 [RFC4944] defines a compression mechanism for UDP, but that mechanism 127 does not enable checksum compression when rendered possible by 128 additional upper layer mechanisms such as upper layer Message 129 Integrity Check (MIC). This specification adds the capability to 130 compress the UDP checksum over the LoWPAN, which enables to save an 131 additional pair of octets. 133 Finally, LOWPAN_HC1 lacks the flexibility to support the compression 134 of additional transport mechanisms that could be introduced in the 135 future. 137 This document specifies a header compression format for IPv6 138 datagrams. This format improves on the header compression format 139 defined in [RFC4944] by generalizing it to support a broader range of 140 communication paradigms, including both mesh-under and route-over 141 configurations; communication to nodes internal and external to the 142 6LoWPAN network; and multicast communication. This document also 143 defines a flexible framework for compressing arbitrary next headers 144 and defines UDP header compression within this framework. This 145 compression format carries forward the design concepts in RFC 4944 146 [RFC4944], minimizing any state and relying on shared context among 147 all nodes in a 6LoWPAN network. 149 1.1. Requirements Language 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in RFC 2119 [RFC2119]. 155 2. IPv6 Header Compression 157 In this section, we define the LOWPAN_IPHC encoding format for 158 compressing the IPv6 header. To enable effective compression 159 LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN 160 network. LOWPAN_IPHC assumes the following will be the common case 161 for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label 162 are both zero; Payload Length can be inferred from lower layers from 163 either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; 164 Hop Limit will be set to a well-known value by the source; addresses 165 assigned to 6LoWPAN interfaces will be formed using the link-local 166 prefix or a single routable prefix assigned to the entire 6LoWPAN 167 network; addresses assigned to 6LoWPAN interfaces are formed with an 168 IID derived directly from either the 64-bit extended or 16-bit short 169 IEEE 802.15.4 addresses. 171 +-------------------------------------+------------------------ 172 | Dispatch + LOWPAN_IPHC (2-3 octets) | Compressed IPv6 Header 173 +-------------------------------------+------------------------ 175 Figure 1: LOWPAN_IPHC Header 177 The LOWPAN_IPHC encoding utilizes 11 bits, 3 of which are taken from 178 the rightmost bit of the dispatch type. The encoding may be extended 179 by another octet to support additional contexts. Uncompressed IPv6 180 header fields follow the LOWPAN_IPHC encoding, as shown in Figure 1. 181 With the above scenario, the LOWPAN_IPHC can compress the IPv6 header 182 down to two octets (the dispatch octet and the LOWPAN_IPHC encoding) 183 with link-local communication. When routing over multiple IP hops, 184 LOWPAN_IPHC can compress the IPv6 header down to 7 octets (1-octet 185 dispatch, 1-octet LOWPAN_IPHC, 1-octet Hop Limit, 2-octet Source 186 Address, and 2-octet Destination Address). 188 2.1. LOWPAN_IPHC Encoding Format 190 2.1.1. Base Format 192 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 193 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 194 | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | 195 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 197 Figure 2: LOWPAN_IPHC Encoding 199 TF: Traffic Class, Flow Label: 200 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) 201 01: ECN + 2-bit Pad + Flow Label (3 bytes) 202 10: Traffic Class (1 byte) 203 11: Version, Traffic Class, and Flow Label are compressed. 205 NH: Next Header: 206 0: Full 8 bits for Next Header are carried in-line. 207 1: The Next Header field is compressed and the next header is 208 compressed using LOWPAN_NHC, which is discussed in Section 3. 210 HLIM: Hop Limit: 211 00: The Hop Limit field is carried in-line. 212 01: The Hop Limit field is elided and the the hop limit is 1. 213 10: The Hop Limit field is elided and the the hop limit is 64. 214 11: The Hop Limit field is elided and the hop limit is 255. 216 CID: Context Identifier Extension: 217 0: No additional 8-bit Context Identifier Extension is used. If 218 context-based compression is specified in either SC or DC, the 219 default context is used. 220 1: An additional 8-bit Context Identifier Extension field 221 immediately follows the DAM field. 223 SAC: Source Address Compression 224 0: Source address compression uses stateless compression. 225 1: Source address compression uses stateful, context-based 226 compression. 228 SAM: Source Address Mode: 229 If SAC=0: 230 00: 0 bits. The address is the unspecified address. 231 01: 64 bits. The first 64-bits of the address are elided. 232 The value of those bits is the link-local prefix padded with 233 zeros. The remaining 64 bits are carried inline. 234 10: 16 bits. The first 112 bits of the address are elided. 235 The value of those bits is the link-local prefix padded with 236 zeros. The remaining 16 bits are carried inline. 237 11: 0 bits. The address is fully elided. The first 64 bits 238 of the address are elided. The remaining 64 bits are 239 computed from the link-layer address as defined in 240 [RFC4944]. 241 If SAC=1: 242 00: 128 bits. The full address is carried in-line. 243 01: 64 bits. The first 64-bits of the address are elided. 244 The value of those bits is taken from the context and padded 245 with zeros. The remaining 64 bits are carried inline. 246 10: 16 bits. The first 112 bits of the address are elided. 247 The value of those bits is taken from the context and padded 248 with zeros. The remaining 16 bits are carried inline. 250 11: 0 bits. The address is fully elided. The first 64 bits 251 are taken from the context. The remaining 64 bits are 252 computed from the link-layer address as defined in 253 [RFC4944]. 255 M: Multicast Compression 256 0: Destination address does not use multicast compression. 257 1: Destination address uses multicast compression. 259 DAC: Destination Address Compression 260 0: Destination address compression uses stateless compression. 261 1: Destination address compression uses stateful, context-based 262 compression. 264 DAM: Destination Address Mode: 265 If M=0: When DAC=0, any elided prefix bits are the link-local 266 prefix padded by zeros. When DAC=1, any elided prefix bits are 267 taken from the context and padded by zeros. 268 00: 128 bits. The full address is carried in-line. 269 01: 64 bits. The first 64-bits of the address are elided. 270 The remaining 64 bits are carried inline. 271 10: 16 bits. The first 112 bits of the address are elided. 272 The remaining 16 bits are carried inline. 273 11: 0 bits. The address is fully elided. The first 64 bits 274 of the address are elided. The remaining 64 bits are 275 computed from the link-layer address as defined in 276 [RFC4944]. 277 If M=1 and DAC=0: 278 00: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX. 279 01: 32 bits. The address takes the form FFXX::00XX:XXXX. 280 10: 16 bits. The address takes the form FF0X::0XXX. 281 11: 8 bits. The address takes the form FF02::00XX. 282 If M=1 and DAC=1: 283 00: 128 bits. The full address is carried in-line. 284 01: 48 bits. The address takes the form FFXX::XX[plen]: 285 [prefix]:XXXX:XXXX. The values of plen and prefix are taken 286 from the specified context. 287 10: reserved 288 11: reserved 290 2.1.2. Context Identifier Extension 292 This specification expects that a concept of context is shared 293 between the node that compresses a packet and the node(s) that need 294 to expand it. The specification enables a node to use of up to 16 295 contexts. How the contexts are shared and maintained is out of 296 scope. Actions in response to unknown and/or invalid contexts are 297 out of scope. 299 If the CMF field is set to '01' in the LOWPAN_HC encoding, then an 300 additional octet extends the LOWPAN_HC encoding following the DAM 301 bits but before the IPv6 header fields that are carried in-line. The 302 additional octet identifies the prefix when the IPv6 source and/or 303 destination address is compressed. The context identifier is 4 bits 304 for each address, supporting up to 16 contexts. The encoding is 305 shown in Figure 3. 307 0 1 2 3 4 5 6 7 308 +---+---+---+---+---+---+---+---+ 309 | SAC | DAC | 310 +---+---+---+---+---+---+---+---+ 312 Figure 3: LOWPAN_IPHC Encoding 314 SAC: Source Address Context Identifies the prefix that is used when 315 the IPv6 source address is compressed. 316 DAC: Destination Address Context Identifies the prefix that is used 317 when the IPv6 destination address is compressed. 319 2.2. IPv6 Header Encoding 321 Fields carried in-line (in part or in whole) appear in the same order 322 as they do in the IPv6 header format [RFC2460]. The Version field is 323 always elided. Unicast IPv6 addresses may be compressed to 64 or 16 324 bits or completely elided. Multicast IPv6 addresses may be 325 compressed to 8, 16, or 24 bits. The IPv6 Payload Length field MUST 326 always be elided and inferred from lower layers using the 6LoWPAN 327 Fragmentation header or the IEEE 802.15.4 header. 329 2.2.1. Traffic Class and Flow Label Compression 331 The TF field in the LOWPAN_HC encoding indicate whether the Traffic 332 Class and Flow Label are carried in-line in the compressed IPv6 333 header. When Flow Label is included while the Traffic Class is 334 compressed, an additional 4 bits are included to maintain byte- 335 alignment. Two of the 4 bits contain the ECN bits from the Traffic 336 Class field. 338 To ensure that the ECN bits appear in the same location for all 339 encodings that include them, the Traffic Class field is rotated right 340 by 2 bits in the compressed IPv6 header. The encodings are shown 341 below: 343 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 |ECN| DSCP | rsv | Flow Label | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 TF = 00: Traffic Class and Flow Label carried in-line. 351 1 2 352 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 |ECN|rsv| Flow Label | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 TF = 01: Flow Label carried in-line. 359 0 1 2 3 4 5 6 7 360 +-+-+-+-+-+-+-+-+ 361 |ECN| DSCP | 362 +-+-+-+-+-+-+-+-+ 364 TF = 10: Traffic Class carried in-line. 366 2.2.2. Stateless Multicast Addresses Compression 368 LOWPAN_HC supports stateless compression of multicast address when M 369 = 1 and SAC = 0. An IPv6 multicast address may be compressed down to 370 48, 32, 16, or 8 bits using stateless compression. The format 371 supports compression of the Solicited-Node Multicast Address (FF02:: 372 1:FFXX:XXXX) as well as any IPv6 multicast address where the upper 373 bits of the multicast group identifier are zero. The compressed 374 forms only carry the least-significant bits of the multicast group 375 identifier. All compressed forms carry the multicast scope in-line 376 and all (except DAM=10) carry the multicast flags as well. 378 1 2 3 379 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 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | Flags | Scope | Group Identifier | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Group Identifier | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 DAM = 00. 48-bit Compressed Multicast Address (FFfs::00gg:gggg:gggg) 388 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Flags | Scope | Group Identifier | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 DAM = 01. 32-bit Compressed Multicast Address (FFfs:00gg:gggg). 396 1 397 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | Scope | Group Identifier | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 DAM = 10. 16-bit Compressed Multicast Address (FF0s::0ggg). 404 0 1 2 3 4 5 6 7 405 +-+-+-+-+-+-+-+-+ 406 | Group ID | 407 +-+-+-+-+-+-+-+-+ 409 DAM = 11. 8-bit Compressed Multicast Address (FF02::gg). 411 2.2.3. Stateful Multicast Addresses Compression 413 LOWPAN_HC supports stateful compression of multicast addresses when M 414 = 1 and SAC = 1. This document currently defines SAM = 01: context- 415 based compression of Unicast-Prefix-based IPv6 Multicast Addresses 416 [RFC3306][RFC3956]. In particular, the Prefix Length and Network 417 Prefix can be taken from a context. As a result, LOWPAN_HC can 418 compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 419 octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and 420 32-bit Group Identifier in-line. 422 1 2 3 423 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 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Flags | Scope | Reserved | Group Identifier | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Group Identifier | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 DAM = 01. Unicast-Prefix-based IPv6 Multicast Address Compression 432 Note that the Reserved field MUST carry the reserved bits from the 433 multicast address format as described in [RFC3306]. When a 434 Rendezvous Point is encoded in the multicast address as described in 435 [RFC3956], the Reserved field carries the RIID bits in-line. 437 3. IPv6 Next Header Compression 439 LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set 440 to 1. It also indicates the use of 6LoWPAN next header compression, 441 LOWPAN_NHC. The value of IPv6 Next Header is recovered from the 442 first bits in the LOWPAN_NHC encoding. The following bits are 443 specific to the IPv6 Next Header value. Figure 4 shows the structure 444 of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. 446 +-------------+-------------+-------------+-----------------+-------- 447 | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload 448 | Encoding | IP Fields | Encoding | Header Fields | 449 +-------------+-------------+-------------+-----------------+-------- 451 Figure 4: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration 453 3.1. LOWPAN_NHC Format 455 Compression formats for different next headers are identified by a 456 variable length bit-pattern immediately following the LOWPAN_IPHC 457 compressed header. When defining a next header compression format, 458 the number of bits used SHOULD be determined by the perceived 459 frequency of using that format. However, the number of bits and any 460 remaining encoding bits SHOULD respect octet alignment. The 461 following bits are specific to the next header compression format. 462 In this document, we define a compression format for UDP headers. 464 +----------------+--------------------------- 465 | var-len NHC ID | compressed next header... 466 +----------------+--------------------------- 468 Figure 5: LOWPAN_NHC Encoding 470 3.2. UDP Header Compression 472 This document defines a compression format for UDP headers using 473 LOWPAN_NHC. The UDP compression format is shown in Figure 6. Bits 0 474 through 4 represent the NHC ID and '11110' indicates the specific UDP 475 header compression encoding defined in this section. 477 0 1 2 3 4 5 6 7 478 +---+---+---+---+---+---+---+---+ 479 | 1 | 1 | 1 | 1 | 0 | C | P | 480 +---+---+---+---+---+---+---+---+ 482 Figure 6: UDP Header Encoding 484 C: Checksum: 485 0: All 16 bits of Checksum are carried in-line. The Checksum MUST 486 be included if there are no other end-to-end integrity checks 487 that are stronger than what is provided by the UDP checksum. 488 Such an integrity check MUST be end-to-end and cover the IPv6 489 pseudo-header, UDP header, and UDP payload. 490 1: All 16 bits of Checksum are elided. The Checksum is recovered 491 by recomputing it. 493 P: Ports: 494 00: All 16 bits for both Source Port and Destination Port are 495 carried in-line. 496 01: All 16 bits for Source Port are carried in-line. First 8 497 bits of Destination Port is 0xF0 and elided. The remaining 8 498 bits of Destination Port are carried in-line. 499 10: First 8 bits of Source Port are 0xF0 and elided. The 500 remaining 8 bits of Source Port are carried in-line. All 16 501 bits for Destination Port are carried in-line. 502 11: First 12 bits of both Source Port and Destination Port are 503 0xF0B and elided. The remaining 4 bits for each are carried 504 in-line. 506 Fields carried in-line (in part or in whole) appear in the same order 507 as they do in the IPv6 header format [RFC2460]. IPv6 addresses may 508 be compressed to 64 or 16 bits or completely elided. The UDP Length 509 field MUST always be elided and is inferred from lower layers using 510 the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 512 4. IANA Considerations 514 This document defines a new IPv6 header compression format for 515 6LoWPAN networks. The document allocates Dispatch type values of 516 0x08-0x0F (TBD) for LOWPAN_IPHC. 518 5. Security Considerations 520 The definition of LOWPAN_IPHC permits the compression of header 521 information on communication that could take place in its absence, 522 albeit in a less efficient form. It recognizes that a IEEE 802.15.4 523 PAN may have associated with it a number of prefixes through shared 524 context. How the shared context is assigned and managed is beyond 525 the scope of this document. 527 6. Acknowledgements 529 Thanks to Julien Abeille, Carsten Bormann, Christos Polyzois, and Jay 530 Werb for useful feedback and discussion. 532 7. Changes 534 Draft 03: 535 - Decoupled meaning of SAM bits from the destination address. 536 - Have separate bit to indicate multicast address compression. 537 - More extensive support for multicast address compression, 538 including Unicast-Prefix-based Multicast Addresses. 540 Draft 02: 541 - Updated wording with compression mode to clarify that a 542 compression mode does not enforce what kind of destination address 543 is being used. Specifically changed Destination Dependent Field 544 to Compression Mode. 545 - Specify that the configuration and management of contexts is out 546 of scope of this document. 548 Draft 01: 550 - HC back to 1 byte by default by stealing a few bits from the 551 dispatch field. 552 - Added better support for multicast address compression. 553 - Fixed alignment for UDP port compression. 554 - Better support for Traffic Class and Flow Label compression. 555 - Pascal joined as an author. 557 8. References 559 8.1. Normative References 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 565 (IPv6) Specification", RFC 2460, December 1998. 567 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 568 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 569 March 2005. 571 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 572 Architecture", RFC 4291, February 2006. 574 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 575 "Transmission of IPv6 Packets over IEEE 802.15.4 576 Networks", RFC 4944, September 2007. 578 8.2. Informative References 580 [IEEE 802.15.4] 581 IEEE Computer Society, "IEEE Std. 802.15.4-2006", 582 October 2006. 584 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 585 Multicast Addresses", RFC 3306, August 2002. 587 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 588 and M. Carney, "Dynamic Host Configuration Protocol for 589 IPv6 (DHCPv6)", RFC 3315, July 2003. 591 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 592 Point (RP) Address in an IPv6 Multicast Address", 593 RFC 3956, November 2004. 595 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 596 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 597 September 2007. 599 Authors' Addresses 601 Jonathan W. Hui (editor) 602 Arch Rock Corporation 603 501 2nd St. Ste. 410 604 San Francisco, California 94107 605 USA 607 Phone: +415 692 0828 608 Email: jhui@archrock.com 610 Pascal Thubert 611 Cisco Systems 612 Village d'Entreprises Green Side 613 400, Avenue de Roumanille 614 Batiment T3 615 Biot - Sophia Antipolis 06410 616 FRANCE 618 Phone: +33 4 97 23 26 34 619 Email: pthubert@cisco.com 621 Full Copyright Statement 623 Copyright (C) The IETF Trust (2008). 625 This document is subject to the rights, licenses and restrictions 626 contained in BCP 78, and except as set forth therein, the authors 627 retain all their rights. 629 This document and the information contained herein are provided on an 630 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 631 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 632 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 633 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 634 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 637 Intellectual Property 639 The IETF takes no position regarding the validity or scope of any 640 Intellectual Property Rights or other rights that might be claimed to 641 pertain to the implementation or use of the technology described in 642 this document or the extent to which any license under such rights 643 might or might not be available; nor does it represent that it has 644 made any independent effort to identify any such rights. Information 645 on the procedures with respect to rights in RFC documents can be 646 found in BCP 78 and BCP 79. 648 Copies of IPR disclosures made to the IETF Secretariat and any 649 assurances of licenses to be made available, or the result of an 650 attempt made to obtain a general license or permission for the use of 651 such proprietary rights by implementers or users of this 652 specification can be obtained from the IETF on-line IPR repository at 653 http://www.ietf.org/ipr. 655 The IETF invites any interested party to bring to its attention any 656 copyrights, patents or patent applications, or other proprietary 657 rights that may cover technology that may be required to implement 658 this standard. Please address the information to the IETF at 659 ietf-ipr@ietf.org.