idnits 2.17.1 draft-ietf-6lowpan-hc-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. (Using the creation date from RFC4944, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2011) is 4819 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCthis' is mentioned on line 863, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 3 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: August 18, 2011 February 14, 2011 8 Compression Format for IPv6 Datagrams in Low Power and Lossy Networks 9 (6LoWPAN) 10 draft-ietf-6lowpan-hc-14 12 Abstract 14 This document updates RFC 4944, "Transmission of IPv6 Packets over 15 IEEE 802.15.4 Networks". This document specifies an IPv6 header 16 compression format for IPv6 packet delivery in Low Power and Lossy 17 Networks (6LoWPANs). The compression format relies on shared context 18 to allow compression of arbitrary prefixes. How the information is 19 maintained in that shared context is out of scope. This document 20 specifies compression of multicast addresses and a framework for 21 compressing next headers. UDP header compression is specified within 22 this framework. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 18, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 60 2. Specific Updates to RFC 4944 . . . . . . . . . . . . . . . . . 4 61 3. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 5 62 3.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 6 63 3.1.1. Base Format . . . . . . . . . . . . . . . . . . . . . 6 64 3.1.2. Context Identifier Extension . . . . . . . . . . . . . 9 65 3.2. IPv6 Header Encoding . . . . . . . . . . . . . . . . . . . 10 66 3.2.1. Traffic Class and Flow Label Compression . . . . . . . 10 67 3.2.2. Deriving IIDs from the Encapsulating Header . . . . . 11 68 3.2.3. Stateless Multicast Address Compression . . . . . . . 12 69 3.2.4. Stateful Multicast Address Compression . . . . . . . . 13 70 4. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 14 71 4.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 14 72 4.2. IPv6 Extension Header Compression . . . . . . . . . . . . 15 73 4.3. UDP Header Compression . . . . . . . . . . . . . . . . . . 16 74 4.3.1. Compressing UDP ports . . . . . . . . . . . . . . . . 17 75 4.3.2. Compressing UDP checksum . . . . . . . . . . . . . . . 17 76 4.3.3. UDP LOWPAN_NHC Format . . . . . . . . . . . . . . . . 19 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 80 8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 83 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 86 1. Introduction 88 The [IEEE 802.15.4] standard specifies an MTU of 127 bytes, yielding 89 about 80 octets of actual Media Access Control (MAC) payload with 90 security enabled, on a wireless link with a link throughput of 250 91 kbps or less. The 6LoWPAN adaptation format [RFC4944] was specified 92 to carry IPv6 datagrams over such constrained links, taking into 93 account limited bandwidth, memory, or energy resources that are 94 expected in applications such as wireless sensor networks. [RFC4944] 95 defines a Mesh Addressing header to support sub-IP forwarding, a 96 Fragmentation header to support the IPv6 minimum MTU requirement 97 [RFC2460], and stateless header compression for IPv6 datagrams 98 (LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large IPv6 and 99 UDP headers down to (in the best case) several bytes. 101 LOWPAN_HC1 and LOWPAN_HC2 are insufficient for most practical uses of 102 IPv6 in Low Power and Lossy Networks (6LoWPANs). LOWPAN_HC1 is most 103 effective for link-local unicast communication, where IPv6 addresses 104 carry the link-local prefix and an Interface Identifier (IID) 105 directly derived from IEEE 802.15.4 addresses. In this case, both 106 addresses may be completely elided. However, though link-local 107 addresses are commonly used for local protocol interactions such as 108 IPv6 Neighbor Discovery [RFC4861], DHCPv6 [RFC3315] or routing 109 protocols, they are usually not used for application-layer data 110 traffic, so the actual value of this compression mechanism is 111 limited. 113 Routable addresses must be used when communicating with devices 114 external to the 6LoWPAN or in a route-over configuration where IP 115 forwarding occurs within the 6LoWPAN. For routable addresses, 116 LOWPAN_HC1 requires both IPv6 source and destination addresses to 117 carry the prefix in-line. In cases where the Mesh Addressing header 118 is not used, the IID of a routable address must be carried in-line. 119 However, LOWPAN_HC1 requires 64-bits for the IID when carried in-line 120 and cannot be shortened even when it is derived from the IEEE 121 802.15.4 16-bit short address. When the destination is an IPv6 122 multicast address, LOWPAN_HC1 requires the full 128-bit address to be 123 carried in-line. 125 As a result, this document defines an encoding format, LOWPAN_IPHC, 126 for effective compression of Unique Local, Global, and multicast IPv6 127 Addresses based on shared state within contexts. In addition, this 128 document also introduces a number of additional improvements over the 129 header compression format defined in [RFC4944]. 131 LOWPAN_IPHC allows for compression of some commonly-used IPv6 Hop 132 Limit values. If the 6LoWPAN is a mesh-under stub, a Hop Limit of 1 133 for inbound and a default value such as 64 for outbound are usually 134 enough for application layer data traffic. Additionally, a hop-limit 135 value of 255 is often used to verify that a communication occurs over 136 a single-hop. This specification enables compression of the IPv6 Hop 137 Limit field in those common cases, whereas LOWPAN_HC1 does not. 139 This document also defines LOWPAN_NHC, an encoding format for 140 arbitrary next headers. LOWPAN_IPHC indicates whether the following 141 header is encoded using LOWPAN_NHC. If so, the bits immediately 142 following the compressed IPv6 header start the LOWPAN_NHC encoding. 143 In contrast, LOWPAN_HC1 could be extended to support compression of 144 next headers using LOWPAN_HC2, but only for UDP, TCP, and ICMPv6. 145 Furthermore, the LOWPAN_HC2 octet sits between the LOWPAN_HC1 octet 146 and uncompressed IPv6 header fields. This specification moves the 147 next header encoding bits to follow all IPv6-related bits, allowing 148 for a properly layered structure and direct support for IPv6 149 extension headers. 151 Using LOWPAN_NHC, this document defines a compression mechanism for 152 UDP. While [RFC4944] defines a compression mechanism for UDP, that 153 mechanism does not enable checksum compression when rendered possible 154 by additional upper layer mechanisms such as upper layer Message 155 Integrity Check (MIC). This specification adds the capability to 156 elide the UDP checksum over the 6LoWPAN, which enables saving of a 157 further two octets. 159 Also using LOWPAN_NHC, this document defines encoding formats for 160 IPv6-in-IPv6 encapsulation as well as IPv6 Extension Headers. With 161 LOWPAN_HC1 and LOWPAN_HC2, chains of next headers cannot be encoded 162 efficiently. 164 1.1. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in RFC 2119 [RFC2119]. 170 2. Specific Updates to RFC 4944 172 This document specifies a header compression format that is intended 173 to replace that defined in Section 10 of [RFC4944]. Implementation 174 of Section 10 of [RFC4944] is now NOT RECOMMENDED. New 175 implementations MAY implement decompression according to Section 10 176 of [RFC4944], but SHOULD NOT send packets compressed according to 177 Section 10 of [RFC4944]. 179 A compliant implementation of [RFC4944] as updated by this document 180 MUST be able to properly process a packet received that makes use of 181 the provisions of this document. A compliant implementation MAY 182 implement additional LOWPAN_NHC types (Section 4) that may be 183 registered (Section 5) in the future. It is out of scope of this 184 document how a compressor learns that a decompressor has additional 185 capabilities. 187 Section 5.3 of [RFC4944] also defines how to fragment compressed IPv6 188 datagrams that do not fit within a single link frame. Section 5.3 of 189 [RFC4944] defines the fragment header's datagram_size and 190 datagram_offset values as the size and offset of the IPv6 datagram 191 before compression. As a result, all fragment payload outside the 192 first fragment must carry their respective portions of the IPv6 193 datagram before compression. This document does not change that 194 requirement. When using the fragmentation mechanism described in 195 Section 5.3 of [RFC4944], any header that cannot fit within the first 196 fragment MUST NOT be compressed. 198 The header compression format defined in this document preempts the 199 ESC dispatch value defined in Section 5.1 of [RFC4944]. Instead, the 200 value of 01 000000 is reserved as a replacement value for ESC, to be 201 finally assigned with the first assignment of extension bytes. 203 3. IPv6 Header Compression 205 In this section, we define the LOWPAN_IPHC encoding format for 206 compressing the IPv6 header. To enable effective compression 207 LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN. 208 LOWPAN_IPHC assumes the following will be the common case for 6LoWPAN 209 communication: Version is 6; Traffic Class and Flow Label are both 210 zero; Payload Length can be inferred from lower layers from either 211 the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; Hop 212 Limit will be set to a well-known value by the source; addresses 213 assigned to 6LoWPAN interfaces will be formed using the link-local 214 prefix or a small set of routable prefixes assigned to the entire 215 6LoWPAN; addresses assigned to 6LoWPAN interfaces are formed with an 216 IID derived directly from either the 64-bit extended or 16-bit short 217 IEEE 802.15.4 addresses. 219 +-------------------------------------+---------------------------- 220 | Dispatch + LOWPAN_IPHC (2-3 octets) | In-line IPv6 Header Fields 221 +-------------------------------------+---------------------------- 223 Figure 1: LOWPAN_IPHC Header 225 The LOWPAN_IPHC encoding utilizes 13 bits, 5 of which are taken from 226 the rightmost bit of the dispatch type. The encoding may be extended 227 by another octet to support additional contexts. Any information 228 from the uncompressed IPv6 header fields carried in-line follow the 229 LOWPAN_IPHC encoding, as shown in Figure 1. In the best case, the 230 LOWPAN_IPHC can compress the IPv6 header down to two octets (the 231 dispatch octet and the LOWPAN_IPHC encoding) with link-local 232 communication. 234 When routing over multiple IP hops, LOWPAN_IPHC can compress the IPv6 235 header down to 7 octets (1-octet dispatch, 1-octet LOWPAN_IPHC, 236 1-octet Hop Limit, 2-octet Source Address, and 2-octet Destination 237 Address). The Hop Limit may not be compressed because it needs to 238 decremented at each hop and may take any value. Stateful address 239 compression must be applied to the source and destination IPv6 240 addresses because they do not statelessly match the source and 241 destination link layer addresses on intermediate hops. 243 3.1. LOWPAN_IPHC Encoding Format 245 This section specifies the format of the LOWPAN_IPHC encoding that 246 describes how an IPv6 header is compressed. The encoding can be 2 247 octets long for the base encoding or 3 octets long when an additional 248 context encoding is present. The IPv6 header fields that are not 249 fully elided are placed immediately after the LOWPAN_IPHC, either in 250 a compressed form if the field is partially elided, or literally. 252 3.1.1. Base Format 254 0 1 255 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 256 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 257 | 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM | 258 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 260 Figure 2: LOWPAN_IPHC base Encoding 262 TF: Traffic Class, Flow Label: As specified in [RFC3168], the 8-bit 263 IPv6 Traffic Class field is split into two fields: 2-bit Explicit 264 Congestion Notification (ECN) and 6-bit Differentiated Services 265 Code Point (DSCP). 266 00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes) 267 01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided 268 10: ECN + DSCP (1 byte), Flow Label is elided 269 11: Traffic Class and Flow Label are elided. 270 NH: Next Header: 271 0: Full 8 bits for Next Header are carried in-line. 272 1: The Next Header field is compressed and the next header is 273 encoded using LOWPAN_NHC, which is discussed in Section 4.1. 275 HLIM: Hop Limit: 276 00: The Hop Limit field is carried in-line. 277 01: The Hop Limit field is compressed and the hop limit is 1. 278 10: The Hop Limit field is compressed and the hop limit is 64. 279 11: The Hop Limit field is compressed and the hop limit is 255. 281 CID: Context Identifier Extension: 282 0: No additional 8-bit Context Identifier Extension is used. If 283 context-based compression is specified in either SAC or DAC, 284 context 0 is used. 285 1: An additional 8-bit Context Identifier Extension field 286 immediately follows the DAM field. 288 SAC: Source Address Compression 289 0: Source address compression uses stateless compression. 290 1: Source address compression uses stateful, context-based 291 compression. 293 SAM: Source Address Mode: 294 If SAC=0: 295 00: 128 bits. The full address is carried in-line. 296 01: 64 bits. The first 64-bits of the address are elided. 297 The value of those bits is the link-local prefix padded with 298 zeros. The remaining 64 bits are carried in-line. 299 10: 16 bits. The first 112 bits of the address are elided. 300 The value of the first 64 bits is the link-local prefix 301 padded with zeros. The following 64 bits are 0000:00ff: 302 fe00:XXXX, where XXXX are the 16 bits carried in-line. 303 11: 0 bits. The address is fully elided. The first 64 bits 304 of the address are the link-local prefix padded with zeros. 305 The remaining 64 bits are computed from the encapsulating 306 header (e.g. 802.15.4 or IPv6 source address) as specified 307 in Section 3.2.2. 308 If SAC=1: 309 00: The UNSPECIFIED address, :: 310 01: 64 bits. The address is derived using context information 311 and the 64 bits carried in-line. Bits covered by context 312 information are always used. Any IID bits not covered by 313 context information are taken directly from the 314 corresponding bits carried in-line. Any remaining bits are 315 zero. 317 10: 16 bits. The address is derived using context information 318 and the 16 bits carried in-line. Bits covered by context 319 information are always used. Any IID bits not covered by 320 context information are taken directly from their 321 corresponding bits in the 16-bit to IID mapping given by 322 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in- 323 line. Any remaining bits are zero. 324 11: 0 bits. The address is fully elided and is derived using 325 context information and the encapsulating header (e.g. 326 802.15.4 or IPv6 source address). Bits covered by context 327 information are always used. Any IID bits not covered by 328 context information are computed from the encapsulating 329 header as specified in Section 3.2.2. Any remaining bits 330 are zero. 332 M: Multicast Compression 333 0: Destination address is not a multicast address. 334 1: Destination address is a multicast address. 336 DAC: Destination Address Compression 337 0: Destination address compression uses stateless compression. 338 1: Destination address compression uses stateful, context-based 339 compression. 341 DAM: Destination Address Mode: 342 If M=0 and DAC=0 This case matches SAC=0 but for the destination 343 address: 344 00: 128 bits. The full address is carried in-line. 345 01: 64 bits. The first 64-bits of the address are elided. 346 The value of those bits is the link-local prefix padded with 347 zeros. The remaining 64 bits are carried in-line. 348 10: 16 bits. The first 112 bits of the address are elided. 349 The value of the first 64 bits is the link-local prefix 350 padded with zeros. The following 64 bits are 0000:00ff: 351 fe00:XXXX, where XXXX are the 16 bits carried in-line. 352 11: 0 bits. The address is fully elided. The first 64 bits 353 of the address are the link-local prefix padded with zeros. 354 The remaining 64 bits are computed from the encapsulating 355 header (e.g. 802.15.4 or IPv6 destination address) as 356 specified in Section 3.2.2. 357 If M=0 and DAC=1: 358 00: Reserved. 359 01: 64 bits. The address is derived using context information 360 and the 64 bits carried in-line. Bits covered by context 361 information are always used. Any IID bits not covered by 362 context information are taken directly from the 363 corresponding bits carried in-line. Any remaining bits are 364 zero. 366 10: 16 bits. The address is derived using context information 367 and the 16 bits carried in-line. Bits covered by context 368 information are always used. Any IID bits not covered by 369 context information are taken directly from their 370 corresponding bits in the 16-bit to IID mapping given by 371 0000:00ff:fe00:XXXX, where XXXX are the 16 bits carried in- 372 line. Any remaining bits are zero. 373 11: 0 bits. The address is fully elided and is derived using 374 context information and the encapsulating header (e.g. 375 802.15.4 or IPv6 destination address). Bits covered by 376 context information are always used. Any IID bits not 377 covered by context information are computed from the 378 encapsulating header as specified in Section 3.2.2. Any 379 remaining bits are zero. 380 If M=1 and DAC=0: 381 00: 128 bits. The full address is carried in-line. 382 01: 48 bits. The address takes the form FFXX::00XX:XXXX:XXXX. 383 10: 32 bits. The address takes the form FFXX::00XX:XXXX. 384 11: 8 bits. The address takes the form FF02::00XX. 385 If M=1 and DAC=1: 386 00: 48 bits. This format is designed to match Unicast-Prefix- 387 based IPv6 Multicast Addresses as defined in [RFC3306] and 388 [RFC3956]. The multicast address takes the form FFXX:XXLL: 389 PPPP:PPPP:PPPP:PPPP:XXXX:XXXX. where the X are the nibbles 390 that are carried in-line, in the order in which they appear 391 in this format. P denotes nibbles used to encode the prefix 392 itself. L denotes nibbles used to encode the prefix length. 393 The prefix information P and L is taken from the specified 394 context. 395 01: reserved 396 10: reserved 397 11: reserved 399 3.1.2. Context Identifier Extension 401 This specification expects that a conceptual context is shared 402 between the node that compresses a packet and the node(s) that need 403 to expand it. How the contexts are shared and maintained is out of 404 scope. What information is contained within a context information is 405 out of scope. Actions in response to unknown and/or invalid contexts 406 are out of scope. The specification enables a node to use up to 16 407 contexts. The context used to encode the source address does not 408 have to be the same as the context used to encode the destination 409 address. 411 If the CID field is set to '1' in the LOWPAN_IPHC encoding, then an 412 additional octet extends the LOWPAN_IPHC encoding following the DAM 413 bits but before the IPv6 header fields that are carried in-line. The 414 additional octet identifies the pair of contexts to be used when the 415 IPv6 source and/or destination address is compressed. The context 416 identifier is 4 bits for each address, supporting up to 16 contexts. 417 Context 0 is the default context. The encoding is shown in Figure 3. 419 0 1 2 3 4 5 6 7 420 +---+---+---+---+---+---+---+---+ 421 | SCI | DCI | 422 +---+---+---+---+---+---+---+---+ 424 Figure 3: LOWPAN_IPHC Encoding 426 SCI: Source Context Identifier Identifies the prefix that is used 427 when the IPv6 source address is statefully compressed. 428 DCI: Destination Context Identifier Identifies the prefix that is 429 used when the IPv6 destination address is statefully compressed. 431 3.2. IPv6 Header Encoding 433 Fields carried in-line (in part or in whole) appear in the same order 434 as they do in the IPv6 header format [RFC2460]. The Version field is 435 always elided. Unicast IPv6 addresses may be compressed to 64 or 16 436 bits or completely elided. Multicast IPv6 addresses may be 437 compressed to 8, 32, or 48 bits. The IPv6 Payload Length field MUST 438 always be elided and inferred from lower layers using the 6LoWPAN 439 Fragmentation header or the IEEE 802.15.4 header. 441 3.2.1. Traffic Class and Flow Label Compression 443 The Traffic Class field in the IPv6 header comprises 6 bits of 444 diffserv extension [RFC2474] and 2 bits of Explicit Congestion 445 Notification (ECN) [RFC3168]. The TF field in the LOWPAN_IPHC 446 encoding indicates whether the Traffic Class and Flow Label are 447 carried in-line in the compressed IPv6 header. When Flow Label is 448 included while the Traffic Class is compressed, an additional 4 bits 449 are included to maintain byte-alignment. Two of the 4 bits contain 450 the ECN bits from the Traffic Class field. 452 To ensure that the ECN bits appear in the same location for all 453 encodings that include them, the Traffic Class field is rotated right 454 by 2 bits in the compressed IPv6 header. The encodings are shown 455 below: 457 1 2 3 458 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 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 |ECN| DSCP | rsv | Flow Label | 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 Figure 4: TF = 00: Traffic Class and Flow Label carried in-line. 465 1 2 466 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 |ECN|rsv| Flow Label | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 5: TF = 01: Flow Label carried in-line. 473 0 1 2 3 4 5 6 7 474 +-+-+-+-+-+-+-+-+ 475 |ECN| DSCP | 476 +-+-+-+-+-+-+-+-+ 478 Figure 6: TF = 10: Traffic Class carried in-line. 480 3.2.2. Deriving IIDs from the Encapsulating Header 482 LOWPAN_IPHC elides the IIDs of source or destination addresses when 483 SAM = 3 or DAM = 3, respectively. In this mode, the IID is derived 484 from the encapsulating header. When the encapsulating header carries 485 IPv6 addresses, bits for the source and destination addresses are 486 copied from the source and destination addresses of the encapsulating 487 IPv6 header. 489 The remainder of this section defines the mapping from IEEE 802.15.4 490 [IEEE 802.15.4] link-layer addresses to IIDs for both short and 491 extended IEEE 802.15.4 addresses. IID bits not covered by the 492 context information MAY be elided if they match the link-layer 493 address mapping and MUST NOT be elided if they do not. 495 An extended IEEE 802.15.4 address takes the form of an IEEE EUI-64 496 address. Generating an IID from an extended address is identical to 497 that defined in Appendix A of [RFC4291]. The only change needed to 498 transform an IEEE EUI-64 identifier to an interface identifier is to 499 invert the universal/local bit. 501 A short IEEE 802.15.4 address is 16 bits in length. Short addresses 502 are mapped into the restricted space of IEEE EUI-64 addresses by 503 setting the middle 16 bits to 0xfffe, the bottom 16 bits to the short 504 address, and all other bits to zero. As a result, an IID generated 505 from a short address has the form: 507 0000:00ff:fe00:XXXX 509 where XXXX carries the short address. The universal/local bit is 510 zero to indicate local scope. 512 This mapping for non-EUI-64 identifiers differs from that presented 513 in Appendix A of [RFC4291]. Using the restricted space ensures no 514 overlap with IIDs generated from unrestricted IEEE EUI-64 addresses. 515 Also, including 0xfffe in the middle of the IID helps avoid overlap 516 with other locally managed IIDs. 518 This mapping from a short IEEE 802.15.4 address to 64-bit IIDs is 519 also used to reconstruct any part of an IID not covered by context 520 information. 522 3.2.3. Stateless Multicast Address Compression 524 LOWPAN_IPHC supports stateless compression of multicast addresses 525 when M = 1 and DAC = 0. An IPv6 multicast address may be compressed 526 down to 48, 32, or 8 bits using stateless compression. The format 527 supports compression of the Solicited-Node Multicast Address (FF02:: 528 1:FFXX:XXXX) as well as any IPv6 multicast address where the upper 529 bits of the multicast group identifier are zero. The 8-bit 530 compressed form only carries the least-significant bits of the 531 multicast group identifier. The 48 and 32-bit compressed forms carry 532 the multicast scope and flags in-line, in addition to the least- 533 significant bits of the multicast group identifier. 535 1 2 3 536 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 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Flags | Scope | Group Identifier | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Group Identifier | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 7: DAM = 01. 48-bit Compressed Multicast Address (FFfs::00gg: 544 gggg:gggg) 546 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Flags | Scope | Group Identifier | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Figure 8: DAM = 10. 32-bit Compressed Multicast Address (FFfs::00gg: 553 gggg). 555 0 1 2 3 4 5 6 7 556 +-+-+-+-+-+-+-+-+ 557 | Group ID | 558 +-+-+-+-+-+-+-+-+ 560 Figure 9: DAM = 11. 8-bit Compressed Multicast Address (FF02::gg). 562 3.2.4. Stateful Multicast Address Compression 564 LOWPAN_IPHC supports stateful compression of multicast addresses when 565 M = 1 and DAC = 1. This document currently defines DAM = 00: 566 context-based compression of Unicast-Prefix-based IPv6 Multicast 567 Addresses [RFC3306][RFC3956]. In particular, the Prefix Length and 568 Network Prefix can be taken from a context. As a result, LOWPAN_IPHC 569 can compress a Unicast-Prefix-based IPv6 Multicast Address down to 6 570 octets by only carrying the 4-bit Flags, 4-bit Scope, 8-bit RIID, and 571 32-bit Group Identifier in-line. 573 1 2 3 574 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 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Flags | Scope | Rsvd / RIID | Group Identifier | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Group Identifier | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 Figure 10: DAM = 00. Unicast-Prefix-based IPv6 Multicast Address 582 Compression 584 Note that the Reserved field MUST carry the reserved bits from the 585 multicast address format as described in [RFC3306]. When a 586 Rendezvous Point is encoded in the multicast address as described in 587 [RFC3956], the Reserved field carries the RIID bits in-line. 589 4. IPv6 Next Header Compression 591 LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set 592 to 1. This also indicates the use of 6LoWPAN next header 593 compression, LOWPAN_NHC. The value of IPv6 Next Header is recovered 594 from the first bits in the LOWPAN_NHC encoding. The following bits 595 are specific to the IPv6 Next Header value. Figure 11 shows the 596 structure of an IPv6 datagram compressed using LOWPAN_IPHC and 597 LOWPAN_NHC. 599 +-------------+-------------+-------------+-----------------+-------- 600 | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload 601 | Encoding | IP Fields | Encoding | Header Fields | 602 +-------------+-------------+-------------+-----------------+-------- 604 Figure 11: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration 606 4.1. LOWPAN_NHC Format 608 Compression formats for different next headers are identified by a 609 variable-length bit-pattern immediately following the LOWPAN_IPHC 610 compressed header. When defining a next header compression format, 611 the number of bits used SHOULD be determined by the perceived 612 frequency of using that format. However, the number of bits and any 613 remaining encoding bits SHOULD respect octet alignment. The 614 following bits are specific to the next header compression format. 615 This document defines a compression format for IPv6 Extension and UDP 616 headers. 618 +----------------+--------------------------- 619 | var-len NHC ID | compressed next header... 620 +----------------+--------------------------- 622 Figure 12: LOWPAN_NHC Encoding 624 4.2. IPv6 Extension Header Compression 626 A necessary property of encoding headers using LOWPAN_NHC is that the 627 immediately preceding header must either be encoded using LOWPAN_IPHC 628 or LOWPAN_NHC. In other words, all headers encoded using the 6LoWPAN 629 encoding format defined in this document must be contiguous. As a 630 result, this document defines a set of LOWPAN_NHC encodings for 631 selected IPv6 Extension Headers such that the UDP Header Compression 632 defined in Section 4.3 may be used in the presence of those extension 633 headers. 635 The LOWPAN_NHC encodings for IPv6 Extension Headers are composed of a 636 single LOWPAN_NHC octet followed by the IPv6 Extension Header. The 637 format of the LOWPAN_NHC octet is shown in Figure 13. The first 7 638 bits serve as an identifier for the IPv6 Extension Header immediately 639 following the LOWPAN_NHC octet. The remaining bit indicates whether 640 or not the following header utilizes LOWPAN_NHC encoding. 642 0 1 2 3 4 5 6 7 643 +---+---+---+---+---+---+---+---+ 644 | 1 | 1 | 1 | 0 | EID |NH | 645 +---+---+---+---+---+---+---+---+ 647 Figure 13: IPv6 Extension Header Encoding 649 EID: IPv6 Extension Header ID: 650 0: IPv6 Hop-by-Hop Options Header[RFC2460] 651 1: IPv6 Routing Header[RFC2460] 652 2: IPv6 Fragment Header[RFC2460] 653 3: IPv6 Destination Options Header[RFC2460] 654 4: IPv6 Mobility Header [RFC3775] 655 5: Reserved 656 6: Reserved 657 7: IPv6 Header 659 NH: Next Header: 660 0: Full 8 bits for Next Header are carried in-line. 661 1: The Next Header field is elided and the next header is encoded 662 using LOWPAN_NHC, which is discussed in Section 4.1. 664 For the most part, the IPv6 Extension Header is carried unmodified in 665 the bytes immediately following the LOWPAN_NHC octet, with two 666 important exceptions: Length Field and Next Header Field. 668 The Next Header Field contained in IPv6 Extension Headers is elided 669 when the NH bit is set in the LOWPAN_NHC encoding octet. Note that 670 doing so allows LOWPAN_NHC to utilize no more overhead than the non- 671 encoded IPv6 Extension Header. 673 The Length Field contained in a compressed IPv6 Extension Header 674 indicates the number of octets that pertain to the (compressed) 675 extension header following the Length Field. Note that this changes 676 the Length Field definition in [RFC2460] from indicating the header 677 size in 8-octet units, not including the first 8 octets. Changing 678 the Length Field to be in units of octets removes wasteful internal 679 fragmentation. 681 IPv6 Hop-by-Hop and Destination Options Headers may use a trailing 682 Pad1 or PadN to achieve 8-octet alignment. When there is a single 683 trailing Pad1 or PadN option of 7 octets or less and the containing 684 header is a multiple of 8 octets, the trailing Pad1 or PadN option 685 MAY be elided by the compressor. A decompressor MUST ensure that the 686 containing header is padded out to a multiple of 8 octets in length, 687 using a Pad1 or PadN option if necessary. Note that Pad1 and PadN 688 options that appear in locations other than the end MUST be carried 689 in-line as they are used to align subsequent options. 691 Note that specifying units in octets means that LOWPAN_NHC MUST NOT 692 be used to encode IPv6 Extension Headers that have more than 255 693 octets following the Length Field after compression. 695 When the identified next header is an IPv6 Header (EID=7), the NH bit 696 of the LOWPAN_NHC encoding is unused and MUST be set to zero. The 697 following bytes MUST be encoded using LOWPAN_IPHC as defined in 698 Section 3. 700 4.3. UDP Header Compression 702 This document defines a compression format for UDP headers using 703 LOWPAN_NHC. The UDP compression format is shown in Figure 14. Bits 704 0 through 4 represent the NHC ID and '11110' indicates the specific 705 UDP header compression encoding defined in this section. 707 4.3.1. Compressing UDP ports 709 This specification allows a particular range of ports number (0xF0B0 710 to 0xF0BF) to be compressed down to 4 bits. This is a stateless 711 compression that is inherited from [RFC4944], as opposed to a new 712 stateful compression. 714 The range of ports compressible down to 4 bits is not in a reserved 715 range. A network stack implementation that is designed to 716 communicate over a 6LoWPAN should avoid using those ports as dynamic 717 ports whenever possible. 719 Considering that this represents only 16 contiguous ports, it can be 720 expected that many incompatible applications will use the same value 721 of port numbers for their own end-to-end needs. Thus a port number 722 in the (0xF0B0 to 0xF0BF) range provides very little information 723 about the application at the remote end. 725 The overloading of the 0xF0Bx ports increases the risk of getting the 726 wrong type of payload and misinterpreting the content compared to 727 ports that are reserved at IANA. As a result, it is recommended that 728 the use of those ports be associated with a mechanism such as a 729 Transport Layer Security (TLS) [RFC5246] Message Integrity Check 730 (MIC) that makes sure that the content is what is expected and is 731 checked. 733 4.3.2. Compressing UDP checksum 735 The UDP checksum operation is mandatory with IPv6 [RFC2460] for all 736 packets. For that reason [RFC4944] disallows the compression of the 737 UDP checksum. 739 With this specification, a compressor in the source transport 740 endpoint MAY elide the UDP Checksum if it is authorized by the Upper 741 Layer. The compressor MUST NOT set the C bit unless it has received 742 such authorization. Requiring Upper Layer authorization ensures that 743 the intended transport peer will have sufficient means to deal with 744 any data corruption that occurs before reaching the destination. The 745 Upper Layer MAY only provide the authorization in the following 746 cases: 748 Tunneling: In this case, 6LoWPAN is deployed as a wireless pseudo- 749 fieldbus by tunneling existing field protocols over UDP. If the 750 tunneled Protocol Data Unit (PDU) possesses its own addressing, 751 security and integrity check (e.g. IPsec Encapsulating Security 752 Payload tunnel mode [RFC4303] or IP over UDP encapsulation), the 753 tunneling mechanism MAY authorize to elide the UDP checksum in 754 order to save on the encapsulation overhead. 756 Message Integrity Check: In this case, either IPsec Authentication 757 Header [RFC4302] or some other form of integrity check in the UDP 758 payload that covers at least the same information as the UDP 759 checksum (pseudo-header, data) and has at least the same strength. 761 To help ensure that the UDP Checksum will be properly restored when 762 expanding a 6LoWPAN packet, an additional integrity check (e.g. L2 763 Message Integrity Check) MUST be used whenever transmitting link 764 frames that carry a compressed UDP datagram that elides the checksum. 765 Without this additional integrity check, a UDP packet may be 766 delivered to an unintended destination since corruption in data 767 covered by the pseudo-header can go undetected. 769 A compressor MUST verify the UDP Checksum before it is elided and 770 SHOULD ensure that the additional integrity check is in place before 771 verifying and eliding the checksum. If verification of the UDP 772 Checksum fails, the compressor MUST drop the packet. 774 A decompressor that expands a 6LoWPAN packet with the C bit set MUST 775 compute the UDP Checksum on behalf of the source node and place that 776 value in the restored UDP header as specified in the incumbent 777 standards [RFC0768], [RFC2460]. The decompressor MUST unambiguously 778 determine that an additional integrity check was put in place by the 779 compressor and verify the integrity check, and SHOULD do so after 780 restoring the UDP Checksum. If the decompressor cannot unambiguously 781 determine the presence of an integrity check or verification fails, 782 the decompressor MUST drop the packet. 784 The recommended ordering of computing and verify the UDP Checksum and 785 additional integrity check ensures that data is never stored 786 unprotected in memory. In practice, functionality separation between 787 layers may preclude the recommended ordering. However, implementors 788 should take special note and understand the risks when dealing with 789 unprotected data covered by the pseudo-header. 791 To allow intermediate nodes to compress the UDP Checksum, a 792 forwarding node MAY infer Upper Layer authorization for an incoming 793 packet if it has the C bit set and it can unambiguously determine 794 that an integrity check covering the same data as the UDP Checksum 795 was in place while the UDP Checksum was elided. A forwarding node 796 MUST NOT infer authorization if it cannot unambiguously determine the 797 presence of and verify an integrity check while the UDP Checksum was 798 elided. 800 4.3.3. UDP LOWPAN_NHC Format 802 0 1 2 3 4 5 6 7 803 +---+---+---+---+---+---+---+---+ 804 | 1 | 1 | 1 | 1 | 0 | C | P | 805 +---+---+---+---+---+---+---+---+ 807 Figure 14: UDP Header Encoding 809 C: Checksum: 810 0: All 16 bits of Checksum are carried in-line. 811 1: All 16 bits of Checksum are elided. The Checksum is recovered 812 by recomputing it on the 6LoWPAN termination point. 814 P: Ports: 815 00: All 16 bits for both Source Port and Destination Port are 816 carried in-line. 817 01: All 16 bits for Source Port are carried in-line. First 8 818 bits of Destination Port is 0xF0 and elided. The remaining 8 819 bits of Destination Port are carried in-line. 820 10: First 8 bits of Source Port are 0xF0 and elided. The 821 remaining 8 bits of Source Port are carried in-line. All 16 822 bits for Destination Port are carried in-line. 823 11: First 12 bits of both Source Port and Destination Port are 824 0xF0B and elided. The remaining 4 bits for each are carried 825 in-line. 827 Fields carried in-line (in part or in whole) appear in the same order 828 as they do in the UDP header format [RFC0768]. The UDP Length field 829 MUST always be elided and is inferred from lower layers using the 830 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 832 5. IANA Considerations 834 This document defines a new IPv6 header compression format for 835 6LoWPAN. The document allocates the following 32 Dispatch type field 836 values for LOWPAN_IPHC: 838 01 100000 839 through 840 01 111111 842 This assignment preempts the assignment of 01 111111 for ESC 843 [RFC4944], which is possible as no extension bytes have been 844 allocated yet that would enable the use of ESC. Instead, the value: 846 01 000000 848 is reserved as a replacement value for ESC, to be finally assigned 849 with the first assignment of extension bytes. 851 This document also creates a new IANA registry for the LOWPAN_NHC 852 header type, with the following initial content: 854 00000000 to 11011111: (unassigned) 855 1110000N: IPv6 Hop-by-Hop Options Header [RFCthis] 856 1110001N: IPv6 Routing Header [RFCthis] 857 1110010N: IPv6 Fragment Header [RFCthis] 858 1110011N: IPv6 Destination Options Header [RFCthis] 859 1110100N: IPv6 Mobility Header [RFCthis] 860 1110101N: (Reserved for future extension headers) 861 1110110N: (Reserved for future extension headers) 862 1110111N: IPv6 Header [RFCthis] 863 11110CPP: UDP Header [RFCthis] 864 11111000 to 11111110: (unassigned) 865 11111111: (unassigned, reserved for extensions) 867 Capital letters in bit positions represent class-specific bit 868 assignments. N indicates whether or not additional LOWPAN_NHC 869 encodings follow, as defined in Section 4.2. CPP represents 870 variables specific to UDP header compression defined in Section 4.3. 872 The policy for this registry [RFC5226] is IETF Review. In this 873 process, new values SHOULD be assigned in a way that preserves the 874 NHC ID abstraction of Section 4 (i.e., k one-bits followed by one 875 zero-bit identify the general class of NHC, followed by class- 876 specific bit assignments). 878 6. Security Considerations 880 The definition of LOWPAN_IPHC permits the compression of header 881 information on communication that could take place in its absence, 882 albeit in a less efficient form. It recognizes that a IEEE 802.15.4 883 PAN may have associated with it a number of prefixes through shared 884 context. How the shared context is assigned and managed is beyond 885 the scope of this document. 887 The overloading of the 0xF0Bx ports increases the risk of getting the 888 wrong type of payload and misinterpreting the content compared to 889 ports that reserved at IANA. It is thus recommended that the use of 890 those ports be associated with a mechanism such as a Transport Layer 891 Security (TLS) [RFC5246] Message Integrity Check (MIC) that validates 892 that the content is expected and checked for integrity. 894 7. Acknowledgements 896 Thanks to Julien Abeille, Robert Assimiti, Dominique Barthel, Carsten 897 Bormann, Robert Cragie, Stephen Dawson-Haggerty, Mathilde Durvy, Erik 898 Nordmark, Christos Polyzois, Joseph Reddy, Shoichi Sakane, Zach 899 Shelby, Dario Tedeschi, Tony Viscardi, and Jay Werb for useful design 900 consideration and implementation feedback. 902 8. Changes 904 (This section to be removed by the RFC editor.) 906 Draft 14: 907 - Edits in response to IESG comments. 909 Draft 13: 910 - Specify that address bits not covered by the context or IID are 911 zero. 913 Draft 12: 914 - Specify that 16-bit to IID mapping is used to derive IID bits 915 when SAC/DAC=1 and the context does not cover those bits. 917 Draft 11: 918 - Removed incorrect and unnecessary text in specifying how to 919 derive the IID bits not covered by the context. 920 - Adjust formatting to reduce orphans and widows. 922 Draft 10: 923 - Specify that the IID has the form 0000:00ff:fe00:XXXX when SAC/ 924 DAC=0 and SAM/DAM=10. 926 Draft 09: 927 - Indicate that a mechanism to learn decompressor's capabilities 928 to decode additional (future) NHCs is out of scope. 929 - Clarify how to derive IID bits not covered by the context when 930 only 16 bits are carried inline. 932 - Clarify the value of the Length field for compressed extension 933 headers. 934 - Added an IANA registry for LOWPAN_NHC types. 936 Draft 08: 937 - Clarified that the lower bits of an IPv6 address may be derived 938 from an IPv6 header, not just an 802.15.4 header. Change text 939 from "derived from link-layer header" to "derived from 940 encapsulating header". 942 Draft 07: 943 - Added section on mapping link-layer addresses to IIDs. 944 - Added text on restricting compressed headers to first fragment 945 when using fragment headers defined in Section 5.3 of [RFC4944]. 946 - Minor editorial edits. 948 Draft 06: 949 - Reworked introduction. 950 - Added section on updates to [RFC4944]. 951 - Fixed description of number of bits used for IPHC encoding. 952 - Specify M=0 only for non-multicast addresses and M=1 only for 953 multicast addresses. 954 - Move 128-bit multicast encoding to DAC=0. 955 - Redefined ESC dispatch value to 01 000000. 956 - Many detailed edits. 958 Draft 05: 959 - Added LOWPAN_NHC encodings for IPv6 Extension Headers. 960 - Specify use of context 0 when CID is 0. 961 - Indicate that first 64-bits is link-local prefix padded with 962 zeros when link-local prefix is elided. 963 - Made prefix-based multicast encoding format more explicit for 964 clarity. 965 - Changed wording around stateful compression to allow for using 966 the in-line bits as an additional index to identify the compressed 967 address. 968 - Removed support for compressing unspecified address. 969 - Full 128-bit addr in-line only in stateless encoding. 971 Draft 04: 972 - Fixed typos leftover from the changes in 03. 973 - Gave more details on UDP checksum compression. 974 - Clarify that the context information is out of scope. 975 - Added security concern on 0xF0Bx port overloading. 977 Draft 03: 979 - Decoupled meaning of SAM bits from the destination address. 980 - Have separate bit to indicate multicast address compression. 981 - More extensive support for multicast address compression, 982 including Unicast-Prefix-based Multicast Addresses. 984 Draft 02: 985 - Updated wording with compression mode to clarify that a 986 compression mode does not enforce what kind of destination address 987 is being used. Specifically changed Destination Dependent Field 988 to Compression Mode. 989 - Specify that the configuration and management of contexts is out 990 of scope of this document. 992 Draft 01: 993 - HC back to 1 byte by default by stealing a few bits from the 994 dispatch field. 995 - Added better support for multicast address compression. 996 - Fixed alignment for UDP port compression. 997 - Better support for Traffic Class and Flow Label compression. 998 - Pascal joined as an author. 1000 9. References 1002 9.1. Normative References 1004 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1005 August 1980. 1007 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1008 Requirement Levels", BCP 14, RFC 2119, March 1997. 1010 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1011 (IPv6) Specification", RFC 2460, December 1998. 1013 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 1014 "Definition of the Differentiated Services Field (DS 1015 Field) in the IPv4 and IPv6 Headers", RFC 2474, 1016 December 1998. 1018 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 1019 of Explicit Congestion Notification (ECN) to IP", 1020 RFC 3168, September 2001. 1022 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1023 in IPv6", RFC 3775, June 2004. 1025 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1026 Architecture", RFC 4291, February 2006. 1028 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 1029 "Transmission of IPv6 Packets over IEEE 802.15.4 1030 Networks", RFC 4944, September 2007. 1032 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1033 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1034 May 2008. 1036 9.2. Informative References 1038 [IEEE 802.15.4] 1039 IEEE Computer Society, "IEEE Std. 802.15.4-2006", 1040 October 2006. 1042 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1043 Multicast Addresses", RFC 3306, August 2002. 1045 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1046 and M. Carney, "Dynamic Host Configuration Protocol for 1047 IPv6 (DHCPv6)", RFC 3315, July 2003. 1049 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 1050 Point (RP) Address in an IPv6 Multicast Address", 1051 RFC 3956, November 2004. 1053 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1054 December 2005. 1056 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1057 RFC 4303, December 2005. 1059 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1060 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1061 September 2007. 1063 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1064 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1066 Authors' Addresses 1068 Jonathan W. Hui (editor) 1069 Arch Rock Corporation 1070 501 2nd St. Ste. 410 1071 San Francisco, California 94107 1072 USA 1074 Phone: +415 692 0828 1075 Email: jhui@archrock.com 1077 Pascal Thubert 1078 Cisco Systems 1079 Village d'Entreprises Green Side 1080 400, Avenue de Roumanille 1081 Batiment T3 1082 Biot - Sophia Antipolis 06410 1083 FRANCE 1085 Phone: +33 4 97 23 26 34 1086 Email: pthubert@cisco.com