idnits 2.17.1 draft-ietf-6lowpan-format-13.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1369. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1380. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1393. 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 (April 2, 2007) is 6231 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) -- Looks like a reference, but probably isn't: '1' on line 652 -- Looks like a reference, but probably isn't: '16' on line 658 -- Looks like a reference, but probably isn't: '15' on line 664 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Montenegro 2 Internet-Draft Microsoft Corporation 3 Intended status: Standards Track N. Kushalnagar 4 Expires: October 4, 2007 Intel Corp 5 J. Hui 6 D. Culler 7 Arch Rock Corp 8 April 2, 2007 10 Transmission of IPv6 Packets over IEEE 802.15.4 Networks 11 draft-ietf-6lowpan-format-13 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on October 4, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 This document describes the frame format for transmission of IPv6 45 packets and the method of forming IPv6 link-local addresses and 46 statelessly autoconfigured addresses on IEEE 802.15.4 networks. 47 Additional specifications include a simple header compression scheme 48 using shared context and provisions for packet delivery in IEEE 49 802.15.4 meshes. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 55 1.2. Terms used . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. IEEE 802.15.4 mode for IP . . . . . . . . . . . . . . . . . . 3 57 3. Addressing Modes . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 5 59 5. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . . 6 60 5.1. Dispatch Type and Header . . . . . . . . . . . . . . . . . 8 61 5.2. Mesh Addressing Type and Header . . . . . . . . . . . . . 9 62 5.3. Fragmentation Type and Header . . . . . . . . . . . . . . 10 63 6. Stateless Address Autoconfiguration . . . . . . . . . . . . . 12 64 7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 13 65 8. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 13 66 9. Multicast Address Mapping . . . . . . . . . . . . . . . . . . 15 67 10. Header Compression . . . . . . . . . . . . . . . . . . . . . . 15 68 10.1. Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 16 69 10.2. Encoding of UDP Header Fields . . . . . . . . . . . . . . 18 70 10.3. Non-Compressed Fields . . . . . . . . . . . . . . . . . . 19 71 10.3.1. Non-Compressed IPv6 Fields . . . . . . . . . . . . . 19 72 10.3.2. Non-Compressed and partially compressed UDP fields . 20 73 11. Frame Delivery in a Link-Layer Mesh . . . . . . . . . . . . . 20 74 11.1. LoWPAN Broadcast . . . . . . . . . . . . . . . . . . . . . 21 75 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 76 13. Security Considerations . . . . . . . . . . . . . . . . . . . 23 77 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 78 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 79 15.1. Normative References . . . . . . . . . . . . . . . . . . . 24 80 15.2. Informative References . . . . . . . . . . . . . . . . . . 25 81 Appendix A. Alternatives for Delivery of Frames in a Mesh . . . . 25 82 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 26 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 84 Intellectual Property and Copyright Statements . . . . . . . . . . 31 86 1. Introduction 88 The IEEE 802.15.4 standard [ieee802.15.4] targets low power personal 89 area networks. This document defines the frame format for 90 transmission of IPv6 [RFC2460] packets as well as the formation of 91 IPv6 link-local addresses and statelessly autoconfigured addresses on 92 top of IEEE 802.15.4 networks. Since IPv6 requires support of packet 93 sizes much larger than the largest IEEE 802.15.4 frame size, an 94 adaptation layer is defined. This document also defines mechanisms 95 for header compression required to make IPv6 practical on IEEE 96 802.15.4 networks, and the provisions required for packet delivery in 97 IEEE 802.15.4 meshes. However, a full specification of mesh routing 98 (the specific protocol used, the interactions with neighbor 99 discovery, etc) is out of scope of this document. 101 1.1. Requirements notation 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 1.2. Terms used 109 AES: Advanced Encryption Scheme 110 CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance 111 FFD: Full Function Device 112 GTS: Guaranteed Time Service 113 MTU: Maximum Transmission Unit 114 MAC: Media Access Control 115 PAN: Personal Area Network 116 RFD: Reduced Function Device 118 2. IEEE 802.15.4 mode for IP 120 IEEE 802.15.4 defines four types of frames: beacon frames, MAC 121 command frames, acknowledgement frames and data frames. IPv6 packets 122 MUST be carried on data frames. Data frames may optionally request 123 that they be acknowledged. In keeping with [RFC3819] it is 124 recommended that IPv6 packets be carried in frames for which 125 acknowledgements are requested so as to aid link-layer recovery. 126 IEEE 802.15.4 networks can either be nonbeacon-enabled or beacon- 127 enabled [ieee802.15.4]. The latter is an optional mode in which 128 devices are synchronized by a so-called coordinator's beacons. This 129 allows the use of superframes within which a contention-free 130 Guaranteed Time Service (GTS) is possible. This document does not 131 require that IEEE networks run in beacon-enabled mode. In nonbeacon- 132 enabled networks, data frames (including those carrying IPv6 packets) 133 are sent via the contention-based channel access method of unslotted 134 CSMA/CA. 136 In nonbeacon-enabled networks, beacons are not used for 137 synchronization. However, they are still useful for link-layer 138 device discovery to aid in association and disassociation events. 139 This document recommends that beacons be configured so as to aid 140 these functions. A further recommendation is for these events to be 141 available at the IPv6 layer to aid in detecting network attachment, a 142 problem being worked on at the IETF at the time of this writing. 144 The specification allows for frames in which either the source or 145 destination addresses (or both) are elided. The mechanisms defined 146 in this document require that both source and destination addresses 147 be included in the IEEE 802.15.4 frame header. The source or 148 destination PAN ID fields may also be included. 150 3. Addressing Modes 152 IEEE 802.15.4 defines several addressing modes: it allows the use of 153 either IEEE 64-bit extended addresses or (after an association event) 154 16-bit addresses unique within the PAN [ieee802.15.4]. This document 155 supports both 64-bit extended addresses, and 16-bit short addresses. 156 For use within 6LoWPANs, this document imposes additional constraints 157 (beyond those imposed by IEEE 802.15.4) on the format of the 16-bit 158 short addresses, as specified in Section 12. Short addresses being 159 transient in nature, a word of caution is in order: since they are 160 doled out by the PAN coordinator function during an association 161 event, their validity and uniqueness is limited by the lifetime of 162 that association. This can be cut short by expiration of the 163 association or simply by any mishap occurring to the PAN coordinator. 164 Because of the scalability issues posed by such a centralized 165 allocation and single point of failure at the PAN coordinator, 166 deployers should carefully weigh the tradeoffs (and implement the 167 necessary mechanisms) of growing such networks based on short 168 addresses. Of course, IEEE 64-bit extended addresses may not suffer 169 from these drawbacks, but still share the remaining scalability 170 issues concerning routing, discovery, configuration, etc. 172 This document assumes that a PAN maps to a specific IPv6 link. This 173 complies with the recommendation that shared networks support link- 174 layer subnet [RFC3819] broadcast. Strictly speaking, it is multicast 175 not broadcast that exists in IPv6. However, multicast is not 176 supported natively in IEEE 802.15.4. Hence, IPv6 level multicast 177 packets MUST be carried as link-layer broadcast frames in IEEE 178 802.15.4 networks. This MUST be done such that the broadcast frames 179 are only heeded by devices within the specific PAN of the link in 180 question. As per section 7.5.6.2 in [ieee802.15.4], this is 181 accomplished as follows: 183 1. A destination PAN identifier is included in the frame, and it 184 MUST match the PAN ID of the link in question. 186 2. A short destination address is included in the frame, and it MUST 187 match the broadcast address (0xffff). 189 Additionally, support for mapping of IPv6 multicast addresses per 190 Section 9 MUST only be used in a mesh configuration. A full 191 specification of such functionality is out of scope of this document. 193 As usual, hosts learn IPv6 prefixes via router advertisements as per 194 [I-D.ietf-ipv6-2461bis]. 196 4. Maximum Transmission Unit 198 The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets. 199 However, a full IPv6 packet does not fit in an IEEE 802.15.4 frame. 200 802.15.4 protocol data units have different sizes depending on how 201 much overhead is present [ieee802.15.4]. Starting from a maximum 202 physical layer packet size of 127 octets (aMaxPHYPacketSize) and a 203 maximum frame overhead of 25 (aMaxFrameOverhead), the resultant 204 maximum frame size at the media access control layer is 102 octets. 205 Link-layer security imposes further overhead, which in the maximum 206 case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 207 for AES-CCM-32 and AES-CCM-64, respectively) leaves only 81 octets 208 available. This is obviously far below the minimum IPv6 packet size 209 of 1280 octets, and in keeping with section 5 of the IPv6 210 specification [RFC2460], a fragmention and reassembly adaptation 211 layer must be provided at the layer below IP. Such a layer is 212 defined below in Section 5. 214 Furthermore, since the IPv6 header is 40 octets long, this leaves 215 only 41 octets for upper-layer protocols, like UDP. The latter uses 216 8 octets in the header which leaves only 33 octets for application 217 data. Additionally, as pointed out above, there is a need for a 218 fragmentation and reassembly layer, which will use even more octets. 220 The above considerations lead to the following two observations: 222 1. The adaptation layer must be provided to comply with IPv6 223 requirements of minimum MTU. However, it is expected that (a) 224 most applications of IEEE 802.15.4 will not use such large 225 packets, and (b) small application payloads in conjunction with 226 proper header compression will produce packets that fit within a 227 single IEEE 802.15.4 frame. The justification for this 228 adaptation layer is not just for IPv6 compliance, as it is quite 229 likely that the packet sizes produced by certain application 230 exchanges (e.g., configuration or provisioning) may require a 231 small number of fragments. 233 2. Even though the above space calculation shows the worst case 234 scenario, it does point out the fact that header compression is 235 compelling to the point of almost being unavoidable. Since we 236 expect that most (if not all) applications of IP over IEEE 237 802.15.4 will make use of header compression, it is defined below 238 in Section 10. 240 5. LoWPAN Adaptation Layer and Frame Format 242 The encapsulation formats defined in this section, (subsequently 243 referred to as the "LoWPAN encapsulation") are the payload in the 244 IEEE 802.15.4 MAC protocol data unit (PDU). The LoWPAN payload 245 (e.g., an IPv6 packet) follows this encapsulation header. 247 All LoWPAN encapsulated datagrams transported over IEEE 802.15.4 are 248 prefixed by an encapsulation header stack. Each header in the header 249 stack contains a header type followed zero or more header fields. 250 Whereas in an IPv6 header the stack would contain, in order, 251 addressing, hop-by-hop options, routing, fragmentation, destination 252 options, and finally payload [RFC2460]; in a LoWPAN header the 253 analogous header sequence is mesh (L2) addressing, hop-by-hop options 254 (including L2 broadcast/multicast), fragmentation, and finally 255 payload. These examples show typical header stacks that may be used 256 in a LoWPAN network. 258 A LoWPAN encapsulated IPv6 datagram: 260 +---------------+-------------+---------+ 261 | IPv6 Dispatch | IPv6 Header | Payload | 262 +---------------+-------------+---------+ 264 A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram: 266 +--------------+------------+---------+ 267 | HC1 Dispatch | HC1 Header | Payload | 268 +--------------+------------+---------+ 270 A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that 271 requires mesh addressing: 273 +-----------+-------------+--------------+------------+---------+ 274 | Mesh Type | Mesh Header | HC1 Dispatch | HC1 Header | Payload | 275 +-----------+-------------+--------------+------------+---------+ 277 A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that 278 requires fragmentation: 280 +-----------+-------------+--------------+------------+---------+ 281 | Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload | 282 +-----------+-------------+--------------+------------+---------+ 284 A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that 285 requires both mesh addressing and fragmentation: 287 +-------+-------+-------+-------+---------+---------+---------+ 288 | M Typ | M Hdr | F Typ | F Hdr | HC1 Dsp | HC1 Hdr | Payload | 289 +-------+-------+-------+-------+---------+---------+---------+ 291 A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that 292 requires both mesh addressing and a broadcast header to support mesh 293 broadcast/multicast: 295 +-------+-------+-------+-------+---------+---------+---------+ 296 | M Typ | M Hdr | B Dsp | B Hdr | HC1 Dsp | HC1 Hdr | Payload | 297 +-------+-------+-------+-------+---------+---------+---------+ 299 When more than one LoWPAN header is used in the same packet, they 300 MUST appear in the following order: 302 Mesh Addressing Header 303 Broadcast Header 304 Fragmentation Header 306 All protocol datagrams (e.g., IPv6, compressed IPv6 headers, etc) 307 SHALL be preceded by one of the valid LoWPAN encapsulation headers, 308 examples of which are given above. This permits uniform software 309 treatment of datagrams without regard to the mode of their 310 transmission. 312 The definition of headers, other than mesh addressing and 313 fragmentation, in LoWPAN consists of the dispatch value, the 314 definition of the header fields that follow, and their ordering 315 constraints relative to all other headers. Although the header stack 316 structure provides a mechanism to address future demands on the 317 LoWPAN adaptation layer, it is not intended to provided general 318 purpose extensibility. This format document specifies a small set of 319 header types using the header stack for clarity, compactness, and 320 othogonality. All headers used in a LOWPAN adaptation layer SHALL be 321 defined in this format document. 323 5.1. Dispatch Type and Header 325 The dispatch type is defined by a zero-bit as the first bit and a 326 one-bit as the second bit. The dispatch type and header is shown 327 here: 329 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |0 1| Dispatch | type-specific header 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 Dispatch 6-bit selector. Identifies the type of header 336 immediately following the Dispatch Header. 338 type-specific header A header determined by the Dispatch Header. 340 Figure 7: Dispatch Type and Header 342 The dispatch value may be treated as an unstructured namespace. Only 343 a few symbols are required to represent current LoWPAN functionality. 344 Although some additional savings could be achieved by encoding 345 additional functionality into the dispatch byte, these measures would 346 tend to constrain the ability to address future alternatives. 348 Pattern Header Type 349 +------------+-----------------------------------------------+ 350 | 00 xxxxxx | NALP - Not a LoWPAN frame | 351 | 01 000001 | IPv6 - uncompressed IPv6 Addresses | 352 | 01 000010 | LOWPAN_HC1 - LOWPAN_HC1 compressed IPv6 | 353 | ... | reserved - Reserved for future use | 354 | 01 010000 | LOWPAN_BC0 - LOWPAN_BC0 broadcast | 355 | ... | reserved - Reserved for future use | 356 | 01 111111 | ESC - Additional Dispatch byte follows | 357 +------------+-----------------------------------------------+ 359 Figure 8: Dispatch Value Bit Pattern 361 NALP: Specifies that the following bits are not a part of the LoWPAN 362 encapsulation, and any LoWPAN node that encounters a dispatch 363 value of 00xxxxxx shall discard the packet. Other non-LoWPAN 364 protocols that wish to coexist with LoWPAN nodes should include a 365 byte matching this pattern immediately following the 802.15.4. 366 header. 368 IPv6: Specifies that the following header is an uncompressed IPv6 369 header [RFC2460]. 371 LOWPAN_HC1: Specifies that the following header is a LOWPAN_HC1 372 compressd IPv6 header. This header format is defined in 373 Figure 15. 375 LOWPAN_BC0: Specifies that the following header is a LOWPAN_BC0 376 header for mesh broadcast/multicast support and is described in 377 Section 11.1. 379 ESC: Specifies that the following header is a single 8-bit field for 380 the Dispatch value. Allows support for Dispatch values larger 381 than 127. 383 5.2. Mesh Addressing Type and Header 385 The mesh type is defined by a one-bit and zero-bit as the first two 386 bits. The mesh type and header is shown here: 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 |1 0|O|F|HopsLft| originator address, final address 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 9: Mesh Addressing Type and Header 396 Field definitions are as follows: 398 O: This 1-bit field SHALL be zero if the Originator Address is an 399 IEEE extended 64 bit address (EUI-64), or 1 if it is a short 16- 400 bit addresses. 402 F: This 1-bit field SHALL be zero if the Final Destination Address is 403 an IEEE extended 64 bit address (EUI-64), or 1 if it is a short 404 16-bit addresses. 406 Hops Left: This 4-bit field SHALL be decremented by each forwarding 407 node before sending this packet towards its next hop. The packet 408 is not forwarded any further if Hops Left is decremented to 0. 409 The value 0xF is reserved and signifies an 8-bit Deep Hops Left 410 field immediately following, and allows a source node to specify a 411 hop limit greater than 14 hops. 413 Originator Address: This is the link-layer address of the 414 Originator. 416 Final Destination Address: This is the link-layer address of the 417 Final Destination. 419 Note that the 'O' and 'F' bits allow for a mix of 16 and 64-bit 420 addresses. This is useful at least to allow for mesh layer 421 "broadcast", as 802.15.4 broadcast addresses are defined as 16-bit 422 short addresses. 424 A further discussion of frame delivery within a mesh is in 425 Section 11. 427 5.3. Fragmentation Type and Header 429 If an entire payload (e.g., IPv6) datagram fits within a single 430 802.15.4 frame, it is unfragmented and the LoWPAN encapsulation 431 should contain no fragmentation header. If the datagram does not fit 432 within a single IEEE 802.15.4 frame, it SHALL be broken into link 433 fragments. As the fragment offset can only express multiples of 434 eight bytes, all link fragments for a datagram except the last one 435 MUST be multiples of eight bytes in length. The first link fragment 436 SHALL contain the first fragment header defined as shown below. 438 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 |1 1 0 0 0| datagram_size | datagram_tag | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Figure 10: First Fragment 446 The second and subsequent link fragments (up to and including the 447 last) SHALL contain a fragmentation header that conforms to the 448 format shown below. 450 1 2 3 451 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 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 |1 1 1 0 0| datagram_size | datagram_tag | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 |datagram_offset| 456 +-+-+-+-+-+-+-+-+ 458 Figure 11: Subsequent Fragments 460 datagram_size: This 11 bit field encodes the size of the entire IP 461 packet before link-layer fragmentation (but after IP layer 462 fragmentation). The value of datagram_size SHALL be the same for 463 all link-layer fragments of an IP packet. For IPv6, this SHALL be 464 40 octets (the size of the uncompressed IPv6 header) more than the 465 value of Payload Length in the IPv6 header [RFC2460] of the 466 packet. Note that this packet may already be fragmented by hosts 467 involved in the communication, i.e., this field needs to encode a 468 maximum length of 1280 octets (the IEEE 802.15.4 link MTU as 469 defined in this document). 471 NOTE: This field does not need to be in every packet, as one could 472 send it with the first fragment and elide it subsequently. 473 However, including it in every link fragment eases the task of 474 reassembly in the event that a second (or subsequent) link 475 fragment arrives before the first. In this case, the guarantee of 476 learning the datagram_size as soon as any of the fragments arrives 477 tells the receiver how much buffer space to set aside as it waits 478 for the rest of the fragments. The format above trades off 479 simplicity for efficiency. 481 datagram_tag: The value of datagram_tag (datagram tag) SHALL be the 482 same for all link fragments of a payload (e.g., IPv6) datagram. 483 The sender SHALL increment datagram_tag for successive, fragmented 484 datagrams. The incremented value of datagram_tag SHALL wrap from 485 65535 back to zero. This field is 16 bits long, and its initial 486 value is not defined. 488 datagram_offset: This field is present only in the second and 489 subsequent link fragments and SHALL specify the offset, in 490 increments of 8 octets, of the fragment from the beginning of the 491 payload datagram. The first octet of the datagram (e.g., the 492 start of the IPv6 header) has an offset of zero; the implicit 493 value of datagram_offset in the first link fragment is zero. This 494 field is 8 bits long. 496 The recipient of link fragments SHALL use (1) the sender's 802.15.4 497 source address (or the Originator Address if a Mesh Addressing field 498 is present), (2) the destination's 802.15.4 address (or the Final 499 Destination address if a Mesh Addressing field is present), (3) 500 datagram_size and (4) datagram_tag to identify all the link fragments 501 that belong to a given datagram. 503 Upon receipt of a link fragment, the recipient starts constructing 504 the original unfragmented packet whose size is datagram_size. It 505 uses the datagram_offset field to determine the location of the 506 individual fragments within the original unfragmented packet. For 507 example, it may place the data payload (except the encapsulation 508 header) within a payload datagram reassembly buffer at the location 509 specified by datagram_offset. The size of the reassembly buffer 510 SHALL be determined from datagram_size. 512 If a link fragment is received that overlaps another fragment as 513 identified above and differs in either the size or datagram_offset of 514 the overlapped fragment, the fragment(s) already accumulated in the 515 reassembly buffer SHALL be discarded. A fresh reassembly may be 516 commenced with the most recently received link fragment. Fragment 517 overlap is determined by the combination of datagram_offset from the 518 encapsulation header and "Frame Length" from the 802.15.4 PPDU packet 519 header. 521 Upon detection of a IEEE 802.15.4 Disassociation event, fragment 522 recipients MUST discard all link fragments of all partially 523 reassembled payload datagrams, and fragment senders MUST discard all 524 not yet transmitted link fragments of all partially transmitted 525 payload (e.g., IPv6) datagrams. Similarly, when a node first 526 receives a fragment with a given datagram_tag, it starts a reassembly 527 timer. When this time expires, if the entire packet has not been 528 reassembled, the existing fragments MUST be discarded and the 529 reassembly state MUST be flushed. The reassembly timeout MUST be set 530 to a maximum of 60 seconds (this is also the timeout in the IPv6 531 reassembly procedure [RFC2460] ). 533 6. Stateless Address Autoconfiguration 535 This section defines how to obtain an IPv6 interface identifier. 537 The Interface Identifier [RFC4291] for an IEEE 802.15.4 interface may 538 be based on the EUI-64 identifier [EUI64] assigned to the IEEE 539 802.15.4 device. In this case, the Interface Identifier is formed 540 from the EUI-64 according to the "IPv6 over Ethernet" specification 541 [RFC2464]. 543 All 802.15.4 devices have an IEEE EUI-64 address, but 16-bit short 544 addresses (Section 3 and Section 12) are also possible. In these 545 cases, a "pseudo 48-bit address" is formed as follows. First, the 546 left-most 32 bits are formed by concatenating 16 zero bits to the 16- 547 bit PAN ID (alternatively, if no PAN ID is known, 16 zero bits may be 548 used). This produces a 32-bit field as follows: 550 16_bit_PAN:16_zero_bits 552 Then, these 32 bits are concatenated with the 16-bit short address. 553 This produces a 48-bit address as follows: 555 32_bits_as_specified_previously:16_bit_short_address 557 The interface identifier is formed from this 48-bit address as per 558 the "IPv6 over Ethernet" specification [RFC2464]. However, in the 559 resultant interface identifier, the "Universal/Local" (U/L) bit SHALL 560 be set to 0 in keeping with the fact that this is not a globally 561 unique value. For either address format, all zero addresses MUST NOT 562 be used. 564 A different MAC address set manually or by software MAY be used to 565 derive the Interface Identifier. If such a MAC address is used, its 566 global uniqueness property should be reflected in the value of the 567 U/L bit. 569 An IPv6 address prefix used for stateless autoconfiguration 570 [I-D.ietf-ipv6-rfc2462bis] of an IEEE 802.15.4 interface MUST have a 571 length of 64 bits. 573 7. IPv6 Link Local Address 575 The IPv6 link-local address [RFC4291] for an IEEE 802.15.4 interface 576 is formed by appending the Interface Identifier, as defined above, to 577 the prefix FE80::/64. 579 10 bits 54 bits 64 bits 580 +----------+-----------------------+----------------------------+ 581 |1111111010| (zeros) | Interface Identifier | 582 +----------+-----------------------+----------------------------+ 584 Figure 12 586 8. Unicast Address Mapping 588 The address resolution procedure for mapping IPv6 non-multicast 589 addresses into IEEE 802.15.4 link-layer addresses follows the general 590 description in section 7.2 of [I-D.ietf-ipv6-2461bis], unless 591 otherwise specified. 593 The Source/Target Link-layer Address option has the following forms 594 when the link layer is IEEE 802.15.4 and the addresses are EUI-64 or 595 16-bit short addresses, respectively. 597 0 1 598 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Type | Length=2 | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | | 603 +- IEEE 802.15.4 -+ 604 | EUI-64 | 605 +- -+ 606 | | 607 +- Address -+ 608 | | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 +- Padding -+ 612 | | 613 +- (all zeros) -+ 614 | | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 0 1 618 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Type | Length=1 | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | 16-bit short Address | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | | 625 +- Padding -+ 626 | (all zeros) | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 Figure 13 631 Option fields: 633 Type: 634 1: for Source Link-layer address. 635 2: for Target Link-layer address. 637 Length: This is the length of this option (including the type and 638 length fields) in units of 8 octets. The value of this field is 2 639 if using EUI-64 addresses, or 1 if using 16-bit short addresses. 641 IEEE 802.15.4 Address: The 64-bit IEEE 802.15.4 address, or the 16- 642 bit short address (as per the format in Section 9), in canonical 643 bit order. This is the address the interface currently responds 644 to. This address may be different from the built-in address used 645 to derive the Interface Identifier, because of privacy or security 646 (e.g., of neighbor discovery) considerations. 648 9. Multicast Address Mapping 650 The functionality in this section MUST only be used in a mesh-enabled 651 LoWPAN. An IPv6 packet with a multicast destination address DST, 652 consisting of the sixteen octets DST[1] through DST[16], is 653 transmitted to the following 802.15.4 16-bit multicast address: 655 0 1 656 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 |1 0 0|DST[15]* | DST[16] | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Figure 14 663 Here, DST[15]* refers to the last 5 bits in octet DST[15], that is, 664 bits 3-7 within DST[15]. The initial 3-bit pattern of "100" follows 665 the 16-bit address format for multicast addresses (Section 12). 667 This allows for multicast support within 6LoWPAN networks, but the 668 full specification of such support is out of scope of this document. 669 Example mechanisms are: flooding, controlled flooding, unicasting to 670 the PAN coordinator, etc. It is expected that this would be 671 specified by the different mesh routing mechanisms. 673 10. Header Compression 675 There is much published and in-progress standardization work on 676 header compression. Nevertheless, header compression for IPv6 over 677 IEEE 802.15.4 has differing constraints summarized as follows: 679 Existing work assumes that there are many flows between any two 680 devices. Here, we assume a very simple and low-context flavor of 681 header compression. Whereas this works independently of flows 682 (potentially several), it does not use any context specific to any 683 flow. Thus, it cannot achieve as much compression as schemes that 684 build separate context for each flow to be compressed. 686 Given the very limited packet sizes, it is highly desirable to 687 integrate layer 2 with layer 3 compression, something 688 traditionally not done (although now changing due to the ROHC 689 working group). 691 It is expected that IEEE 802.15.4 devices will be deployed in 692 multi-hop networks. However, header compression in a mesh departs 693 from the usual point-to-point link scenario in which the 694 compressor and decompressor are in direct and exclusive 695 communication with each other. In an IEEE 802.15.4 network, it is 696 highly desirable for a device to be able to send header compressed 697 packets via any of its neighbors, with as little preliminary 698 context-building as possible. 700 Any new packets formats required by header compression reuse the 701 basic packet formats defined in Section 5 by using different dispatch 702 values. 704 10.1. Encoding of IPv6 Header Fields 706 By virtue of having joined the same 6LoWPAN network, devices share 707 some state. This makes it possible to compress headers without 708 explicitly building any compression context state. Therefore, 709 6LoWPAN header compression does not keep any flow state; instead, it 710 relies on information pertaining to the entire link. The following 711 IPv6 header values are expected to be common on 6LoWPAN networks, so 712 the HC1 header has been constructed to efficiently compress them from 713 the onset: Version is IPv6; both IPv6 source and destination 714 addresses are link local; the IPv6 interface identifiers (bottom 64 715 bits) for the source or destination addresses can be inferred from 716 the layer two source and destination addresses (of course, this is 717 only possible for interface identifiers derived from an underlying 718 802.15.4 MAC address); the packet length can be inferred either from 719 layer two ("Frame Length" in the IEEE 802.15.4 PPDU) or from the 720 "datagram_size" field in the fragment header (if present); both the 721 Traffic Class and the Flow Label are zero; and the Next Header is 722 UDP, ICMP or TCP. The only field in the IPv6 header that always 723 needs to be carried in full is the Hop Limit (8 bits). Depending on 724 how closely the packet matches this common case, different fields may 725 not be compressible thus needing to be carried "in-line" as well 726 (Section 10.3.1). This common IPv6 header (as mentioned above) can 727 be compressed to 2 octets (1 octet for the HC1 encoding and 1 octet 728 for the Hop Limit), instead of 40 octets. Such a packet is 729 compressible via the LOWPAN_HC1 format by using a Dispatch value of 730 LOWPAN_HC1 followed by a LOWPAN_HC1 header "HC1 encoding" field (8 731 bits) to encode the different combinations as shown below. This 732 header may be preceded by a fragmentation header, which may be 733 preceded by a mesh header. 735 1 2 3 736 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 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 | HC1 encoding | Non-Compressed fields follow... 739 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 Figure 15: LOWPAN_HC1 (common compressed header encoding) 743 As can be seen below (bit 7), an HC2 encoding may follow an HC1 744 octet. In this case, the non-compressed fields follow the HC2 745 encoding field Section 10.3. 747 The address fields encoded by "HC1 encoding" are interpreted as 748 follows: 750 PI: Prefix carried in-line (Section 10.3.1). 751 PC: Prefix compressed (link-local prefix assumed). 752 II: Interface identifier carried in-line (Section 10.3.1). 753 IC: Interface identifier elided (derivable from the corresponding 754 link-layer address). If applied to the interface identifier of 755 either the source or destination address when routing in a mesh 756 (Section 11), the corresponding link-layer address is that 757 found in the "Mesh Addressing" field (Section 5.2). 759 The "HC1 encoding" is shown below (starting with bit 0 and ending at 760 bit 7): 762 IPv6 source address (bits 0 and 1): 763 00: PI, II 764 01: PI, IC 765 10: PC, II 766 11: PC, IC 768 IPv6 destination address (bits 2 and 3): 769 00: PI, II 770 01: PI, IC 771 10: PC, II 772 11: PC, IC 774 Traffic Class and Flow Label (bit 4): 775 0: not compressed, full 8 bits for Traffic Class and 20 bits 776 for Flow Label are sent 778 1: Traffic Class and Flow Label are zero 780 Next Header (bits 5 and 6): 781 00: not compressed, full 8 bits are sent 782 01: UDP 783 10: ICMP 784 11: TCP 786 HC2 encoding(bit 7): 787 0: No more header compression bits 788 1: HC1 encoding immediately followed by more header compression 789 bits per HC2 encoding format. Bits 5 and 6 determine which 790 of the possible HC2 encodings apply (e.g., UDP, ICMP or TCP 791 encodings). 793 10.2. Encoding of UDP Header Fields 795 Bits 5 and 6 of the LOWPAN_HC1 allows compressing the Next Header 796 field in the IPv6 header (for UDP, TCP and ICMP). Further 797 compression of each of these protocol headers is also possible. This 798 section explains how the UDP header itself may be compressed. The 799 HC2 encoding in this section is the HC_UDP encoding, and it only 800 applies if bits 5 and 6 in HC1 indicate that the protocol that 801 follows the IPv6 header is UDP. The HC_UDP encoding (Figure 16) 802 allows compressing the following fields in the UDP header: source 803 port, destination port and length. The UDP header's checksum field 804 is not compressed and is therefore carried in full. The scheme 805 defined below allows compressing the UDP header to 4 octets instead 806 of the original 8 octets. 808 The only UDP header field whose value may be deduced from information 809 available elsewhere is the Length. The other fields must be carried 810 in-line either in full or in a partially compressed manner 811 (Section 10.3.2). 813 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 |HC_UDP encoding| Fields carried in-line follow... 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 Figure 16: HC_UDP (UDP common compressed header encoding) 821 The "HC_UDP encoding" for UDP is shown below (starting with bit 0 and 822 ending at bit 7): 824 UDP source port (bit 0): 825 0: Not compressed, carried "in-line" (Section 10.3.2) 826 1: Compressed to 4 bits. The actual 16-bit source port is 827 obtained by calculating: P + short_port value. The value of 828 P is the number 61616 (0xF0B0). The short_port is expressed 829 as a 4-bit value which is carried "in-line" (Section 10.3.2) 831 UDP destination port (bit 1): 832 0: Not compressed, carried "in-line" (Section 10.3.2) 833 1: Compressed to 4 bits. The actual 16-bit destination port is 834 obtained by calculating: P + short_port value. The value of 835 P is the number 61616 (0xF0B0). The short_port is expressed 836 as a 4-bit value which is carried "in-line" (Section 10.3.2) 838 Length (bit 2): 839 0: not compressed, carried "in-line" (Section 10.3.2) 840 1: compressed, length computed from IPv6 header length 841 information. The value of the UDP length field is equal to 842 the Payload Length from the IPv6 header, minus the length of 843 any extension headers present between the IPv6 header and 844 the UDP header. 846 Reserved (bit 3 through 7) 848 10.3. Non-Compressed Fields 850 10.3.1. Non-Compressed IPv6 Fields 852 This scheme allows the IPv6 header to be compressed to different 853 degrees. Hence, instead of the entire (standard) IPv6 header, only 854 non-compressed fields need to be sent. The subsequent header (as 855 specified by the Next Header field in the original IPv6 header) 856 immediately follows the IPv6 non-compressed fields. 858 Uncompressed IPv6 addressing is described by a dispatch type 859 containing an IPv6 dispatch value followed by the uncompressed IPv6 860 header. This dispatch type may be preceded by additional LoWPAN 861 headers. 863 The non-compressed IPv6 field that MUST be always present is the Hop 864 Limit (8 bits). This field MUST always follow the encoding fields 865 (e.g., "HC1 encoding" as shown in Figure 15), perhaps including other 866 future encoding fields). Other non-compressed fields MUST follow the 867 Hop Limit as implied by the "HC1 encoding" in the exact same order as 868 shown above (Section 10.1): source address prefix (64 bits) and/or 869 interface identifier (64 bits), destination address prefix (64 bits) 870 and/or interface identifier (64 bits), Traffic Class (8 bits), Flow 871 Label (20 bits) and Next Header (8 bits). The actual next header 872 (e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields. 874 10.3.2. Non-Compressed and partially compressed UDP fields 876 This scheme allows the UDP header to be compressed to different 877 degrees. Hence, instead of the entire (standard) UDP header, only 878 non-compressed or partially compressed fields need to be sent. 880 The non-compressed or partially compressed fields in the UDP header 881 MUST always follow the IPv6 header and any of its associated in-line 882 fields. Any UDP header in-line fields present MUST appear in the 883 same order as the corresponding fields appear in a normal UDP header 884 [RFC0768], e.g., source port, destination port, length and checksum. 885 If either the source or destination ports are in "short_port" 886 notation (as indicated in the compressed UDP header), then instead of 887 taking 16 bits, the inline port numbers take 4 bits. 889 11. Frame Delivery in a Link-Layer Mesh 891 Even though 802.15.4 networks are expected to commonly use mesh 892 routing, the IEEE 802.15.4-2003 specification [ieee802.15.4] does not 893 define such capability. In such cases, Full Function Devices (FFDs) 894 run an ad hoc or mesh routing protocol to populate their routing 895 tables (outside the scope of this document). In such mesh scenarios, 896 two devices do not require direct reachability in order to 897 communicate. Of these devices, the sender is known as the 898 "Originator", and the receiver is known as the "Final Destination". 899 An originator device may use other intermediate devices as forwarders 900 towards the final destination. In order to achieve such frame 901 delivery using unicast, it is necessary to include the link-layer 902 addresses of the originator and final destinations, in addition to 903 the hop-by-hop source and destination. 905 This section defines how to effect delivery of layer 2 frames in a 906 mesh, given a target "Final Destination" link-layer address. 908 Mesh delivery is enabled by including a Mesh Addressing header prior 909 to any other headers of the LoWPAN encapsulation (Section 5), 910 unfragmented and fragmented, a full-blown IPv6 header, or a 911 compressed IPv6 header as per Section 10, or any others defined 912 elsewhere. 914 If a node wishes to use a default mesh forwarder to deliver a packet 915 (i.e., because it does not have direct reachability to the 916 destination), it MUST include a Mesh Addressing header with the 917 originator's link-layer address set to its own, and the final 918 destination's link-layer address set to the packet's ultimate 919 destination. It sets the source address in the 802.15.4 header to 920 its own link-layer address, and puts the forwarder's link-layer 921 address in the 802.15.4 header's destination address field. Finally, 922 it transmits the packet. 924 Similarly, if a node receives a frame with a Mesh Addressing header, 925 it must look at the Mesh Addressing header's "Final Destination" 926 field to determine the real destination. If the node is itself the 927 final destination, it consumes the packet as per normal delivery. If 928 it is not the final destination, the device then reduces the "Hops 929 Left" field, and if the result is zero, discards the packet. 930 Otherwise, the node consults its link-layer routing table, determines 931 what the next hop towards the final destination should be, and puts 932 that address in the destination address field of the 802.15.4 header. 933 Finally, the node changes the source address in the 802.15.4 header 934 to its own link-layer address and transmits the packet. 936 Whereas a node must participate in a mesh routing protocol to be a 937 forwarder, no such requirement exists for simply using mesh 938 forwarding. Only "Full Function Devices" (FFDs) are expected to 939 participate as routers in a mesh. "Reduced Function Devices" (RFDs) 940 limit themselves to discovering FFDs and using them for all their 941 forwarding, in a manner similar to how IP hosts typically use default 942 routers to forward all their off-link traffic. For an RFD using mesh 943 delivery, the "forwarder" is always the appropriate FFD. 945 11.1. LoWPAN Broadcast 947 Additional mesh routing functionality is encoded using a routing 948 header immediately following the Mesh header. In particular, a 949 broadcast header consists of a LOWPAN_BC0 dispatch followed by a 950 sequence number field. The sequence number is used to detect 951 duplicate packets (and hopefully suppress them). 953 1 954 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 |0|1|LOWPAN_BC0 |Sequence Number| 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 Figure 17: Broadcast Header 961 Field definitions are as follows: 963 Sequence Number: This 8-bit field SHALL be incremented by the 964 originator whenever it sends a new mesh broadcast or multicast 965 packet. Full specification of how to handle this field is out of 966 scope of this document. 968 Further implications of such mesh-layer broadcast, e.g., whether it 969 maps to a controlled flooding mechanism or its role in, say, topology 970 discovery, is out of scope of this document. 972 Additional mesh routing capabilities, such as specifying the mesh 973 routing protocol, source routing, and so on may be expressed by 974 defining additional routing headers that preceed the fragmentation or 975 addressing header in the header stack. The full specification of 976 such mesh routing capabilities are out of scope of this document. 978 12. IANA Considerations 980 This document creates two new IANA registries, as discussed below. 981 Future assignments in these registries are to be coordinated via IANA 982 under the policy of "Specification Required" [RFC2434]. It is 983 expected that this policy will allow for other (non-IETF) 984 organizations to more easily obtain assignments. 986 This document creates a new IANA registry for the Dispatch type field 987 shown in the header definitions Section 5. This document defines the 988 values IPv6, LOWPAN_HC1 header compression, BC0 broadcast and two 989 escape patterns (NALP to indicate not a LOWPAN frame and ESC to allow 990 additional dispatch bytes). This document defines this field to be 8 991 bits long. The values 00xxxxxx being reserved and not used, this 992 allows for a total of 192 different values, which should be more than 993 enough. If header compression formats in addition to HC1 are defined 994 or if additional TCP, ICMP HC2 formats are defined, it is expected 995 that these will use reserved dispatch values following LOWPAN_HC1. 996 If additional mesh delivery formats are defined these will use 997 reserved values following LOWPAN_BC0. 999 This document creates a new IANA registry for the 16-bit short 1000 address fields as used in 6LoWPAN packets. 1002 0 1 1003 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1005 | 16-bit short Address | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 Figure 18 1009 This registry MUST include the addresses 0xffff (16-bit broadcast 1010 address accepted by all devices currently listening to the channel) 1011 and 0xfffe as defined in [ieee802.15.4]. Additionally, within 1012 6LoWPAN networks, 16-bit short addresses MUST follow this format 1013 (referring to bit fields in the order from 0 to 7), where "x" is a 1014 place holder for an unspecified bit value: 1016 Range 1, Oxxxxxxxxxxxxxxx: The first bit (bit 0) SHALL be zero if 1017 the 16-bit address is a unicast address. This leaves 15 bits for 1018 the actual address. 1020 Range 2, 100xxxxxxxxxxxxx: Bits 0,1 and 2 SHALL follow this pattern 1021 if the 16-bit address is a multicast address (see Section 9). 1022 This leaves 13 bits for the actual multicast address. 1024 Range 3, 101xxxxxxxxxxxxx: This pattern for bits 0,1 and 2 is 1025 reserved. Any future assignment shall follow the policy mentioned 1026 above. 1028 Range 4, 110xxxxxxxxxxxxx: This pattern for bits 0,1 and 2 is 1029 reserved. Any future assignment shall follow the policy mentioned 1030 above. 1032 Range 5, 111xxxxxxxxxxxxx: This pattern for bits 0,1 and 2 is 1033 reserved. Any future assignment shall follow the policy mentioned 1034 above. 1036 13. Security Considerations 1038 The method of derivation of Interface Identifiers from EUI-64 MAC 1039 addresses is intended to preserve global uniqueness when possible. 1040 However, there is no protection from duplication through accident or 1041 forgery. 1043 Neighbor Discovery in IEEE 802.15.4 links may be susceptible to 1044 threats as detailed in [RFC3756]. Mesh routing is expected to be 1045 common in IEEE 802.15.4 networks. This implies additional threats 1046 due to ad hoc routing as per [KW03]. IEEE 802.15.4 provides some 1047 capability for link-layer security. Users are urged to make use of 1048 such provisions if at all possible and practical. Doing so will 1049 alleviate the threats referred to above. 1051 A sizeable portion of IEEE 802.15.4 devices is expected to always 1052 communicate within their PAN (i.e., within their link, in IPv6 1053 terms). In response to cost and power consumption considerations, 1054 and in keeping with the IEEE 802.15.4 model of "Reduced Function 1055 Devices" (RFDs), these devices will typically implement the minimum 1056 set of features necessary. Accordingly, security for such devices 1057 may rely quite strongly on the mechanisms defined at the link-layer 1058 by IEEE 802.15.4. The latter, however, only defines the AES modes 1059 for authentication or encryption of IEEE 802.15.4 frames, and does 1060 not, in particular, specify key management (presumably group 1061 oriented). Other issues to address in real deployments relate to 1062 secure configuration and management. Whereas such a complete picture 1063 is out of scope of this document, it is imperative that IEEE 802.15.4 1064 networks be deployed with such considerations in mind. Of course, it 1065 is also expected that some IEEE 802.15.4 devices (the so-called "Full 1066 Function Devices", or "FFDs") will implement coordination or 1067 integration functions. These may communicate regularly with off-link 1068 IPv6 peers (in addition to the more common on-link exchanges). Such 1069 IPv6 devices are expected to secure their end-to-end communications 1070 with the usual mechanisms (e.g., IPsec, TLS, etc). 1072 14. Acknowledgements 1074 Thanks to the authors of RFC 2464 and RFC 2734, as parts of this 1075 document are patterned after theirs. Thanks to Geoff Mulligan for 1076 useful discussions which helped shape this document. Erik Nordmark's 1077 suggestions were instrumental for the header compression section. 1078 Also thanks to Shoichi Sakane, Samita Chakrabarti, Vipul Gupta, 1079 Carsten Bormann, Ki-Hyung Kim, Mario Mao, Phil Levis, Magnus 1080 Westerlund and Jari Arkko. 1082 15. References 1084 15.1. Normative References 1086 [I-D.ietf-ipv6-2461bis] 1087 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 1088 draft-ietf-ipv6-2461bis-11 (work in progress), March 2007. 1090 [I-D.ietf-ipv6-rfc2462bis] 1091 Thomson, S., "IPv6 Stateless Address Autoconfiguration", 1092 draft-ietf-ipv6-rfc2462bis-08 (work in progress), 1093 May 2005. 1095 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", BCP 14, RFC 2119, March 1997. 1098 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1099 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1100 October 1998. 1102 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1103 (IPv6) Specification", RFC 2460, December 1998. 1105 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 1106 Networks", RFC 2464, December 1998. 1108 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1109 Architecture", RFC 4291, February 2006. 1111 [ieee802.15.4] 1112 IEEE Computer Society, "IEEE Std. 802.15.4-2003", 1113 October 2003. 1115 15.2. Informative References 1117 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 1118 REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/ 1119 regauth/oui/tutorials/EUI64.html. 1121 [KW03] Karlof, Chris and Wagner, David, "Secure Routing in Sensor 1122 Networks: Attacks and Countermeasures", Elsevier's AdHoc 1123 Networks Journal, Special Issue on Sensor Network 1124 Applications and Protocols vol 1, issues 2-3, 1125 September 2003. 1127 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1128 August 1980. 1130 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1131 Discovery (ND) Trust Models and Threats", RFC 3756, 1132 May 2004. 1134 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1135 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1136 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1137 RFC 3819, July 2004. 1139 Appendix A. Alternatives for Delivery of Frames in a Mesh 1141 Before settling on the mechanism finally adopted for delivery in a 1142 mesh (Section 11), several alternatives were considered. In addition 1143 to the hop-by-hop source and destination link-layer addresses, 1144 delivering a packet in a LoWPAN mesh requires the end-to-end 1145 originator and destination addresses. These could be expressed 1146 either as layer 2 or as layer 3 (i.e., IP ) addresses. In the latter 1147 case, there would be no need to provide any additional header support 1148 in this document (i.e., within the LoWPAN header itself). The link- 1149 layer destination address would point to the next hop destination 1150 address while the IP header destination address would point to the 1151 final destination (IP) address (possibly multiple hops away from the 1152 source), and similarly for the source addresses. Thus, while 1153 forwarding data, the single-hop source and destination addresses 1154 would change at each hop (always pointing to the node doing the 1155 forwarding and the "best" next link-layer hop, respectively), while 1156 the source and destination IP addresses would remain unchanged. 1157 Notice that if an IP packet is fragmented, the individual fragments 1158 may arrive at any node out of order. If the initial fragment (which 1159 contains the IP header) is delayed for some reason, a node that 1160 receives a subsequent fragment would lack the required information. 1161 It would be forced to wait until it receives the IP header (within 1162 the first fragment) before being able to forward the fragment any 1163 further. This imposes some additional buffering requirements on 1164 intermediate nodes. Additionally, such a specification would only 1165 work for one type of LoWPAN payload: IPv6. In general, it would have 1166 to be adapted for any other payload, and would require that payload 1167 to provide its own end-to-end addressing information. 1169 On the other hand, the approach finally followed (Section 11) creates 1170 a mesh at the LoWPAN layer (below layer 3). Accordingly, link-layer 1171 originator and final destination address are included within the 1172 LoWPAN header. This enables mesh delivery for any protocol or 1173 application layered on the LoWPAN adaptation layer (Section 5). For 1174 IPv6 as supported in this document, another advantage of expressing 1175 the originator and final destinations as layer 2 addresses is that 1176 the IPv6 addresses can be compressed as per the header compression 1177 specified in Section 10. Furthermore, the number of octets needed to 1178 maintain routing tables is reduced due to the smaller size of 1179 802.15.4 addresses (either 64 bits or 16 bits) as compared to IPv6 1180 addresses (128 bits). A disadvantage is that applications on top of 1181 IP do not address packets to link-layer destination addresses, but to 1182 IP (layer 3) destination addresses. Thus, given an IP address, there 1183 is a need to resolve the corresponding link-layer address. 1184 Accordingly, a mesh routing specification needs to clarify the 1185 Neighbor Discovery implications, although in some special cases, it 1186 may be possible to derive a device's address at layer 2 from its 1187 address at layer 3 (and viceversa). Such complete specification is 1188 outside the scope of this document. 1190 Appendix B. Changes 1192 Changes up to version 13 are as follows: 1194 Fixed note about datagram_size: it needs to codify a max of 1280. 1196 Changed multicast address mapping from MAY in a mesh configuration 1197 to a MUST only use in a mesh configuration. 1199 Changes up to version 12 are as follows: 1201 Datagram_tag size increased. 1203 Fixed UDP port P done without IANA intervention. 1205 Deleted unused references, and various editorial clarifications 1206 and issues resulting from IESG review. 1208 Changes up to version 11 are as follows: 1210 Changed to MUST discard (from SHOULD) fragments after a disconnect 1211 or reassembly timeout expiration. 1213 3rd last para of section 6: Added reference to IPv6 over Ethernet 1214 in addition to that in the 1st paragraph. 1216 Changes up to version 09 and 10 are as follows: 1218 Editorial changes, typos, nits. 1220 Changes up to version draft-ietf-6lowpan-format-08.txt are as 1221 follows: 1223 Clarification of dispatch header name space and Mesh Delivery 1224 Header. 1226 Changes up to version draft-ietf-6lowpan-format-07.txt are as 1227 follows: 1229 Conversion to stacked header layout analogous to IPv6 headers. 1231 Changes up to version draft-ietf-6lowpan-format-06.txt are as 1232 follows: 1234 Further clarification in the reassembly procedures. 1236 Editorial nits and corrections. 1238 Changes up to version draft-ietf-6lowpan-format-05.txt are as 1239 follows: 1241 Added some padding bits to the first and subsequent fragment 1242 formats to align on an octet boundary. 1244 Header compression may result in alignment not falling on an octet 1245 boundary. Since hardware typically cannot transmit units less 1246 than an octet, added text to the effect that one lays out the 1247 contiguous compressed headers and then zero bits SHOULD BE added 1248 as appropriate to align to an octet boundary. 1250 Added how to distinguish between the multicast and the unicast 1251 formats for the mesh delivery field. We use one of the 5 reserved 1252 bits to signal if the bcast/mcast mesh delivery format is being 1253 used, and we called it the 'B' ("broadcast") bit. So no change to 1254 the mesh delivery fields is required. Since the reserved bits are 1255 common to all three lowpan header formats, the 'B' bit applies to 1256 all. 1258 Changes from version draft-ietf-6lowpan-format-02.txt to version 1259 draft-ietf-6lowpan-format-03.txt are as follows: 1261 Interface Identifier derivation using 16-bit short addresses now 1262 using the PAN ID as well. 1264 Word of caution on the transient nature of 16 bit short addresses. 1266 Reassembly now also keying on destination and datagram_size. 1268 Mesh delivery header now allowing mix of 16/64 bit addresses. 1269 This leaves 6 bits for hops_left (64 hops is plenty). 1271 Added optional Multicast Address mapping patterned after that of 1272 ethernet. 1274 Clarified that all zero addresses must not be used (for either 16 1275 or 64 bit formats). 1277 Added address format section to IANA considerations to define 1278 unicast, multicast and reserved address formats. 1280 Added Mesh Broadcast or Multicast Delivery Field. 1282 Created a new section on Addressing Modes. 1284 Sundry editorial changes. 1286 Changes from version draft-ietf-6lowpan-format-01.txt to version 1287 draft-ietf-6lowpan-format-02.txt are as follows: 1289 Further details on broadcast by using PAN-specific broadcast. 1291 Sundry editorial changes. 1293 Changes from version draft-ietf-6lowpan-format-00.txt to version 1294 draft-ietf-6lowpan-format-01.txt are as follows: 1296 Added a reassembly timeout of 15 sec. 1298 Added support for 16-bit "short" addresses. 1300 datagram tag now at 10 bits protocol_type and datagram offset both 1301 went from 11 to 8 bits (which is still enough for the format, and 1302 which implies counting offset in units of 8 octets for the 1303 latter). 1305 Addition of the originator's link-layer source address to the 1306 "Mesh Delivery" header. 1308 Changed name of "Final Destination" header to "Mesh Delivery" 1309 header. 1311 Further clarification on mesh delivery. 1313 Sundry editorial changes. 1315 Changes from version 1316 draft-montenegro-lowpan-ipv6-over-802.15.4-02.txt to version 1317 draft-ietf-6lowpan-format-00.txt are as follows: 1319 The LoWPAN encapsulation was modified to allow 11 bits of protocol 1320 type (prot_type field). Because of this, the minimum overhead 1321 grew from 1 octet to 2 octets. This was done in order to allow 1322 more protocol types as the previous format started with a field 1323 only 5 bits wide. Whereas growing it to 7 bits was possible in 1324 the future, this would always entail 2 octets of overhead for the 1325 longer protocol types to be used. 1327 The 'M' bit had been left out of the 3rd packet format (for 1328 subsequent fragments). Corrected this oversight. This means that 1329 the fragment tag lost one bit. 1331 Sundry editorial changes. 1333 Authors' Addresses 1335 Gabriel Montenegro 1336 Microsoft Corporation 1338 Email: gabriel.montenegro@microsoft.com 1340 Nandakishore Kushalnagar 1341 Intel Corp 1343 Email: nandakishore.kushalnagar@intel.com 1345 Jonathan W. Hui 1346 Arch Rock Corp 1348 Email: jhui@archrock.com 1350 David E. Culler 1351 Arch Rock Corp 1353 Email: dculler@archrock.com 1355 Full Copyright Statement 1357 Copyright (C) The IETF Trust (2007). 1359 This document is subject to the rights, licenses and restrictions 1360 contained in BCP 78, and except as set forth therein, the authors 1361 retain all their rights. 1363 This document and the information contained herein are provided on an 1364 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1365 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1366 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1367 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1368 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1369 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1371 Intellectual Property 1373 The IETF takes no position regarding the validity or scope of any 1374 Intellectual Property Rights or other rights that might be claimed to 1375 pertain to the implementation or use of the technology described in 1376 this document or the extent to which any license under such rights 1377 might or might not be available; nor does it represent that it has 1378 made any independent effort to identify any such rights. Information 1379 on the procedures with respect to rights in RFC documents can be 1380 found in BCP 78 and BCP 79. 1382 Copies of IPR disclosures made to the IETF Secretariat and any 1383 assurances of licenses to be made available, or the result of an 1384 attempt made to obtain a general license or permission for the use of 1385 such proprietary rights by implementers or users of this 1386 specification can be obtained from the IETF on-line IPR repository at 1387 http://www.ietf.org/ipr. 1389 The IETF invites any interested party to bring to its attention any 1390 copyrights, patents or patent applications, or other proprietary 1391 rights that may cover technology that may be required to implement 1392 this standard. Please address the information to the IETF at 1393 ietf-ipr@ietf.org. 1395 Acknowledgment 1397 Funding for the RFC Editor function is provided by the IETF 1398 Administrative Support Activity (IASA).