idnits 2.17.1 draft-ietf-6lo-lowpanz-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 68 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 4, 2014) is 3705 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KW03' is mentioned on line 519, but not defined == Unused Reference: 'RFC2464' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 583, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.9959' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3587 ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 over Networks of Resource-constrained Nodes (6lo) WG A. Brandt 3 Internet-Draft J. Buron 4 Intended status: Standards Track Sigma Designs 5 Expires: September 5, 2014 March 4, 2014 7 Transmission of IPv6 packets over ITU-T G.9959 Networks 8 draft-ietf-6lo-lowpanz-03 10 Abstract 12 This document describes the frame format for transmission of IPv6 13 packets and a method of forming IPv6 link-local addresses and 14 statelessly autoconfigured IPv6 addresses on ITU-T G.9959 networks. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 5, 2014. 39 Copyright Notice 41 Copyright (c) 2014 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. G.9959 parameters to use for IPv6 transport . . . . . . . . . 4 59 2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 4 61 2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 5 62 2.4. Transmission status indications . . . . . . . . . . . . . 5 63 2.5. Transmission security . . . . . . . . . . . . . . . . . . 5 64 3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 6 65 3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 6 66 4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 7 67 4.1. Stateless Address Autoconfiguration of routable IPv6 68 addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 70 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8 71 4.4. On the use of Neighbor Discovery technologies . . . . . . 9 72 4.4.1. Prefix and CID management (Route-over) . . . . . . . 9 73 4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 10 74 5. Header Compression . . . . . . . . . . . . . . . . . . . . . 11 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 80 9.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 14 82 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 17 83 B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 17 84 B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 18 85 B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 18 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 88 1. Introduction 90 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal 91 Area Networks (PANs). This document defines the frame format for 92 transmission of IPv6 [RFC2460] packets as well as the formation of 93 IPv6 link-local addresses and statelessly autoconfigured IPv6 94 addresses on G.9959 networks. 96 The general approach is to adapt elements of [RFC4944] to G.9959 97 networks. G.9959 provides a Segmentation and Reassembly (SAR) layer 98 for transmission of datagrams larger than the G.9959 MAC PDU. 100 [RFC6775] updates [RFC4944] by specifying 6LoWPAN optimizations for 101 IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This 102 document limits the use of [RFC6775] to prefix and Context ID 103 assignment. An IID may be constructed from a G.9959 link-layer 104 address, leading to a "link-layer-derived IPv6 address". If using 105 that method, Duplicate Address Detection (DAD) is not needed. 106 Alternatively, IPv6 addresses may be assigned centrally via DHCP, 107 leading to a "non-link-layer-derived IPv6 address". Address 108 registration is only needed in certain cases. 110 In addition to IPv6 application communication, the frame format 111 defined in this document may be used by IPv6 routing protocols such 112 as RPL [RFC6550] or P2P-RPL [RFC6997] to implement IPv6 routing over 113 G.9959 networks. 115 The encapsulation frame defined by this specification may optionally 116 be transported via mesh routing below the 6LoWPAN layer. Routing 117 protocol specifications are out of scope of this document. 119 1.1. Terms used 121 6LoWPAN: IPv6-based Low-power Personal Area Network 123 ABR: Authoritative Border Router ([RFC6775]) 125 AES: Advanced Encryption Scheme 127 EUI-64: Extended Unique Identifier 129 HomeID: G.9959 Link-Layer Network Identifier 131 IID: Interface IDentifier 133 MAC: Media Access Control 135 MTU: Maximum Transmission Unit 137 NodeID: G.9959 Link-Layer Node Identifier (Short Address) 139 PAN: Personal Area Network 141 PDU: Protocol Data Unit 143 SAR: Segmentation And Reassembly 144 ULA: Unique Local Address 146 2. G.9959 parameters to use for IPv6 transport 148 This chapter outlines properties applying to the PHY and MAC of 149 G.9959 and how to use these for IPv6 transport. 151 2.1. Addressing mode 153 G.9959 defines how a unique 32-bit HomeID network identifier is 154 assigned by a network controller and how an 8-bit NodeID host 155 identifier is allocated. NodeIDs are unique within the logical 156 network identified by the HomeID. The logical network identified by 157 the HomeID maps directly to an IPv6 subnet identified by one or more 158 IPv6 prefixes. 160 An IPv6 host MUST construct its link-local IPv6 address from the 161 link-layer-derived IID in order to facilitate IP header compression 162 as described in [RFC6282]. 164 A node interface MAY support the M flag of the RA message for the 165 construction of routable IPv6 addresses. If the M flag is not 166 supported, link-layer-derived addressing MUST be used. If the M flag 167 is supported, link-layer-derived addressing MUST be used if the M 168 flag is 0, while DHCPv6 address assignment MUST be used if the M flag 169 is 1. Nodes using DHCPv6 assigned IPv6 addresses MUST comply with 170 [RFC6775]. 172 A word of caution: since HomeIDs and NodeIDs are handed out by a 173 network controller function during inclusion, identifier validity and 174 uniqueness is limited by the lifetime of the logical network 175 membership. This can be cut short by a mishap occurring to the 176 network controller. Having a single point of failure at the network 177 controller suggests that deployers of high-reliability applications 178 should carefully consider adding redundancy to the network controller 179 function. 181 This warning applies to link-layer-derived addressing as well as to 182 non-link-layer addressing deployments. 184 2.2. IPv6 Multicast support 186 [RFC3819] recommends that IP subnetworks support (subnet-wide) 187 multicast. G.9959 supports direct-range IPv6 multicast while subnet- 188 wide multicast is not supported natively by G.9959. Subnet-wide 189 multicast may be provided by an IP routing protocol or a mesh routing 190 protocol operating below the 6LoWPAN layer. Routing protocol 191 specifications are out of scope of this document. 193 IPv6 multicast packets MUST be carried via G.9959 broadcast. 195 As per [G.9959], this is accomplished as follows: 197 1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID 198 of the logical network 200 2. The destination NodeID of the G.9959 MAC PDU MUST be the 201 broadcast NodeID (0xff) 203 G.9959 broadcast MAC PDUs are only intercepted by nodes within the 204 logical network identified by the HomeID. 206 2.3. G.9959 MAC PDU size and IPv6 MTU 208 IPv6 packets MUST use G.9959 transmission profiles which support MAC 209 PDU payload sizes of 150 bytes or higher, i.e. profile R3 or higher. 210 (G.9959 profiles R1 and R2 only support MPDU payloads around 40 bytes 211 and the transmission speed is down to 9.6kbit/s) 213 [RFC2460] specifies that IPv6 packets may be up to 1280 octets. 215 G.9959 provides Segmentation And Reassembly for payloads up to 1350 216 octets. IPv6 Header Compression [RFC6282] improves the chances that 217 a short IPv6 packet can fit into a single G.9959 frame. Therefore, 218 section Section 3 specifies that [RFC6282] MUST be supported. With 219 the mandatory link-layer security enabled, a G.9959 R3 MAC PDU may 220 accommodate 6LoWPAN datagrams of up to 130 octets without triggering 221 G.9959 Segmentation and Reassembly. Longer 6LoWPAN datagrams will 222 lead to the transmission of multiple G.9959 PDUs. 224 2.4. Transmission status indications 226 The G.9959 MAC layer provides native acknowledgement and 227 retransmission of MAC PDUs. The G.9959 SAR layer does the same for 228 larger datagrams. A mesh routing layer may provide a similar feature 229 for routed communication. An IPv6 routing stack communicating over 230 G.9959 may utilize link-layer status indications such as delivery 231 confirmation and Ack timeout from the MAC layer. 233 2.5. Transmission security 235 Implementations claiming conformance with this document MUST enable 236 G.9959 shared network key security. 238 The shared network key is intended to address security requirements 239 in the home at the normal security requirements level. For 240 applications with high or very high requirements on confidentiality 241 and/or integrity, additional application layer security measures for 242 end-to-end authentication and encryption may need to be applied. 243 (The availability of the network relies on the security properties of 244 the network key in any case) 246 3. 6LoWPAN Adaptation Layer and Frame Format 248 The 6LoWPAN encapsulation formats defined in this chapter are carried 249 as payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282] 250 MUST be supported by implementations of this specification. 252 All 6LoWPAN datagrams transported over G.9959 are prefixed by a 253 6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this 254 encapsulation header stack. Each header in the header stack contains 255 a header type followed by zero or more header fields. An IPv6 header 256 stack may contain, in the following order, addressing, hop-by-hop 257 options, routing, fragmentation, destination options, and finally 258 payload [RFC2460]. The 6LoWPAN header format is structured the same 259 way. Currently only one payload option is defined for the G.9959 260 6LoWPAN header format. 262 The definition of 6LoWPAN headers consists of the dispatch value, the 263 definition of the header fields that follow, and their ordering 264 constraints relative to all other headers. Although the header stack 265 structure provides a mechanism to address future demands on the 266 6LoWPAN adaptation layer, it is not intended to provide general 267 purpose extensibility. 269 An example of a complete G.9959 6LoWPAN datagram can be found in 270 Appendix A. 272 3.1. Dispatch Header 274 The dispatch header is shown below: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | 6LoWPAN CmdCls | Dispatch | Type-specific header | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 Figure 1: Dispatch Type and Header 284 6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST 285 carry the value 0x4F [G.9959]. The value specifies that the 286 following bits are a 6LoWPAN encapsulated datagram. Non-6LoWPAN 287 protocols MUST ignore the contents following the 6LoWPAN Command 288 Class identifier. 290 Dispatch: Identifies the header type immediately following the 291 Dispatch Header. 293 Type-specific header: A header determined by the Dispatch Header. 295 The dispatch value may be treated as an unstructured namespace. Only 296 a few symbols are required to represent current 6LoWPAN 297 functionality. Although some additional savings could be achieved by 298 encoding additional functionality into the dispatch byte, these 299 measures would tend to constrain the ability to address future 300 alternatives. 302 Dispatch values used in this specification are compatible with the 303 dispatch values defined by [RFC4944] and [RFC6282]. 305 +------------+------------------------------------------+-----------+ 306 | Pattern | Header Type | Reference | 307 +------------+------------------------------------------+-----------+ 308 | 01 1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses | [RFC6282] | 309 +------------+------------------------------------------+-----------+ 310 All other Dispatch values are unassigned in this document. 312 Figure 2: Dispatch values 314 6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282]. 316 4. 6LoWPAN addressing 318 IPv6 addresses are autoconfigured from IIDs which are again 319 constructed from link-layer address information to save memory in 320 devices and to facilitate efficient IP header compression as per 321 [RFC6282]. 323 A NodeID is mapped into an IEEE EUI-64 identifier as follows: 325 IID = 0000:00ff:fe00:YYXX 327 Figure 3: Constructing a compressible IID 329 where XX carries the G.9959 NodeID and YY is a one byte value chosen 330 by the individual node. The default YY value MUST be zero. A node 331 MAY use other values of YY than zero to form additional IIDs in order 332 to instantiate multiple IPv6 interfaces. The YY value MUST be 333 ignored when computing the corresponding NodeID (the XX value) from 334 an IID. 336 The method of constructing IIDs from the link-layer address obviously 337 does not support addresses assigned or constructed by other means. A 338 node MUST NOT compute the NodeID from the IID if the first 6 bytes of 339 the IID do not comply with the format defined in Figure 3. In that 340 case, the address resolution mechanisms of RFC 6775 apply. 342 4.1. Stateless Address Autoconfiguration of routable IPv6 addresses 344 The IID defined above MUST be used whether autoconfiguring a ULA IPv6 345 address [RFC4193] or a globally routable IPv6 address [RFC3587] in 346 G.9959 subnets. 348 4.2. IPv6 Link Local Address 350 The IPv6 link-local address [RFC4291] for a G.9959 interface is 351 formed by appending the IID defined above to the IPv6 link local 352 prefix FE80::/64. 354 The "Universal/Local" (U/L) bit MUST be set to zero in keeping with 355 the fact that this is not a globally unique value [EUI64]. 357 The resulting link local address is formed as follows: 359 10 bits 54 bits 64 bits 360 +----------+-----------------------+----------------------------+ 361 |1111111010| (zeros) | Interface Identifier (IID) | 362 +----------+-----------------------+----------------------------+ 364 Figure 4: IPv6 Link Local Address 366 4.3. Unicast Address Mapping 368 The address resolution procedure for mapping IPv6 unicast addresses 369 into G.9959 link-layer addresses follows the general description in 370 Section 7.2 of [RFC4861]. The Source/Target Link-layer Address 371 option MUST have the following form when the link layer is G.9959. 373 0 1 374 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Type | Length=1 | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | 0x00 | NodeID | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Padding | 381 +- -+ 382 | (All zeros) | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 5: IPv6 Unicast Address Mapping 387 Option fields: 389 Type: The value 1 signifies the Source Link-layer address. The value 390 2 signifies the Destination Link-layer address. 392 Length: This is the length of this option (including the type and 393 length fields) in units of 8 octets. The value of this field is 394 always 1 for G.9959 NodeIDs. 396 NodeID: This is the G.9959 NodeID the actual interface currently 397 responds to. The link-layer address may change if the interface 398 joins another network at a later time. 400 4.4. On the use of Neighbor Discovery technologies 402 [RFC4861] specifies how IPv6 nodes may resolve link layer addresses 403 from IPv6 addresses via the use of link-local IPv6 multicast. 404 [RFC6775] is an optimization of [RFC4861], specifically targeting 405 6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register 406 IPv6 addresses with an authoritative border router (ABR). Mesh-under 407 networks MUST NOT use [RFC6775] address registration. However, 408 [RFC6775] address registration MUST be used if the first 6 bytes of 409 the IID do not comply with the format defined in Figure 3. 411 4.4.1. Prefix and CID management (Route-over) 413 In route-over environments, IPv6 hosts MUST use [RFC6775] address 414 registration. A node implementation for route-over operation MAY use 415 RFC6775 mechanisms for obtaining IPv6 prefixes and corresponding 416 header compression context information [RFC6282]. RFC6775 Route-over 417 requirements apply with no modifications. 419 4.4.2. Prefix and CID management (Mesh-under) 421 An implementation for mesh-under operation MUST use [RFC6775] 422 mechanisms for managing IPv6 prefixes and corresponding header 423 compression context information [RFC6282]. [RFC6775] Duplicate 424 Address Detection (DAD) MUST NOT be used, since the link-layer 425 inclusion process of G.9959 ensures that a NodeID is unique for a 426 given HomeID. 428 With this exception and the specific redefinition of the RA Router 429 Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the 430 following subsections is in compliance with [RFC6775]. 432 4.4.2.1. Prefix assignment considerations 434 As stated by [RFC6775], an ABR is responsible for managing 435 prefix(es). Global routable prefixes may change over time. It is 436 RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to 437 facilitate stable site-local application associations based on IPv6 438 addresses. A node MAY support the M flag of the RA message. If the 439 M flag is not supported, link-layer-derived addressing MUST be used. 440 If the M flag is supported, link-layer-derived addressing MUST be 441 used if the M flag is 0, while DHCPv6 address assignment MUST be used 442 if the M flag is 1. 444 4.4.2.2. Robust and efficient CID management 446 The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an 447 RA to disseminate Context IDs (CID) to use for compressing prefixes. 448 One or more prefixes and corresponding Context IDs MUST be assigned 449 during initial node inclusion. 451 When updating context information, a CID may have its lifetime set to 452 zero to obsolete it. The CID MUST NOT be reused immediately; rather 453 the next vacant CID should be assigned. Header compression based on 454 CIDs MUST NOT be used for RA messages carrying Context Information. 455 An expired CID and the associated prefix MUST NOT be reset but rather 456 retained in receive-only mode if there is no other current need for 457 the CID value. This will allow an ABR to detect if a sleeping node 458 without clock uses an expired CID and in response, the ABR MUST 459 return an RA with fresh Context Information to the originator. 461 4.4.2.3. Infinite prefix lifetime support for island-mode networks 463 Nodes MUST renew the prefix and CID according to the lifetime 464 signaled by the ABR. [RFC6775] specifies that the maximum value of 465 the RA Router Lifetime field MAY be up to 0xFFFF. This document 466 further specifies that the value 0xFFFF MUST be interpreted as 467 infinite lifetime. This value MUST NOT be used by ABRs. Its use is 468 only intended for a sleeping network controller; for instance a 469 battery powered remote control being master for a small island-mode 470 network of light modules. 472 5. Header Compression 474 IPv6 header compression [RFC6282] MUST be implemented according to 475 [RFC6282]. This section will simply identify substitutions that 476 should be made when interpreting the text of [RFC6282]. 478 In general the following substitutions should be made: 480 o Replace "802.15.4" with "G.9959" 482 o Replace "802.15.4 short address" with "" 484 o Replace "802.15.4 PAN ID" with "G.9959 HomeID" 486 When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short 487 address") it MUST be formed by prepending an Interface label byte to 488 the G.9959 NodeID: 490 0 1 491 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Interface | NodeID | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 A transmitting node may be sending to an IPv6 destination address 497 which can be reconstructed from the link-layer destination address. 498 If the Interface number is zero (the default value), all IPv6 address 499 bytes may be elided. Likewise, the Interface number of a fully 500 elided IPv6 address (i.e. SAM/DAM=11) may be reconstructed to the 501 value zero by a receiving node. 503 64 bit 802.15.4 address details do not apply. 505 6. IANA Considerations 507 This document makes no request of IANA. 509 Note to RFC Editor: this section may be removed on publication as an 510 RFC. 512 7. Security Considerations 514 The method of derivation of Interface Identifiers from 8-bit NodeIDs 515 preserves uniqueness within the logical network. However, there is 516 no protection from duplication through forgery. Neighbor Discovery 517 in G.9959 links may be susceptible to threats as detailed in 518 [RFC3756]. G.9959 networks may feature mesh routing. This implies 519 additional threats due to ad hoc routing as per [KW03]. G.9959 520 provides capability for link-layer security. G.9959 nodes MUST use 521 link-layer security with a shared key. Doing so will alleviate the 522 majority of threats stated above. A sizeable portion of G.9959 523 devices is expected to always communicate within their PAN (i.e., 524 within their subnet, in IPv6 terms). In response to cost and power 525 consumption considerations, these devices will typically implement 526 the minimum set of features necessary. Accordingly, security for 527 such devices may rely on the mechanisms defined at the link layer by 528 G.9959. G.9959 relies on the Advanced Encryption Standard (AES) for 529 authentication and encryption of G.9959 frames and further employs 530 challenge-response handshaking to prevent replay attacks. 532 It is also expected that some G.9959 devices (e.g. billing and/or 533 safety critical products) will implement coordination or integration 534 functions. These may communicate regularly with IPv6 peers outside 535 the subnet. Such IPv6 devices are expected to secure their end-to- 536 end communications with standard security mechanisms (e.g., IPsec, 537 TLS, etc). 539 8. Acknowledgements 541 Thanks to the authors of RFC 4944 and RFC 6282 and members of the 542 IETF 6LoWPAN working group; this document borrows extensively from 543 their work. Thanks to Erez Ben-Tovim, Kerry Lynn, Michael 544 Richardson, Tommas Jess Christensen for useful comments. Thanks to 545 Carsten Bormann for extensive feedback which improved this document 546 significantly. 548 9. References 550 9.1. Normative References 552 [EUI64] IEEE, "communicationIDELINES FOR 64-BIT GLOBAL IDENTIFIER 553 (EUI-64) REGISTRATION AUTHORITY", IEEE Std http:// 554 standards.ieee.org/regauth/oui/tutorials/EUI64.html, 555 November 2012. 557 [G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range, 558 narrow-band digital radiocommunication transceivers", 559 February 2012. 561 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 562 Requirement Levels", BCP 14, RFC 2119, March 1997. 564 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 565 (IPv6) Specification", RFC 2460, December 1998. 567 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 568 Networks", RFC 2464, December 1998. 570 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 571 Unicast Address Format", RFC 3587, August 2003. 573 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 574 Addresses", RFC 4193, October 2005. 576 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 577 Architecture", RFC 4291, February 2006. 579 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 580 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 581 September 2007. 583 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 584 Extensions for Stateless Address Autoconfiguration in 585 IPv6", RFC 4941, September 2007. 587 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 588 "Transmission of IPv6 Packets over IEEE 802.15.4 589 Networks", RFC 4944, September 2007. 591 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 592 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 593 September 2011. 595 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 596 "Neighbor Discovery Optimization for IPv6 over Low-Power 597 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 598 November 2012. 600 9.2. Informative References 602 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 603 Discovery (ND) Trust Models and Threats", RFC 3756, May 604 2004. 606 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 607 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 608 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 609 RFC 3819, July 2004. 611 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 612 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 613 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 614 Lossy Networks", RFC 6550, March 2012. 616 [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 617 Martocci, "Reactive Discovery of Point-to-Point Routes in 618 Low-Power and Lossy Networks", RFC 6997, August 2013. 620 Appendix A. G.9959 6LoWPAN datagram example 622 This example outlines each individual bit of a sample IPv6 UDP packet 623 arriving to a G.9959 node from a host in the Internet 624 via a PAN border router. 626 In the G.9959 PAN, the complete frame has the following fields. 628 G.9959: 630 +------+---------+----------+---+-----+----------... 631 |HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID| 632 +------+---------+----------+---+-----+----------+-... 634 6LoWPAN: 636 ...+--------------+----------------+-----------------------... 637 |6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers| 638 ...-------------+----------------+-----------------------+-... 640 6LoWPAN, TCP/UDP, App payload: 642 ...+-------------------------+------------+-----------+ 643 |Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload| 644 ...------------------------+------------+-----------+ 646 The frame comes from the source IPv6 address 2001:0db8:ac10:ef01::ff:fe00:1206. 647 The source prefix 2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3. 648 The frame is delivered in direct range from the gateway which has source NodeID = 1. 649 The Interface Identifier (IID) ff:fe00:1206 is recognised as a link-layer-derived address 650 and is compressed to the 16 bit value 0x1206. 652 The frame is sent to the destination IPv6 address 2001:0db8:27ef:42ca::ff:fe00:0004. 653 The destination prefix 2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2. 655 The Interface Identifier (IID) ff:fe00:0004 is recognised as a link-layer-derived address. 657 Thanks to the link-layer-derived addressing rules, the sender knows that this is to be sent 658 to G.9959 NodeID = 4; targeting the IPv6 interface instance number 0 (the default). 660 To reach the 6LoWPAN stack of the G.9959 node, (skipping the G.9959 header fields) the first octet must be the 6LoWPAN Command Class (0x4F). 662 0 663 0 1 2 3 4 5 6 7 8 664 +-+-+-+-+-+-+-+-... 665 | 0x4F | 666 +-+-+-+-+-+-+-+-+-... 668 The Dispatch header bits '011' advertises a compressed IPv6 header to follow. 670 0 1 671 0 1 2 3 4 5 6 7 8 9 0 672 +-+-+-+-+-+-+-+-+-+-+-... 673 | 0x4F |0 1 1 674 +-+-+-+-+-+-+-+-+-+-+-+-... 676 The following bits encode the following: 678 TF = '11' : Traffic Class and Flow Label are elided. 679 NH = '1' : Next Header is elided 680 HLIM = '10' : Hop limit is 64 682 0 1 683 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 685 | 0x4F |0 1 1 1 1 1 0 1| 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 688 CID = '1' : CI data follows the DAM field 689 SAC = '1' : Src addr uses stateful, context-based compression 690 SAM = '10' : Combine src CID and 16 bits to link-layer-derived addr 691 M = '0' : Dest addr is not a multicast addr 692 DAC = '1' : Dest addr uses stateful, context-based compression 693 DAM = '11' : Combine dest CID and dest NodeID to link-layer-derived addr 694 0 1 2 695 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 697 | 0x4F |0 1 1 1 1 1 0 1|1 1 1 0 0 1 1 1| 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 700 Address compression context identifiers: 702 SCI = 0x3 703 DCI = 0x2 705 2 3 706 4 5 6 7 8 9 0 1 707 ...+-+-+-+-+-+-+-+-... 708 | 0x3 | 0x2 | 709 ...+-+-+-+-+-+-+-+-... 711 IPv6 header fields: 712 (skipping "version" field) 713 (skipping "Traffic Class") 714 (skipping "flow label") 715 (skipping "payload length") 717 IPv6 header address fields: 719 SrcIP = 0x1206 : 16 LS bits of link-layer-derived address to combine with SCI 720 (skipping DestIP ) - completely reconstructed from Dest NodeID and DCI 722 2 3 4 723 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 724 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 725 | 0x3 | 0x2 | 0x12 | 0x06 | 726 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 728 Hext header encoding for the UDP header: 730 Dispatch = '11110': Next Header dispatch code for UDP header 731 C = '0' : 16 bit checksupm carried inline 732 P = '00' : both src port and dest Port are carried in-line. 734 4 5 735 8 9 0 1 2 3 4 5 736 ...+-+-+-+-+-+-+-+-... 737 |1 1 1 1 0|0|0 0| 739 ...+-+-+-+-+-+-+-+-... 741 UDP header fields: 743 src Port = 0x1234 744 dest port = 0x5678 746 5 6 7 8 747 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 748 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 749 | 0x12 | 0x34 | 0x56 | 0x78 | 750 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 752 UDP header fields: 754 (skipping "length") 755 checksum = .... (actual checksum value depends on 756 the actual UDP payload) 758 1 759 8 9 0 760 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 761 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 762 | (UDP checksum) | 763 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 765 Add your own UDP payload here... 767 Appendix B. Change Log 769 B.1. Changes since -00 771 o Clarified that mesh-under routing may take place below the 6LoWPAN 772 layer but that specific mesh-under routing protocols are not 773 within the scope of this doc. 775 o Clarified that RFC6282 IPv6 Header Compression MUST be supported. 777 o Clarified the text of section 5.4 on the use of RFC6775 address 778 registration in mesh-under networks. 780 o Split 5.4.2 into multiple paragraphs. 782 B.2. Changes since -01 784 o Added this Change Log 786 o Editorial nits. 788 o Made IPv6 Header Compression mandatory. Therefore, the Dispatch 789 value "01 000001 - Uncompressed IPv6 Addresses" was removed from 790 figure 2. 792 o Changed SHOULD to MUST: An IPv6 host SHOULD construct its link- 793 local IPv6 address and routable IPv6 addresses from the NodeID in 794 order to facilitate IP header compression as described in 795 [RFC6282]. 797 o Changed SHOULD NOT to MUST NOT: Mesh-under networks MUST NOT use 798 [RFC6775] address registration. 800 o Changed SHOULD NOT to MUST NOT: [RFC6775] Duplicate Address 801 Detection (DAD) MUST NOT be used. 803 o Changed SHOULD NOT to MUST NOT: The CID MUST NOT be reused 804 immediately; 806 o Changed SHOULD NOT to MUST NOT: An expired CID and the associated 807 prefix MUST NOT be reset but rather retained in receive-only mode 809 o Changed LBR -> ABR 811 o Changed SHOULD to MUST: , the ABR MUST return an RA with fresh 812 Context Information to the originator. 814 o Changed SHOULD NOT to MUST NOT: This value MUST NOT be used by 815 ABRs. Its use is only intended for a sleeping network controller; 817 B.3. Changes since -02 819 o Editorial nits. 821 o Moved text to the right section so that it does not prohibit DAD 822 for Route-Over deployments. 824 o Introduced RA m flag support so that nodes may be instructed to 825 use DHCPv6 for centralized address assignment. 827 Authors' Addresses 829 Anders Brandt 830 Sigma Designs 831 Emdrupvej 26A, 1. 832 Copenhagen O 2100 833 Denmark 835 Email: anders_brandt@sigmadesigns.com 837 Jakob Buron 838 Sigma Designs 839 Emdrupvej 26A, 1. 840 Copenhagen O 2100 841 Denmark 843 Email: jakob_buron@sigmadesigns.com