idnits 2.17.1 draft-ietf-6lowpan-hc-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 568. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 6, 2008) is 5675 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: 'RFC2461' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 515, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hui 3 Internet-Draft Arch Rock Corporation 4 Intended status: Standards Track October 6, 2008 5 Expires: April 9, 2009 7 Compression Format for IPv6 Datagrams in 6LoWPAN Networks 8 draft-ietf-6lowpan-hc-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 9, 2009. 35 Abstract 37 This document specifies an IPv6 header compression format for IPv6 38 packet delivery in 6LoWPAN networks. The compression format relies 39 on shared context to allow compression of arbitrary prefixes. This 40 document specifies compression of well-known multicast addresses and 41 a framework for compressing next headers. UDP compression is 42 specified within this framework. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 48 2. IPv6 Header Compression . . . . . . . . . . . . . . . . . . . 4 49 2.1. LOWPAN_IPHC Encoding Format . . . . . . . . . . . . . . . 5 50 2.2. IPv6 Unicast Address Compression . . . . . . . . . . . . . 6 51 2.3. IPv6 Multicast Address Compression . . . . . . . . . . . . 7 52 2.4. 16-bit Compressed Address Ranges . . . . . . . . . . . . . 8 53 3. IPv6 Next Header Compression . . . . . . . . . . . . . . . . . 9 54 3.1. LOWPAN_NHC Format . . . . . . . . . . . . . . . . . . . . 9 55 3.2. LOWPAN_UDP Header Compression . . . . . . . . . . . . . . 9 56 3.3. ISA100_UDP Header Compression . . . . . . . . . . . . . . 10 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 64 Intellectual Property and Copyright Statements . . . . . . . . . . 14 66 1. Introduction 68 The IEEE 802.15.4 standard specifies an MTU of 128 bytes, (including 69 the length byte) on a wireless link with a link throughput of 250 70 kbps or less[ieee802.15.4]. The 6LoWPAN adaptation format [RFC4944] 71 was specified to carry IPv6 datagrams over IEEE 802.15.4 links, 72 taking into account limited bandwidth, memory, or energy resources 73 that are expected in IEEE 802.15.4 applications. The 6LoWPAN 74 adaptation format defines a Mesh Addressing header to support sub-IP 75 forwarding, a Fragmentation header to support the IPv6 minimum MTU 76 requirement [RFC2460], and stateless header compression for IPv6 77 datagrams (LOWPAN_HC1 and LOWPAN_HC2) to reduce the relatively large 78 IPv6 and UDP headers down to (in the best case) several bytes. 80 LOWPAN_HC1 is most effective for link-local unicast communication, 81 where IPv6 addresses carry the link-local prefix and an Interface 82 Identifier (IID) directly derived from IEEE 802.15.4 addresses. In 83 this case, both addresses may be completely elided. This scenario is 84 most effective when communication remains local to a mesh-under 85 network where any forwarding occurs below IP and all 6LoWPAN nodes 86 are connected by a single IP hop. Even so, LOWPAN_HC1 cannot elide 87 the IPv6 Hop Limit. In cases where communication only occurs over a 88 single IP hop, there may be cases where a common IPv6 Hop Limit is 89 used. 91 Routable addresses must be used when communicating in a route-over 92 network where forwarding occurs at IP or when communicating with 93 devices external to the 6LoWPAN network. In this scenario, 94 LOWPAN_HC1 requires both IPv6 source and destination addresses to 95 carry the prefix in-line. Furthermore, in route-over networks, the 96 Mesh Addressing header may not be used and the IID must be carried 97 in-line. However LOWPAN_HC1 requires 64-bits for the IID when 98 carried in-line and cannot be shortened even when it is derived 99 directly from the IEEE 802.15.4 16-bit short address. When sending 100 to an IPv6 multicast address, LOWPAN_HC1 requires the full 128-bit 101 multicast address to be carried in-line. Multicast addresses are 102 commonly used for neighbor discovery, such as in IPv6 ND. 104 LOWPAN_HC1 can be extended to include a LOWPAN_HC2 octet to support 105 compression of UDP, TCP, or ICMPv6. RFC 4944 [RFC4944] only defines 106 compression for UDP, where UDP ports may be compressed and the UDP 107 Length may be elided. However, LOWPAN_HC1 also does not provide any 108 flexibility in supporting future compression mechanisms for next 109 headers other than UDP, TCP or ICMPv6. 111 This document specifies a header compression format for IPv6 112 datagrams. This format improves on the header compression format 113 defined in RFC 4944 [RFC4944] by generalizing it to support a broader 114 range of communication paradigms, including both mesh-under and 115 route-over configurations; communication to nodes internal and 116 external to the 6LoWPAN network; and multicast communication. This 117 document also defines a flexible framework for compressing arbitrary 118 next headers and defines UDP header compression within this 119 framework. This compression format carries forward the design 120 concepts in RFC 4944 [RFC4944], minimizing any state and relying on 121 shared context among all nodes in a 6LoWPAN network. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC 2119 [RFC2119]. 129 2. IPv6 Header Compression 131 In this section, we define the LOWPAN_IPHC encoding format for 132 compressing the IPv6 header. To enable effective compression 133 LOWPAN_IPHC relies on information pertaining to the entire 6LoWPAN 134 network. LOWPAN_IPHC assumes the following will be the common case 135 for 6LoWPAN communication: Version is 6; Traffic Class and Flow Label 136 are both zero; Payload Length can be inferred from lower layers from 137 either the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header; 138 Hop Limit will be set to a well-known value by the source; addresses 139 assigned to 6LoWPAN interfaces will be formed using the link-local 140 prefix or a single routable prefix assigned to the entire 6LoWPAN 141 network; addresses assigned to 6LoWPAN interfaces are formed with an 142 IID derived directly from either the 64-bit extended or 16-bit short 143 IEEE 802.15.4 addresses. 145 1 2 3 146 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 2 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | LOWPAN_IPHC | Uncompressed fields follow... 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1: LOWPAN_IPHC Header 153 The LOWPAN_IPHC encoding utilizes a two octets, with uncompressed 154 fields following, as shown in Figure 1. With the above scenario, the 155 LOWPAN_IPHC can compress the IPv6 header down to two octets (the 156 LOWPAN_IPHC encoding) with link-local communication. When 157 communicating over multiple IP hops, LOWPAN_IPHC can compress the 158 IPv6 header down to 7 octets (2-octet LOWPAN_IPHC, 1-octet Hop Limit, 159 2-octet Source Address, and 2-octet Destination Address). 161 2.1. LOWPAN_IPHC Encoding Format 163 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 164 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 165 | T |VF |NH | HLIM | rsv | SAM | SAC | DAM | DAC | 166 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 168 Figure 2: LOWPAN_IPHC Encoding 170 T: Traffic Class (bit 0): 171 0: Full 8 bits for Traffic Class are carried in-line. 172 1: Traffic Class is elided and implicitly 0. 173 VF: Version and Flow Label (bit 1): 174 0: Full 4 bits for Version and 20 bits for Flow Label are carried 175 in-line. 176 1: Version and Flow Label are elided. Version is implicitly 6. 177 Traffic Class and Flow Label are implicitly 0. 179 NH: Next Hop (bit 2): 180 0: Full 8 bits for Next Hop are carried in-line. 181 1: Next Hop is elided and the next header is compressed using 182 LOWPAN_NHC, which is discussed in Section 3. 184 HLIM: Hop Limit (bits 3-4): 185 00: All 8 bits of Hop Limit are carried in-line. 186 01: All 8 bits of Hop Limit are elided and the Hop Limit is 187 assumed to be 1. 188 10: All 8 bits of Hop Limit are elided and the Hop Limit is 189 assumed to be 64. 190 11: All 8 bits of Hop Limit are elided and the Hop Limit is 191 assumed to be 255. 193 rsv: Reserved (bit 5-7) 195 SAC: Source Address Mode (bits 8-9): 196 00: All 128 bits of Source Address are carried in-line. 197 01: 64-bit Compressed IPv6 address. 198 10: 16-bit Compressed IPv6 address. 199 11: All 128 bits of Source Address are elided. 201 SAC: Source Address Context (bits 10-11): Identifies the compression 202 context when the source address is compressed. The value '00' is 203 reserved and indicates a link-local address. 205 DAM: Destination Address Mode (bits 12-13): 206 00: All 128 bits of Destination Address are carried in-line. 207 01: 64-bit Compressed IPv6 address. 208 10: 16-bit Compressed IPv6 address. 209 11: All 128 bits of Destination Address are elided. 211 DAC: Destination Address Context (bits 14-15): Identifies the 212 compression context when the destination address is compressed. 213 The value '00' is reserved and indicates a link-local address. 215 Fields carried in-line (in part or in whole) appear in the same order 216 as they do in the IPv6 header format [RFC2460]. IPv6 addresses may 217 be compressed to 64 or 16 bits or completely elided. The IPv6 218 Payload Length field MUST always be elided and inferred from lower 219 layers using the 6LoWPAN Fragmentation header or the IEEE 802.15.4 220 header. 222 2.2. IPv6 Unicast Address Compression 224 IPv6 unicast addresses may be compressed to 64, 16, or 0 bits. When 225 an IPv6 unicast address is compressed, the compression context 226 identifies the value of the elided bits. A compression value of '00' 227 indicates the link-local prefix. The mapping between a specific 228 context and prefix may be obtained through simple modifications to 229 IPv6 Neighbor Discovery. However, the specification of those 230 mechanisms are out of scope of this document. Care should be taken 231 when renumbering a network. Nodes SHOULD only use a context after 232 all of its neighbors have been configured with the same context 233 information with high probability. New information within a context 234 SHOULD only be assigned after all nodes in the network have received 235 notification of its deprecation with high probability. 237 There may be cases where the compressor and decompressor are out of 238 sync within a context. In this cases, the decompressor may 239 reconstruct the IPv6 address using the incorrect prefix. To prevent 240 such errors, upper-layer integrity checks (e.g. psuedo-header 241 checksum) that cover both source and destination addresses SHOULD be 242 used. 244 When an IPv6 unicast address is compressed to 64 bits, the last 64 245 bits are carried in-line. When an IPv6 unicast address is compressed 246 to 16 bits, the last 16 bits are carried in line. Because the 16-bit 247 compressed form is also used for IPv6 multicast address compression, 248 the 16-bit address space is divided into multiple ranges. For 249 unicast addresses, the first bit carried in-line must be zero. 251 1 252 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 |0| Last 15 bits of IPv6 Addr | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 3: 16-bit Compressed IPv6 Unicast Address Encoding 259 When an address is completely elided, the IID is inferred from lower 260 layers (either from the 6LoWPAN Mesh Addressing header or from the 261 IEEE 802.15.4 header). The prefix is inferred from the identified 262 context. Any remaining bits in between are implicitly zero. 264 To elide the IID, it MUST be derivable from IEEE 802.15.4 addresses. 265 An IID may be derived from the IEEE EUI-64 address by creating a 266 Modified EUI-64 IID from the IEEE EUI-64 address, as defined in RFC 267 4291 [RFC4291]. The universal/local bit in the Modified IEEE EUI-64 268 IID must be set to '1', indicating universal scope. An IID may also 269 be derived from the 16-bit short address and PAN ID, as defined in 270 RFC 4944 [RFC4944]. Note, however, that the most significant bit in 271 the short address must be zero. 273 2.3. IPv6 Multicast Address Compression 275 IPv6 multicast addresses may be compressed to 16 bits by utilizing a 276 different 6LoWPAN short address range. This document allocates 277 another range of 8192 values to be used for well-known IPv6 multicast 278 addresses. 280 1 281 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |Range| Scope | Mapped Group ID | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 4: Compressed IPv6 Multicast Address Encoding 288 Range (bits 0-2): Must be set to '101' (TBD), which identifies the 289 6LoWPAN short address range for compressed IPv6 multicast 290 addresses. 291 Scope (bits 3-6): 4-bit multicast scope as specified in RFC 4007 292 [RFC4007]. 293 Mapped Group ID (bits 7-15): 9-bit mapped multicast group 294 identifier. 296 The full 128-bit multicast address can be reconstructed from the 16- 297 bit mapped multicast address. By definition, the 3-bit range 298 identifier indicates the well-known multicast prefix (0xFF) in 299 addition to a flags field set to all zeros (indicating a permanently 300 assigned multicast address, that the multicast address is not 301 assigned based on the network prefix, and that it doesn't embed the 302 address of a Rendezvous Point). The 4-bit scope is carried in-line 303 and the 112-bit group ID is derived from the 9-bit mapped group ID 304 using a well-known mapping maintained by the Internet Assigned 305 Numbers Authority (IANA). 307 Nodes MUST accept both the compressed and uncompressed form of well- 308 known multicast addresses that they subscribe to. Doing so removes 309 any ambiguity of which form to use as both will work. Conversely, 310 nodes MUST NOT subscribe to well-known multicast addresses that are 311 not defined by the well-known mapping. 313 This document defines an initial mapping. Additional mappings 314 between 9-bit mapped group IDs and 112-bit group IDs may be specified 315 in the future. 317 +-------+---------+-----------------------+ 318 | 9-bit | 112-bit | Description | 319 +-------+---------+-----------------------+ 320 | 1 | 1 | All Nodes Addresses | 321 | 2 | 2 | All Routers Addresses | 322 +-------+---------+-----------------------+ 324 9-bit to 112-bit Group ID Mapping 326 2.4. 16-bit Compressed Address Ranges 328 To use the 16-bit compressed address format for different kinds of 329 addresses (e.g. unicast or multicast), LOWPAN_IPHC utilizes the 16- 330 bit short address ranges as specified in RFC 4944. This document 331 specifies another range, for compressed multicast addresses. 333 Range 0, 0xxxxxxxxxxxxxxx: As specified in RFC 4944. 335 Range 2, 100xxxxxxxxxxxxx: As specified in RFC 4944. 337 Range 1, 101xxxxxxxxxxxxx: The remaining 13 bits represent a 338 compressed IPv6 multicast address, as described in Section 2.3. 340 Range 3, 110xxxxxxxxxxxxx: Reserved. 342 Range 4, 111xxxxxxxxxxxxx: Reserved. 344 3. IPv6 Next Header Compression 346 LOWPAN_IPHC elides the IPv6 Next Header field when the NH bit is set 347 to 1. It also indicates the use of 6LoWPAN next header compression, 348 LOWPAN_NHC. The value of IPv6 Next Header is recovered from the 349 first bits in the LOWPAN_NHC encoding. The following bits are 350 specific to the IPv6 Next Header value. Figure 5 shows the structure 351 of an IPv6 datagram compressed using LOWPAN_IPHC and LOWPAN_NHC. 353 +-------------+-------------+-------------+-----------------+-------- 354 | LOWPAN_IPHC | In-line | LOWPAN_NHC | In-line Next | Payload 355 | Encoding | IP Fields | Encoding | Header Fields | 356 +-------------+-------------+-------------+-----------------+-------- 358 Figure 5: Typical LOWPAN_IPHC/LOWPAN_NHC Header Configuration 360 3.1. LOWPAN_NHC Format 362 Compression formats for different next headers are identified by a 363 variable length bit-pattern immediately following the LOWPAN_IPHC 364 compressed header. When defining a next header compression format, 365 the number of bits used SHOULD be determined by the perceived 366 frequency of using that format. However, the number of bits and any 367 remaining encoding bits SHOULD respect octet alignment. The 368 following bits are specific to the next header compression format. 369 In this document, we define a compression format for UDP headers. 371 +----------------+--------------------------- 372 | var-len NHC ID | compressed next header... 373 +----------------+--------------------------- 375 Figure 6: LOWPAN_NHC Encoding 377 3.2. LOWPAN_UDP Header Compression 379 This document defines a compression format for UDP headers using 380 LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 7. 381 Bits 0 through 5 represent the NHC ID and '111110' indicates the 382 specific UDP header compression encoding defined in this section. 384 0 1 2 3 4 5 6 7 385 +---+---+---+---+---+---+---+---+ 386 | 1 | 1 | 1 | 1 | 1 | 0 | S | D | 387 +---+---+---+---+---+---+---+---+ 389 Figure 7: Compressed UDP Header Encoding 391 S: Source Port (bit 6): 392 0: All 16 bits of Source Port are carried in-line. 393 1: First 12 bits of Source Port are elided and the remaining 4 394 bits are carried in-line. The Source Port is recovered by: P + 395 short_port, where P is 61616 (0xF0B0). 397 D: Destination Port (bit 7): 398 0: All 16 bits of Destination Port are carried in-line. 399 1: First 12 bits of Destination Port are elided and the remaining 400 4 bits are carried in-line. The Destination Port is recovered 401 by: P + short_port, where P is 61616 (0xF0B0). 403 Fields carried in-line (in part or in whole) appear in the same order 404 as they do in the IPv6 header format [RFC0768]. IPv6 addresses may 405 be compressed to 64 or 16 bits or completely elided. The UDP Length 406 field MUST always be elided and is inferred from lower layers using 407 the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 409 3.3. ISA100_UDP Header Compression 411 This document defines a compression format for UDP headers using 412 LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 8. 413 Bits 0 through 4 represent the NHC ID and '11110' indicates the 414 specific UDP header compression encoding defined in this section. 416 0 1 2 3 4 5 6 7 417 +---+---+---+---+---+---+---+---+ 418 | 1 | 1 | 1 | 1 | 0 | C | S | D | 419 +---+---+---+---+---+---+---+---+ 421 Figure 8: Compressed ISA100.11a UDP Header Encoding 423 C: Checksum (bit 5): 424 0: All 16 bits of Checksum are carried in-line. The Checksum MUST 425 be included if there are no other end-to-end integrity checks 426 that are stronger than what is provided by the UDP checksum. 427 Such an integrity check MUST be end-to-end and cover the IPv6 428 pseudo-header, UDP header, and UDP payload. 429 1: All 16 bits of Checksum are elided. The Checksum is recovered 430 by recomputing it. 432 S: Source Port (bit 6): 433 0: All 16 bits of Source Port are carried in-line. 434 1: First 12 bits of Source Port are elided and the remaining 4 435 bits are carried in-line. The Source Port is recovered by: P + 436 short_port, where P is 61616 (0xF0B0). 438 D: Destination Port (bit 7): 439 0: All 16 bits of Destination Port are carried in-line. 440 1: First 12 bits of Destination Port are elided and the remaining 441 4 bits are carried in-line. The Destination Port is recovered 442 by: P + short_port, where P is 61616 (0xF0B0). 444 Fields carried in-line (in part or in whole) appear in the same order 445 as they do in the IPv6 header format [RFC0768]. IPv6 addresses may 446 be compressed to 64 or 16 bits or completely elided. The UDP Length 447 field MUST always be elided and is inferred from lower layers using 448 the 6LoWPAN Fragmentation header or the IEEE 802.15.4 header. 450 4. IANA Considerations 452 This document defines a new IPv6 header compression format for 453 6LoWPAN networks. The document allocates a new Dispatch type value 454 of 0x03 (TBD) for LOWPAN_IPHC. 456 This document reserves another 16-bit short address range from RFC 457 4944 for use with 16-bit compressed well-known IPv6 multicast 458 addresses. 460 This document creates a new IANA registry for mapped well-known 461 multicast addresses, mapping 112-bit group identifiers to compressed 462 9-bit ones. The registry MUST include the All Nodes Address (1) and 463 the All Routers Address (2). 465 5. Security Considerations 467 The definition of LOWPAN_IPHC permits the compression of header 468 information on communication that could take place in its absence, 469 albeit in a less efficient form. It recognizes that a IEEE 802.15.4 470 PAN may have associated with it a global prefix. How that global 471 prefix is assigned and managed is beyond the scope of this document. 473 6. Acknowledgements 475 Thanks to Pascal Thubert for useful discussions in helping shape the 476 header compression mechanisms. Thanks to Carsten Bormann for useful 477 feedback and discussion. 479 7. References 480 7.1. Normative References 482 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 483 August 1980. 485 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, March 1997. 488 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 489 (IPv6) Specification", RFC 2460, December 1998. 491 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 492 Discovery for IP Version 6 (IPv6)", RFC 2461, 493 December 1998. 495 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 496 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 497 March 2005. 499 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 500 Architecture", RFC 4291, February 2006. 502 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 503 Address Autoconfiguration", RFC 4862, September 2007. 505 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 506 "Transmission of IPv6 Packets over IEEE 802.15.4 507 Networks", RFC 4944, September 2007. 509 [ieee802.15.4] 510 IEEE Computer Society, "IEEE Std. 802.15.4-2006", 511 October 2006. 513 7.2. Informative References 515 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 516 Text on Security Considerations", BCP 72, RFC 3552, 517 July 2003. 519 Author's Address 521 Jonathan W. Hui 522 Arch Rock Corporation 523 501 2nd St. Ste. 410 524 San Francisco, California 94107 525 USA 527 Phone: +415 692 0828 528 Email: jhui@archrock.com 530 Full Copyright Statement 532 Copyright (C) The IETF Trust (2008). 534 This document is subject to the rights, licenses and restrictions 535 contained in BCP 78, and except as set forth therein, the authors 536 retain all their rights. 538 This document and the information contained herein are provided on an 539 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 540 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 541 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 542 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 543 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 544 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 546 Intellectual Property 548 The IETF takes no position regarding the validity or scope of any 549 Intellectual Property Rights or other rights that might be claimed to 550 pertain to the implementation or use of the technology described in 551 this document or the extent to which any license under such rights 552 might or might not be available; nor does it represent that it has 553 made any independent effort to identify any such rights. Information 554 on the procedures with respect to rights in RFC documents can be 555 found in BCP 78 and BCP 79. 557 Copies of IPR disclosures made to the IETF Secretariat and any 558 assurances of licenses to be made available, or the result of an 559 attempt made to obtain a general license or permission for the use of 560 such proprietary rights by implementers or users of this 561 specification can be obtained from the IETF on-line IPR repository at 562 http://www.ietf.org/ipr. 564 The IETF invites any interested party to bring to its attention any 565 copyrights, patents or patent applications, or other proprietary 566 rights that may cover technology that may be required to implement 567 this standard. Please address the information to the IETF at 568 ietf-ipr@ietf.org.