idnits 2.17.1 draft-montenegro-lowpan-ipv6-over-802.15.4-02.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.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 936. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 913. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 920. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 926. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Bad filename characters: the document name given in the document, 'draft-montenegro-lowpan-ipv6-over-802.15.4-02', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 200 has weird spacing: '...certain appli...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (February 21, 2005) is 7002 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: 'I-D.ietf-ipngwg-icmp-v3' is defined on line 857, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-node-requirements' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC3439' is defined on line 881, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-01 == Outdated reference: A later version (-08) exists of draft-ietf-ipv6-rfc2462bis-07 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-06 Summary: 9 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Montenegro 3 Internet-Draft Sun Microsystems, Inc. 4 Expires: August 22, 2005 N. Kushalnagar 5 Intel Corp 6 February 21, 2005 8 Transmission of IPv6 Packets over IEEE 802.15.4 Networks 9 draft-montenegro-lowpan-ipv6-over-802.15.4-02 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 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 23 Internet-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 August 22, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 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. Maximum Transmission Unit . . . . . . . . . . . . . . . . . . 4 58 4. Adaptation Layer and Frame Format . . . . . . . . . . . . . . 6 59 4.1 Link Fragmentation . . . . . . . . . . . . . . . . . . . . 6 60 4.2 Reassembly . . . . . . . . . . . . . . . . . . . . . . . . 9 61 5. Stateless Address Autoconfiguration . . . . . . . . . . . . . 9 62 6. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . 10 63 7. Unicast Address Mapping . . . . . . . . . . . . . . . . . . . 10 64 8. Header Compression . . . . . . . . . . . . . . . . . . . . . . 11 65 8.1 Encoding of IPv6 Header Fields . . . . . . . . . . . . . . 12 66 8.2 Encoding of UDP Header Fields . . . . . . . . . . . . . . 14 67 8.3 Non-Compressed . . . . . . . . . . . . . . . . . . . . . . 15 68 8.3.1 Non-Compressed IPv6 Fields . . . . . . . . . . . . . . 15 69 8.3.2 Non-Compressed and partially compressed UDP fields . . 15 70 9. Packet Delivery in a Link-Layer Mesh . . . . . . . . . . . . . 16 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 72 11. Security Considerations . . . . . . . . . . . . . . . . . . 18 73 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 74 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 75 13.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 76 13.2 Informative References . . . . . . . . . . . . . . . . . . . 20 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 78 Intellectual Property and Copyright Statements . . . . . . . . 22 80 1. Introduction 82 The IEEE 802.15.4 standard [ieee802.15.4] targets low power personal 83 area networks. This document defines the frame format for 84 transmission of IPv6 [RFC2460] packets as well as the formation of 85 IPv6 link-local addresses and statelessly autoconfigured addresses on 86 top of IEEE 802.15.4 networks. Since IPv6 requires support of packet 87 sizes much larger than the largest IEEE 802.15.4 frame size, an 88 adaptation layer is defined. This document also defines mechanisms 89 for header compression required to make IPv6 practical on IEEE 90 802.15.4 networks. Likewise, the provisions required for packet 91 delivery in IEEE 802.15.4 meshes is defined. However, a full 92 specification of mesh routing (the specific protocol used, the 93 interactions with neighbor discovery, etc) is out of scope of this 94 document. 96 1.1 Requirements notation 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 1.2 Terms used 104 AES: Advanced Encryption Scheme 105 CSMA/CA: Carrier Sense Multiple Access / Collision Avoidance 106 FFD: Full Function Device 107 GTS: Guaranteed Time Service 108 MTU: Maximum Transmission Unit 109 MAC: Media Access Control 110 PAN: Personal Area Network 111 RFD: Reduced Function Device 113 2. IEEE 802.15.4 mode for IP 115 IEEE 802.15.4 defines four types of frames: beacon frames, MAC 116 command frames, acknowledgement frames and data frames. IPv6 packets 117 MUST be carried on data frames. Data frames may optionally request 118 that they be acknowledged. In keeping with [RFC3819] it is 119 recommended that IPv6 packets be carried in frames for which 120 acknowledgements are requested so as to aid link-layer recovery. 121 IEEE 802.15.4 networks can either be nonbeacon-enabled or 122 beacon-enabled [ieee802.15.4]. The latter is an optional mode in 123 which devices are synchronized by a so-called coordinator's beacons. 124 This allows the use of superframes within which a contention-free 125 Guaranteed Time Service (GTS) is possible. This document does not 126 require that IEEE networks run in beacon-enabled mode. In 127 nonbeacon-enabled networks, data frames (including those carrying 128 IPv6 packets) are sent via the contention-based channel access method 129 of unslotted CSMA/CA. 131 In nonbeacon-enabled networks, beacons are not used for 132 synchronization. However, they are still useful for link-layer 133 device discovery to aid in association and disassociation events. 134 This document recommends that beacons be configured so as to aid 135 these functions. A further recommendation is for these events to be 136 available at the IPv6 layer to aid in detecting network attachment, a 137 problem being worked on at the IETF at the time of this writing. 139 IEEE 802.15.4 defines several addressing modes. The specification 140 allows for frames in which either the source or destination addresses 141 (or both) are elided. The mechanisms defined in this document 142 require that both source and destination addresses be included in the 143 IEEE 802.15.4 frame header. The source or destination PAN ID fields 144 may also be included. 146 IEEE 802.15.4 allows the use of either IEEE 64 bit extended addresses 147 or (after an association event) 16 bit addresses unique within the 148 PAN. This document assumes use of 64 bit extended addresses, but 16 149 bit address support may be added in a future revision. 151 This document assumes that a PAN maps to a specific IPv6 link, hence 152 it implies a unique prefix. If the PAN ID (16 bits) is included in 153 the IEEE 802.15.4 headers, it may be possible to use it to 154 automatically map to the corresponding IPv6 prefix. One possible 155 method is to concatenate the 16 bits of PAN ID to a /48 in order to 156 obtain the link prefix. Whichever method is used, the assumption in 157 this document is that a given PAN ID maps to a unique IPv6 prefix. 158 This complies with the recommendation that shared networks support 159 link-layer subnet [RFC3819] broadcast. Strictly speaking, it is 160 multicast not broadcast that exists in IPv6. However, multicast is 161 not supported in IEEE 802.15.4. Hence, IPv6 level multicast packets 162 MUST be carried as link-layer broadcast frames in IEEE 802.15.4 163 networks. As usual, hosts learn IPv6 prefixes via router 164 advertisements ([I-D.ietf-ipv6-2461bis]). 166 3. Maximum Transmission Unit 168 The MTU size for IPv6 packets over IEEE 802.15.4 is 1280 octets. 169 However, a full IPv6 packet does not fit in an IEEE 802.15.4 frame. 170 802.15.4 protocol data units have different sizes depending on how 171 much overhead is present [ieee802.15.4]. Starting from a maximum 172 physical layer packet size of 127 octets (aMaxPHYPacketSize) and a 173 maximum frame overhead of 25 (aMaxFrameOverhead), the resultant 174 maximum frame size at the media access control layer is 102 octets. 176 Link-layer security imposes further overhead, which in the maximum 177 case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 178 for AES-CCM-32 and AES-CCM-64, respectively) leaves only 81 octets 179 available. This is obviously far below the minimum IPv6 packet size 180 of 1280 octets, and in keeping with section 5 of the IPv6 181 specification [RFC2460], a fragmention and reassembly adaptation 182 layer must be provided at the layer below IP. Such a layer is 183 defined below in Section 4. 185 Furthermore, since the IPv6 header is 40 octets long, this leaves 186 only 41 octets for upper-layer protocols, like UDP. The latter uses 187 8 octets in the header which leaves only 33 octets for application 188 data. Additionally, as pointed out above, there is a need for a 189 fragmentation and reassembly layer, which will use even more octets. 191 The above considerations lead to the following two observations: 193 1. The adaptation layer must be provided to comply with IPv6 194 requirements of minimum MTU. However, it is expected that (a) 195 most applications of IEEE 802.15.4 will not use such large 196 packets, and (b) small application payloads in conjunction with 197 proper header compression will produce packets that fit within a 198 single IEEE 802.15.4 frame. The justification for this 199 adaptation layer is not just for IPv6 compliance, as it is quite 200 likely that the packet sizes produced by certain application 201 exchanges (e.g., configuration or provisioning) may require a 202 small number of fragments. 204 2. Even though the above space calculation shows the worst case 205 scenario, it does point out the fact that header compression is 206 compelling to the point of almost being unavoidable. Since we 207 expect that most (if not all) applications of IP over IEEE 208 802.15.4 will make use of header compression, it is defined below 209 in Section 8. 211 NOTE: In traditional IEEE 802 applications, a further 8 octets are 212 taken up by LLC/SNAP encapsulation [RFC1042], which would leave only 213 73 octets for upper layer protocols (e.g., IP). SNAP encapsulation 214 is not used in this specification. Any heartburn about this? Must 215 think about compatibility with other applications (what do these 216 do?). To guarantee interoperability, we might want to add the SNAP 217 header. It's just more fixed overhead, as instead of following with 218 the ether_type for IPv6 (and overloading the version field as per the 219 hack in RFCs 1144 and 2507), we would want to follow the SNAP header 220 with a new identifier for the adaptation layer defined below. 222 4. Adaptation Layer and Frame Format 224 4.1 Link Fragmentation 226 All IP datagrams transported over IEEE 802.15.4 are prefixed by an 227 encapsulation header with one of the formats illustrated below. The 228 encapsulation formats defined in this section are the payload in the 229 IEEE 802.15.4 MAC protocol data unit (PDU). 231 If an entire IP datagram may be transmitted within a single 802.15.4 232 packet, it is unfragmented and the first octet of the data payload 233 SHALL conform to the format illustrated below. In this case, the 234 encapsulation header size is 1 octet. It is expected that this will 235 be, by far, the most common case. 237 NOTE: All fields marked "reserved" or "rsv" SHALL be zero. 239 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | LF|prot_type|M| IPv6 packet (or Final Destination Header) | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 1: Unfragmented encapsulation header format 247 Field definitions are as follows: 249 LF: This 2 bit field SHALL be zero. 251 prot_type: This 5 bit field SHALL indicate the nature of the datagram 252 that follows. In particular, the prot_type for IPv6 is 1 253 hexadecimal. The value 2 hexadecimal is defined below for header 254 compression (Section 8). Other protocols may use this 255 encapsulation format, but such use is outside the scope of this 256 document. Subsequent assignments are to be handled by IANA 257 (Section 10). 259 NOTE: This field serves a purpose similar to that of the PPP DLL 260 or ethertype protocol numbers (16 bits). However, in the interest 261 of reducing the overhead in the common case, here we only have 6 262 bits. Assuming that we do not use the value zero, this leaves 31 263 type assignments in total. It is apparent that this may be 264 enough. But in case it is not, it is important to know that it is 265 possible to grow beyond these 5 bits. One way to do so is to 266 assume that the actual field holds 7 bits, which leaves plenty of 267 possibilities for future assignments. In such a case, the above 268 format could only be used with the first 31 types assignments. 269 Use of types beyond the initial ones assignments would require use 270 of the frame format below. This format, defined below to transmit 271 the *first* fragment, can be overloaded to mean "first *and* last" 272 (i.e., unfragmented). This can be accomplished by using a 273 datagram_label of zero (otherwise illegal), and/or simply in an 274 implicit fashion via the datagram_size information. Accordingly, 275 it seems prudent to leave a "rsv" field in front of the prot_type 276 field in the frame below, pending further discussion. 278 M: This bit is used to signal whether there is a "Final Destination" 279 field as used for ad hoc or mesh routing. If set to 1, a "Final 280 Destination" field precedes the IPv6 packet (Section 9). 282 If the datagram does not fit within a single IEEE 802.15.4 frame, it 283 SHALL be broken into link fragments. The first link fragment SHALL 284 conform to the format shown below. 286 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | LF|rsv | prot_type |M|datagram_label | datagram_size | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 Figure 2: First fragment encapsulation header format 294 The second and subsequent link fragments (up to and including the 295 last) SHALL conform to the format shown below. 297 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | LF| datagram_offset |datagram_label | datagram_size | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 Figure 3: Subsequent fragment(s) encapsulation header format 305 Field definitions are as follows: 307 LF: This 2 bit field SHALL specify the relative position of the link 308 fragment within the IP datagram, as encoded by the following 309 table. 311 LF Position 312 +-------------------------------------------+ 313 | 00 | Unfragmented (Figure 1) | 314 | 01 | First Fragment (Figure 2) | 315 | 10 | Last Fragment (Figure 3) | 316 | 11 | Interior Fragment (Figure 3) | 317 +-------------------------------------------+ 319 Figure 4: Link Fragment Bit Pattern 321 datagram_size: This 11 bit field encodes the size of the entire IP 322 datagram. The value of datagram_size SHALL be the same for all 323 link fragments of an IP datagram and SHALL be 40 octets more (the 324 size of the IPv6 header) than the value of Payload Length in the 325 datagram's IPv6 header [RFC2460]. Typically, this field needs to 326 encode a maximum length of 1280 (IEEE 802.15.4 link MTU as defined 327 in this document), and as much as 1500 (the default maximum IPv6 328 packet size if IPv6 fragmentation is in use). Therefore, this 329 field is 11 bits long, which works in either case. 331 NOTE: This field does not need to be in every packet, as one could 332 send it with the first fragment and elide it subsequently. 333 However, including it in every link fragment eases the task of 334 reassembly in the event that a second (or subsequent) link 335 fragment arrives before the first. In this case, the guarantee of 336 learning the datagram_size as soon as any of the fragments arrives 337 tells the receiver how much buffer space to set aside as it waits 338 for the rest of the fragments. The format above trades off 339 simplicity for efficiency. 341 prot_type: This 7 bit field is present only in the first link 342 fragment. For possible values, see Section 10. 344 M: This bit is only present in the first link fragment. If set to 1, 345 a "Final Destination" field to aid in mesh routing is present as 346 per Section 9. 348 fragment_offset: This field is present only in the second and 349 subsequent link fragments and SHALL specify the offset, in octets, 350 of the fragment from the beginning of the IP datagram. The first 351 octet of the datagram (the start of the IP header) has an offset 352 of zero; the implicit value of fragment_offset in the first link 353 fragment is zero. This field is 11 bits long, as per the 354 datagram_size explanation above. 356 datagram_label: The value of datagram_label (datagram label) SHALL be 357 the same for all link fragments of an IP datagram. The sender 358 SHALL increment datagram_label for successive, fragmented 359 datagrams; the incremented value of datagram_label SHALL wrap from 360 255 back to one. The value zero is not used. 362 NOTE: The value zero is reserved as per the note under Figure 1. 363 This may allow for a future overloading of the "first fragment" 364 header to also mean "first and last fragment", thus allowing the 365 use of extended protocol type numbers (8 bits instead of 6 bits). 367 All IP datagrams SHALL be preceded by one of the encapsulation 368 headers described above. This permits uniform software treatment of 369 datagrams without regard to the mode of their transmission. 371 4.2 Reassembly 373 The recipient of an IP datagram transmitted via more than one 374 802.15.4 packet SHALL use both the sender's 802.15.4 source address 375 and datagram_label to identify all the link fragments from a single 376 datagram. 378 Upon receipt of a link fragment, the recipient may place the data 379 payload (except the encapsulation header) within an IP datagram 380 reassembly buffer at the location specified by fragment_offset. The 381 size of the reassembly buffer SHALL be determined from datagram_size. 383 If a link fragment is received that overlaps another fragment 384 identified by the same source address and datagram_label, the 385 fragment(s) already accumulated in the reassembly buffer SHALL be 386 discarded. A fresh reassembly may be commenced with the most 387 recently received link fragment. Fragment overlap is determined by 388 the combination of fragment_offset from the encapsulation header and 389 data_length from the 802.15.4 packet header. 391 Upon detection of a IEEE 802.15.4 Disassociation event, the 392 recipient(s) SHOULD discard all link fragments of all partially 393 reassembled IP datagrams, and the sender(s) SHOULD discard all not 394 yet transmitted link fragments of all partially transmitted IP 395 datagrams. 397 5. Stateless Address Autoconfiguration 399 The Interface Identifier [RFC3513] for an IEEE 802.15.4 interface is 400 based on the EUI-64 identifier [EUI64] assigned to the IEEE 802.15.4 401 device. The Interface Identifier is formed from the EUI-64 according 402 to the "IPv6 over Ethernet" specification [RFC2464]. 404 A different MAC address set manually or by software MAY be used to 405 derive the Interface Identifier. If such a MAC address is used, its 406 global uniqueness property should be reflected in the value of the 407 U/L bit. 409 An IPv6 address prefix used for stateless autoconfiguration 410 [I-D.ietf-ipv6-rfc2462bis] of an IEEE 802.15.4 interface MUST have a 411 length of 64 bits. 413 6. IPv6 Link Local Address 415 The IPv6 link-local address [RFC3513] for an IEEE 802.15.4 interface 416 is formed by appending the Interface Identifier, as defined above, to 417 the prefix FE80::/64. 419 10 bits 54 bits 64 bits 420 +----------+-----------------------+----------------------------+ 421 |1111111010| (zeros) | Interface Identifier | 422 +----------+-----------------------+----------------------------+ 424 Figure 5 426 7. Unicast Address Mapping 428 The procedure for mapping IPv6 unicast addresses into IEEE 802.15.4 429 link-layer addresses is described in [I-D.ietf-ipv6-2461bis]. 431 The Source/Target Link-layer Address option has the following form 432 when the link layer is IEEE 802.15.4. 434 0 1 435 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type | Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 +- IEEE 802.15.4 -+ 441 | | 442 +- -+ 443 | | 444 +- Address -+ 445 | | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | | 448 +- Padding -+ 449 | | 450 +- (all zeros) -+ 451 | | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 6 456 Option fields: 458 Type: 459 1: for Source Link-layer address. 460 2: for Target Link-layer address. 462 Length: 2. This is the length of this option (including the type and 463 length fields) in units of 8 octets. 465 IEEE 802.15.4 Address: The 64 bit IEEE 802.15.4 address, in canonical 466 bit order. This is the address the interface currently responds 467 to. This address may be different from the built-in address used 468 to derive the Interface Identifier, because of privacy or security 469 (e.g., of neighbor discovery) considerations. 471 8. Header Compression 473 There is much published and in-progress standardization work on 474 header compression. Nevertheless, header compression for IPv6 over 475 IEEE 802.15.4 has differing constraints summarized as follows: 477 Existing work assumes that there are many flows between any two 478 devices. Here, we assume that most of the time there will be only 479 one flow, and this allows a very simple and low context flavor of 480 header compression. 482 Given the very limited packet sizes, it is highly desirable to 483 integrate layer 2 with layer 3 compression, something typically 484 not done. 486 It is expected that IEEE 802.15.4 devices will be deployed in 487 multi-hop networks. However, header compression in a mesh departs 488 from the usual point-to-point link scenario in which the 489 compressor and decompressor are in direct and exclusive 490 communication with each other. In an IEEE 802.15.4 network, it is 491 highly desirable for a device to be able to send header compressed 492 packets via any of its neighbors, with as little preliminary 493 context-building as possible. 495 Preliminary context is often required. If so, it is highly 496 desirable to allow building it by not relying exclusively on the 497 in-line negotiation phase. For example, if we assume there is 498 some manual configuration phase that precedes deployment (perhaps 499 with human involvement), then one should be able to leverage this 500 phase to set up context such that the first packet sent will 501 already be compressed. 503 Any new packets formats required by header compression reuse the 504 basic packet formats defined in Section 4 by using different values 505 for the prot_type (defined below). 507 8.1 Encoding of IPv6 Header Fields 509 However, it is possible to use header compression even in advance of 510 setting up the customary state. Thus, the following common IPv6 511 header values may be compressed from the onset: Version is IPv6, both 512 IPv6 source and destination are link local, the IPv6 bottom 64 bits 513 can be inferred from the layer two source and destination, the packet 514 length can be inferred from the layer two, both the Traffic Class and 515 the Flow Label are zero, and the Next Header is UDP, ICMP or TCP. 516 Thus, the IPv6 header info that always needs to be carried is the Hop 517 Limit (8 bits). Depending on how closely the packet matches this 518 common case, different fields may not be compressible thus needing to 519 be carried "in-line" as well (Section 8.3.1). Thus this common IPv6 520 header can be compressed to 2 octets (1 octet for the HC1 encoding 521 and 1 octet for the Hop Limit), instead of 40 octets. Such a packet 522 is compressible via the LOWPAN_HC1 format (assigned a prot_type value 523 of 2 hexadecimal). It uses the "HC1 encoding" field (8 bits) to 524 encode the different combinations as shown below. 526 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | HC1 encoding | Non-Compressed fields follow... | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Figure 7: LOWPAN_HC1 (common compressed header encoding) 534 As can be seen below (bit 7), an HC2 encoding may follow an HC1 535 octet. In this case, the non-compressed fields follow the HC2 536 encoding field Section 8.3. 538 The address fields encoded by "HC1 encoding" are interpreted as 539 follows: 541 PI: Prefix carried in-line (Section 8.3.1). 542 PC: Prefix compressed (link-local prefix assumed). 543 II: Interface identifier carried in-line (Section 8.3.1). 544 IC: Interface identifier elided (to be derived from the 545 corresponding link-layer address). If applied to the 546 destination interface identifier when routing in a mesh 547 (Section 9), the corresponding link-layer address is that found 548 in the "Final Destination" field (Figure 9). 550 The "HC1 encoding" is shown below (starting with bit 0 and ending at 551 bit 7): 553 IPv6 source address (bits 0 and 1): 554 00: PI, II 555 01: PI, IC 556 10: PC, II 557 11: PC, IC 559 IPv6 destination address (bits 2 and 3): 560 00: PI, II 561 01: PI, IC 562 10: PC, II 563 11: PC, IC 565 Traffic Class and Flow Label (bit 4): 566 0: not compressed, full 8 bits for Traffic Class and 20 bits 567 for Flow Label are sent 568 1: Traffic Class and Flow Label are zero 570 Next Header (bits 5 and 6): 572 00: not compressed, full 8 bits are sent 573 01: UDP 574 10: ICMP 575 11: TCP 577 HC2 encoding(bit 7): 578 0: No more header compression bits 579 1: HC1 encoding immediately followed by more header compression 580 bits per HC2 encoding format 582 8.2 Encoding of UDP Header Fields 584 Bits 5 and 6 of the LOWPAN_HC1 allows compressing the Next Header 585 field in the IPv6 header (for UDP, TCP and ICMP). Further 586 compression of each of these protocol headers is also possible. This 587 section explains how the UDP itself header may be compressed. The 588 LOWPAN_HC2 encoding (Figure 8) allows compressing the following 589 fields in the UDP header: source port, destination port and length. 590 The UDP header's checksum field is not compressed and is therefore 591 carried in full. The scheme defined below allows compressing the UDP 592 header to 4 octets instead of the original 8 octets. 594 The only UDP header field whose value may be deduced from information 595 available elsewhere is the Length. The other fields must be carried 596 in-line either in full or in a partially compressed manner (Section 597 8.3.2). 599 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | HC2 encoding | Fields carried in-line follow... | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 Figure 8: LOWPAN_HC2 (UDP common compressed header encoding) 607 The "HC2 encoding" for UDP is shown below (starting with bit 0 and 608 ending at bit 7): 610 UDP source port (bit 0): 611 0: Not compressed, carried "in-line" (Section 8.3.2) 612 1: Compressed to 4 bits. The actual 16-bit source port is 613 obtained by calculating: P + short_port value. P is a 614 predetermined port number with value TBD. The short_port is 615 expressed as a 4-bit value which is carried "in-line" 616 (Section 8.3.2) 618 UDP destination port (bit 1): 619 0: Not compressed, carried "in-line" (Section 8.3.2) 620 1: Compressed to 4 bits. The actual 16-bit destination port is 621 obtained by calculating: P + short_port value. P is a 622 predetermined port number with value TBD. The short_port is 623 expressed as a 4-bit value which is carried "in-line" 624 (Section 8.3.2) 626 Length (bit 2): 627 0: not compressed, carried "in-line" (Section 8.3.2) 628 1: compressed, length computed from IPv6 header length 629 information (similar to how the length of the header is 630 calculated in TCP 632 Reserved (bit 3 through 7) 634 Note: TCP, ICMP HC2 formats TBD. 636 8.3 Non-Compressed 638 8.3.1 Non-Compressed IPv6 Fields 640 This scheme allows the IPv6 header to be compressed to different 641 degrees. Hence, instead of the entire (standard) IPv6 header, only 642 non-compressed fields need to be sent. The subsequent header (as 643 specified by the Next Header field in the original IPv6 header) 644 immediately follows the IPv6 non-compressed fields. 646 The non-compressed IPv6 field that MUST be always present is the Hop 647 Limit (8 bits). This field MUST always follow the encoding fields 648 (e.g., "HC1 encoding" as shown in Figure 7), perhaps including other 649 future encoding fields). Other non-compressed fields must follow the 650 Hop Limit as implied by the "HC1 encoding" in the exact same order as 651 shown above (Section 8.1): source address prefix (64 bits) and/or 652 interface identifier (64 bits), destination address prefix (64 bits) 653 and/or interface identifier (64 bits), Traffic Class (8 bits), Flow 654 Label (20 bits) and Next Header (8 bits). The actual next header 655 (e.g., UDP, TCP, ICMP, etc) follows the non-compressed fields. 657 8.3.2 Non-Compressed and partially compressed UDP fields 659 This scheme allows the UDP header to be compressed to different 660 degrees. Hence, instead of the entire (standard) UDP header, only 661 non-compressed or partially compressed fields need to be sent. 663 The non-compressed or partially compressed fields in the UDP header 664 MUST always follow the IPv6 header and any of its associated in-line 665 fields. The order of any UDP header in-line fields present MUST be 666 the same as the corresponding fields appear in a normal UDP header 667 [RFC0768], e.g., source port, destination port, length and checksum. 669 9. Packet Delivery in a Link-Layer Mesh 671 IEEE 802.15.4-2003 [ieee802.15.4] does not define a mesh routing 672 capability. Nevertheless, it is expected that most 802.15.4 networks 673 will use mesh routing. In such cases, an ad hoc or mesh routing 674 procotol populates the devices' routing tables. A device that wishes 675 to send a packet may, in such cases, use other intermediate devices 676 as forwarders towards the final destination. In order to achieve 677 such packet delivery using unicast, it is necessary to include the 678 final destination in addition to the hop-by-hop destination. This 679 final destination may be expressed either as a layer 2 or as an IP 680 (layer 3) address. 682 In the latter case, there is no need to provide any additional header 683 support in this document (i.e., at the sub-IP layer). The link-layer 684 destination address points to the next hop destination address while 685 the IP destination address points to the final destination (IP) 686 address (that may be multiple hops away from the source). Thus, 687 while forwarding data, the single-hop destination address changes 688 hop-by-hop pointing to the "best" next hop, while the destination IP 689 address remains unchanged. 691 If creating a mesh at the link-layer (layer 2), there is a need to 692 include the link-layer final destination address within the packet. 693 The advantage of expressing the final destination as a layer 2 694 addresses is that the IPv6 destination address can be compressed as 695 per the header compression specified in Section 8, thus saving 8 696 octets. Another advantage is that the the number of octets needed to 697 maintain routing tables is reduced. A disadvantage is that 698 applications do not address packets to link-layer destination 699 addresses, but to IP (layer 3) addresses. Thus, given an IP address, 700 there is a need to resolve the corresponding link-layer address. A 701 mesh routing specification needs to clarify the Neighbor Discovery 702 implications, although in some special cases, it may be possible to 703 derive one address from the other. Such complete specification is 704 outside the scope of this document. 706 This document merely defines how to effect packet delivery in a mesh, 707 given a target link-layer address. 709 This is the purpose of the 'M' bit that immediately follows the 710 'prot_type' field. If the 'M' bit is set, there is a "Final 711 Destination" field included in the packet immediately following the 712 current header (e.g., possibly preceding any existing header 713 compression fields). This implies that the "Final Destination" field 714 will immediately follow an unfragmented packet as per Figure 1 (i.e., 715 preceding the IPv6 Header), or immediately following the first 716 fragment header as per Figure 2. 718 If a node wishes to use a forwarder to deliver a packet, it puts the 719 forwarder's link-layer address in the link-layer destination address 720 field. It must also set the 'M' bit, and include a "Final 721 Destination" field with the final destination's link-layer address. 722 Similarly, if a node receives a frame with the 'M' bit set, it must 723 look at the "Final Destination" field to determine the real 724 destination. Upon consulting its routing table, it determines what 725 the next hop towards that destination should be. The node then 726 reduces the "Hops Left" field. If the result is zero, the node 727 discards the packet. Otherwise, it puts the next hop's address in 728 the link-layer destination address field, and transmits the packet. 729 If upon examining the "Final Destination" field the node determines 730 that it has direct reachability, it removes the "Final Destination" 731 field, sets that final address as the link-layer destination address, 732 and transmits the packet. 734 The "Final Destination" field is defined as follows: 736 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 |S| Hops Left | Address of final destination | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 Figure 9: Final Destination Field 744 Field definitions are as follows: 746 S: This bit field SHALL be zero. Future revisions will use this bit 747 to signal the use of a short 16 bit address instead of the default 748 IEEE extended 64 bit address format. 750 Hops Left: This 7 bit field SHALL be decremented by each forwarding 751 node before sending this packet towards its next hop. The packet 752 is discarded if Hops Left is decremented to 0. 754 Address: This is the final destination's link-layer address. This 755 document assumes that this field is 64 bits long, but a future 756 revision may add support for short addresses (16 bits). 758 10. IANA Considerations 760 This document creates a new IANA registry for the prot_type (Protocol 761 Type) field shown in the packet formats in Section 4. This document 762 defines the values 1 and 2 hexadecimal for IPv6 and the LOWPAN_HC1 763 header compression format, respectively. Future assignments in this 764 field are to be coordinated via IANA under the policy of 765 "Specification Required" [RFC2434]. It is expected that this policy 766 will allow for other (non-IETF) organizations to more easily obtain 767 assignments. This document defines this field to be 5 bits long. 768 The value 0 being reserved and not used, this allows for a total of 769 31 different values. If there is a need for more assignments, future 770 specifications may lengthen this field, e.g., by overloading the 771 packet format in Figure 2 (Section 4). 773 11. Security Considerations 775 The method of derivation of Interface Identifiers from MAC addresses 776 is intended to preserve global uniqueness when possible. However, 777 there is no protection from duplication through accident or forgery. 779 Neighbor Discovery in IEEE 802.15.4 links may be susceptible to 780 threats as detailed in [RFC3756]. Mesh routing is expected to be 781 common in IEEE 802.15.4 networks. This implies additional threats 782 due to ad hoc routing as per [KW03]. IEEE 802.15.4 provides some 783 capability for link-layer security. Users are urged to make use of 784 such provisions if at all possible and practical. Doing so will 785 alleviate the threats referred to above. 787 A sizeable portion of IEEE 802.15.4 devices is expected to always 788 communicate within their PAN (i.e., within their link, in IPv6 789 terms). In response to cost and power consumption considerations, 790 and in keeping with the IEEE 802.15.4 model of "Reduced Function 791 Devices" (RFDs), these devices will typically implement the minimum 792 set of features necessary. Accordingly, security for such devices 793 may rely quite strongly on the mechanisms defined at the link-layer 794 by IEEE 802.15.4. The latter, however, only defines the AES modes 795 for authentication or encryption of IEEE 802.15.4 frames, and does 796 not, in particular, specify key management (presumably group 797 oriented). Other issues to address in real deployments relate to 798 secure configuration and management. Whereas such a complete picture 799 is out of scope of this document, it is imperative that IEEE 802.15.4 800 networks be deployed with such considerations in mind. Of course, it 801 is also expected that some IEEE 802.15.4 devices (the so-called "Full 802 Function Devices", or "FFDs") will implement coordination or 803 integration functions. These may communicate regularly with off-link 804 IPv6 peers (in addition to the more common on-link exchanges). Such 805 IPv6 devices are expected to secure their end-to-end communications 806 with the usual mechanisms (e.g., IPsec, TLS, etc). 808 12. Acknowledgements 810 Thanks to the authors of RFC 2464 and RFC 2734, as parts of this 811 document are patterned after theirs. Thanks to Geoff Mulligan for 812 useful discussions which helped shape this document. Erik Nordmark's 813 suggestions were instrumental for the header compression section. 814 Also thanks to Shoichi Sakane. 816 13. References 818 13.1 Normative References 820 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 821 REGISTRATION AUTHORITY", IEEE 822 http://standards.ieee.org/regauth/oui/tutorials/EUI64.html 823 . 825 [I-D.ietf-ipv6-2461bis] 826 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 827 draft-ietf-ipv6-2461bis-01 (work in progress), October 828 2004. 830 [I-D.ietf-ipv6-rfc2462bis] 831 Thomson, S., "IPv6 Stateless Address Autoconfiguration", 832 draft-ietf-ipv6-rfc2462bis-07 (work in progress), December 833 2004. 835 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 836 Requirement Levels", BCP 14, RFC 2119, March 1997. 838 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 839 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 840 October 1998. 842 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 843 (IPv6) Specification", RFC 2460, December 1998. 845 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 846 Networks", RFC 2464, December 1998. 848 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 849 (IPv6) Addressing Architecture", RFC 3513, April 2003. 851 [ieee802.15.4] 852 IEEE Computer Society, "IEEE Std. 802.15.4-2003", October 853 2003. 855 13.2 Informative References 857 [I-D.ietf-ipngwg-icmp-v3] 858 Conta, A., "Internet Control Message Protocol (ICMPv6)for 859 the Internet Protocol Version 6 (IPv6) Specification", 860 draft-ietf-ipngwg-icmp-v3-06 (work in progress), November 861 2004. 863 [I-D.ietf-ipv6-node-requirements] 864 Loughney, J., "IPv6 Node Requirements", 865 draft-ietf-ipv6-node-requirements-11 (work in progress), 866 August 2004. 868 [KW03] Karlof, Chris and Wagner, David, "Secure Routing in Sensor 869 Networks: Attacks and Countermeasures", Elsevier's AdHoc 870 Networks Journal, Special Issue on Sensor Network 871 Applications and Protocols vol 1, issues 2-3, September 872 2003. 874 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 875 August 1980. 877 [RFC1042] Postel, J. and J. Reynolds, "Standard for the transmission 878 of IP datagrams over IEEE 802 networks", STD 43, RFC 1042, 879 February 1988. 881 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 882 Guidelines and Philosophy", RFC 3439, December 2002. 884 [RFC3756] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 885 Discovery (ND) Trust Models and Threats", RFC 3756, May 886 2004. 888 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 889 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. 890 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 891 RFC 3819, July 2004. 893 Authors' Addresses 895 Gabriel Montenegro 896 Sun Microsystems, Inc. 898 EMail: gab@sun.com 899 Nandakishore Kushalnagar 900 Intel Corp 902 EMail: nandakishore.kushalnagar@intel.com 904 Intellectual Property Statement 906 The IETF takes no position regarding the validity or scope of any 907 Intellectual Property Rights or other rights that might be claimed to 908 pertain to the implementation or use of the technology described in 909 this document or the extent to which any license under such rights 910 might or might not be available; nor does it represent that it has 911 made any independent effort to identify any such rights. Information 912 on the procedures with respect to rights in RFC documents can be 913 found in BCP 78 and BCP 79. 915 Copies of IPR disclosures made to the IETF Secretariat and any 916 assurances of licenses to be made available, or the result of an 917 attempt made to obtain a general license or permission for the use of 918 such proprietary rights by implementers or users of this 919 specification can be obtained from the IETF on-line IPR repository at 920 http://www.ietf.org/ipr. 922 The IETF invites any interested party to bring to its attention any 923 copyrights, patents or patent applications, or other proprietary 924 rights that may cover technology that may be required to implement 925 this standard. Please address the information to the IETF at 926 ietf-ipr@ietf.org. 928 Disclaimer of Validity 930 This document and the information contained herein are provided on an 931 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 932 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 933 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 934 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 935 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 936 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 938 Copyright Statement 940 Copyright (C) The Internet Society (2005). This document is subject 941 to the rights, licenses and restrictions contained in BCP 78, and 942 except as set forth therein, the authors retain all their rights. 944 Acknowledgment 946 Funding for the RFC Editor function is currently provided by the 947 Internet Society.