idnits 2.17.1 draft-brandt-6man-lowpanz-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2013) is 4022 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 526, but not defined == Unused Reference: 'G.9959.llc' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'G.9959.sar' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC2464' is defined on line 581, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 597, 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.llc' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.9959.sar' -- 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) -- No information found for draft-ietf-roll-p2p-rpl-15 - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance WG A. Brandt 3 Internet-Draft J. Buron 4 Intended status: Standards Track Sigma Designs 5 Expires: October 24, 2013 April 22, 2013 7 Transmission of IPv6 packets over ITU-T G.9959 Networks 8 draft-brandt-6man-lowpanz-01 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 October 24, 2013. 39 Copyright Notice 41 Copyright (c) 2013 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. Author's notes . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Reader's guidance . . . . . . . . . . . . . . . . . . . . 2 58 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. G.9959 parameters to use for IPv6 transport . . . . . . . . . 4 61 3.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 4 62 3.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 4 63 3.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 5 64 3.4. Transmission status indications . . . . . . . . . . . . . 5 65 3.5. Transmission security . . . . . . . . . . . . . . . . . . 5 66 4. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 6 67 4.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 6 68 5. LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Stateless Address Autoconfiguration of routable IPv6 70 addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 8 72 5.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 8 73 5.4. On the use of Neighbor Discovery technologies . . . . . . 9 74 5.4.1. Prefix and CID management (Route-over) . . . . . . . 10 75 5.4.2. Prefix and CID management (Mesh-under) . . . . . . . 10 76 6. Header Compression . . . . . . . . . . . . . . . . . . . . . 10 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 8. Z-Wave Alliance Considerations . . . . . . . . . . . . . . . 11 79 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 83 11.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Author's notes 88 This chapter MUST be deleted before going for document last call. 90 1.1. Reader's guidance 92 This document borrows heavily from RFC4944, "Transmission of IPv6 93 Packets over IEEE 802.15.4 Networks". The process of creating this 94 document was mainly a simplification; removing the following topics: 96 o EUI-64 link-layer addresses 97 o Fragmentation layer 99 o Mesh routing 101 The 16-bit short addresses of 802.15.4 have been changed to 8-bit 102 G.9959 NodeIDs. 104 2. Introduction 106 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal 107 Area Networks (PANs). This document defines the frame format for 108 transmission of IPv6 [RFC2460] packets as well as the formation of 109 IPv6 link-local addresses and statelessly autoconfigured IPv6 110 addresses on G.9959 networks. 112 The general approach is to adapt elements of [RFC4944] to G.9959 113 networks. G.9959 provides a Segmentation and Reassembly (SAR) layer 114 for transmission of datagrams larger than the G.9959 MAC PDU. 116 [RFC6775] updates [RFC4944] by specifying LoWPAN optimizations for 117 IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This 118 document limits the use of [RFC6775] to prefix and Context ID 119 assignment. It is described how to construct an IID from a G.9959 120 link-layer address. Refer to Section 5. If using that method, 121 Duplicate Address Detection (DAD) is not needed. Address 122 registration is only needed in certain cases. 124 In addition to IPv6 application communication, the frame format 125 defined in this document may be used by IPv6 routing protocols such 126 as RPL [RFC6550] or P2P-RPL [P2P-RPL] to implement IPv6 routing over 127 G.9959 networks. 129 G.9959 networks may implement mesh routing between nodes below the IP 130 layer. Mesh routing is out of scope of this document. 132 2.1. Terms used 134 ABR: Authoritative Border Router ([RFC6775]) 136 AES: Advanced Encryption Scheme 138 EUI-64: Extended Unique Identifier 140 HomeID: G.9959 Link-Layer Network Identifier 142 IID: Interface IDentifier 144 MAC: Media Access Control 145 MTU: Maximum Transmission Unit 147 NodeID: G.9959 Link-Layer Node Identifier (Short Address) 149 PAN: Personal Area Network 151 PDU: Protocol Data Unit 153 SAR: Segmentation And Reassembly 155 ULA: Unique Local Address 157 3. G.9959 parameters to use for IPv6 transport 159 This chapter outlines properties applying to the PHY and MAC of 160 G.9959 and how to use these for IPv6 transport. 162 3.1. Addressing mode 164 G.9959 defines how a unique 32-bit HomeID network identifier is 165 assigned by a network controller and how an 8-bit NodeID host 166 identifier is allocated. NodeIDs are unique within the logical 167 network identified by the HomeID. The logical network identified by 168 the HomeID maps directly to an IPv6 subnet identified by one or more 169 IPv6 prefixes. 171 An IPv6 host SHOULD construct its link-local IPv6 address and 172 routable IPv6 addresses from the NodeID in order to facilitate IP 173 header compression as described in [RFC6282]. 175 A word of caution: since HomeIDs and NodeIDs are handed out by a 176 network controller function during inclusion, identifier validity and 177 uniqueness is limited by the lifetime of the logical network 178 membership. This can be cut short by a mishap occurring to the 179 network controller. Having a single point of failure at the network 180 controller suggests that deployers of high-reliability applications 181 should carefully consider adding redundancy to the network controller 182 function. 184 3.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 LoWPAN layer. Routing protocols are out 191 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 3.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, e.g. the R3 profile. 210 G.9959 profiles R1 and R2 only supports 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. 214 However, a full IPv6 packet does not fit in an G.9959 MAC PDU. The 215 maximum G.9959 R3 MAC PDU payload size is 158 octets. Link-layer 216 security imposes an overhead, which in the extreme case leaves 130 217 octets available. 219 G.9959 provides Segmentation And Reassembly for payloads up to 1350 220 octets. Segmentation however adds further overhead. It is therefore 221 desirable that datagrams can fit into a single G.9959 MAC PDU. IPv6 222 Header Compression [RFC6282] improves the chances that a short IPv6 223 packet can fit into a single G.9959 frame. 225 3.4. Transmission status indications 227 The G.9959 MAC layer provides native acknowledgement and 228 retransmission of MAC PDUs. The G.9959 SAR layer does the same for 229 larger datagrams. A mesh routing layer may provide a similar feature 230 for routed communication. Acknowledgment and retransmission improves 231 the transmission success rate and frees higher layers from the burden 232 of implementing individual retransmission schemes. An IPv6 routing 233 stack communicating over G.9959 may utilize link-layer status 234 indications such as delivery confirmation and Ack timeout from the 235 MAC layer. 237 3.5. Transmission security 239 Implementations claiming conformance with this document MUST enable 240 G.9959 common network key security. 242 The network key is intended to address security requirements in the 243 home at the normal security requirements level. For applications 244 with high or very high requirements on confidentiality and/or 245 integrity, such as door locks and meters, additional application 246 layer security measures for end-to-end authentication and encryption 247 will need to be applied. The availability of the network relies on 248 the security properties of the network key in any case. 250 4. LoWPAN Adaptation Layer and Frame Format 252 The LoWPAN encapsulation formats defined in this chapter are the 253 payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282] 254 MUST be supported by implementations of this specification. 256 All LoWPAN datagrams transported over G.9959 are prefixed by a LoWPAN 257 encapsulation header stack. The LoWPAN payload (e.g. an IPv6 258 packet) follows this encapsulation header. Each header in the header 259 stack contains a header type followed by zero or more header fields. 260 An IPv6 header stack may contain, in the following order, addressing, 261 hop-by-hop options, routing, fragmentation, destination options, and 262 finally payload [RFC2460]. The LoWPAN header format is structured 263 the same way. Currently only payload options are defined for the 264 LoWPAN header format. 266 The definition of LoWPAN headers consists of the dispatch value, the 267 definition of the header fields that follow, and their ordering 268 constraints relative to all other headers. Although the header stack 269 structure provides a mechanism to address future demands on the 270 LoWPAN adaptation layer, it is not intended to provide general 271 purpose extensibility. This document specifies a small set of 272 6LoWPAN header types using the 6LoWPAN header stack for clarity, 273 compactness, and orthogonality. 275 4.1. Dispatch Header 277 The dispatch header is shown below: 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | LoWPAN CmdCls | Dispatch | Type-specific header | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 Figure 1: Dispatch Type and Header 287 LoWPAN CmdCls: LoWPAN Command Class identifier, [G.9959]. Specifies 288 that the following bits are a LoWPAN encapsulated datagram. Non- 289 LoWPAN protocols MUST ignore the contents following the LoWPAN 290 Command Class identifier. TBD: Specific value to be assigned by 291 Z-Wave Alliance before last call of this Internet Draft. Refer to 292 Section 8. 294 Dispatch: Identifies the header type immediately following the 295 Dispatch Header. 297 Type-specific header: A header determined by the Dispatch Header. 299 The dispatch value may be treated as an unstructured namespace. Only 300 a few symbols are required to represent current LoWPAN functionality. 301 Although some additional savings could be achieved by encoding 302 additional functionality into the dispatch byte, these measures would 303 tend to constrain the ability to address future alternatives. 305 Dispatch values used in this specification are compatible with the 306 dispatch values defined by [RFC4944] and [RFC6282]. 308 +------------+------------------------------------------+-----------+ 309 | Pattern | Header Type | Reference | 310 +------------+------------------------------------------+-----------+ 311 | 01 000001 | IPv6 - Uncompressed IPv6 Addresses| [RFC4944] | 312 | 01 1xxxxx | LoWPAN_IPHC - LoWPAN_IPHC compressed IPv6| [RFC6282] | 313 +------------+------------------------------------------+-----------+ 314 All other Dispatch values are unassigned in this document. 316 Figure 2: Dispatch values 318 IPv6: Specifies that the following header is an uncompressed IPv6 319 header. 321 LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282]. 323 5. LoWPAN addressing 325 IPv6 addresses are autoconfigured from IIDs which are again 326 constructed from link-layer address information to save memory in 327 devices and to facilitate efficient IP header compression as per 328 [RFC6282]. 330 A G.9959 NodeID is 8 bits in length. A NodeID is mapped into an IEEE 331 EUI-64 identifier as follows: 333 IID = 0000:00ff:fe00:YYXX 335 Figure 3: Constructing a compressible IID 337 where XX carries the G.9959 NodeID and YY is a one byte value chosen 338 by the individual node. The default YY value MUST be zero. A node 339 MAY use other values of YY than zero to form additional IIDs in order 340 to instantiate multiple IPv6 interfaces. The YY value MUST be 341 ignored when computing the corresponding NodeID (the XX value) from 342 an IID. 344 A LoWPAN network typically is used for M2M-style communication. The 345 method of constructing IIDs from the link-layer address obviously 346 does not support addresses assigned or constructed by other means. A 347 node MUST NOT compute the NodeID from the IID if the first 6 bytes of 348 the IID do not comply with the format defined in Figure 3. In that 349 case, the address resolution mechanisms of RFC 6775 apply. 351 5.1. Stateless Address Autoconfiguration of routable IPv6 addresses 353 The IID defined above MUST be used whether autoconfiguring a ULA IPv6 354 address [RFC4193] or a globally routable IPv6 address [RFC3587] in 355 G.9959 subnets. 357 5.2. IPv6 Link Local Address 359 The IPv6 link-local address [RFC4291] for a G.9959 interface is 360 formed by appending the IID defined above to the IPv6 link local 361 prefix FE80::/64. 363 The "Universal/Local" (U/L) bit MUST be set to zero in keeping with 364 the fact that this is not a globally unique value [EUI64]. 366 The resulting link local address is formed as follows: 368 10 bits 54 bits 64 bits 369 +----------+-----------------------+----------------------------+ 370 |1111111010| (zeros) | Interface Identifier (IID) | 371 +----------+-----------------------+----------------------------+ 373 Figure 4: IPv6 Link Local Address 375 5.3. Unicast Address Mapping 377 The address resolution procedure for mapping IPv6 unicast addresses 378 into G.9959 link-layer addresses follows the general description in 379 Section 7.2 of [RFC4861]. The Source/Target Link-layer Address 380 option MUST have the following form when the link layer is G.9959. 382 0 1 383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Type | Length=1 | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | 0x00 | NodeID | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Padding | 390 +- -+ 391 | (All zeros) | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 5: IPv6 Unicast Address Mapping 396 Option fields: 398 Type: The value 1 signifies the Source Link-layer address. The value 399 2 signifies the Destination Link-layer address. 401 Length: This is the length of this option (including the type and 402 length fields) in units of 8 octets. The value of this field is 403 always 1 for G.9959 NodeIDs. 405 NodeID: This is the G.9959 NodeID the actual interface currently 406 responds to. The link-layer address may change if the interface 407 joins another network at a later time. 409 5.4. On the use of Neighbor Discovery technologies 411 [RFC4861] specifies how IPv6 nodes may resolve link layer addresses 412 from IPv6 addresses via the use of link-local IPv6 multicast. 413 [RFC6775] is an optimization of [RFC4861], specifically targeting 414 LoWPAN networks. [RFC6775] defines how a LoWPAN node may register 415 IPv6 addresses with an authoritative border router (ABR). Generally, 416 nodes SHOULD NOT use [RFC6775] address registration. However, 417 address registration MUST be used if the first 6 bytes of the IID do 418 not comply with the format defined in Figure 3. 420 In route-over environments, IPv6 hosts MUST use [RFC6775] address 421 registration. [RFC6775] Duplicate Address Detection (DAD) SHOULD NOT 422 be used, since the link-layer inclusion process of G.9959 ensures 423 that a NodeID is unique for a given HomeID. 425 5.4.1. Prefix and CID management (Route-over) 427 A node implementation for route-over operation MAY use RFC6775 428 mechanisms for obtaining IPv6 prefixes and corresponding header 429 compression context information [RFC6282]. RFC6775 Route-over 430 requirements apply with no modifications. 432 5.4.2. Prefix and CID management (Mesh-under) 434 An implementation for mesh-under operation MUST use [RFC6775] 435 mechanisms for managing IPv6 prefixes and corresponding header 436 compression context information [RFC6282]. When using [RFC6775] 437 mechanisms for sending RAs, the M flag MUST NOT be set. As stated by 438 [RFC6775], an ABR is responsible for managing prefix(es). Global 439 prefixes may change over time. It is RECOMMENDED that a ULA prefix 440 is always assigned to the LoWPAN subnet to facilitate stable site- 441 local application associations based on IPv6 addresses. Prefixes 442 used in the LoWPAN subnet are distributed by normal RA mechanisms. 443 The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an 444 RA to disseminate Context IDs (CID) to use for compressing prefixes. 445 Prefixes and corresponding Context IDs MUST be assigned during 446 initial node inclusion. Nodes MUST renew the prefix and CID 447 according to the lifetime signaled by the ABR. [RFC6775] specifies 448 that the maximum value of the RA Router Lifetime field MAY be up to 449 0xFFFF. This document further specifies that the value 0xFFFF MUST 450 be interpreted as infinite lifetime. This value SHOULD NOT be used 451 by ABRs. Its use is only intended for a sleeping network controller; 452 for instance a battery powered remote control being master for a 453 small island-mode network of light modules. CIDs SHOULD be used in a 454 cyclic fashion to assist battery powered nodes with no real-time 455 clock. When updating context information, a CID may have its 456 lifetime set to zero to obsolete it. The CID SHOULD NOT be reused 457 immediately; rather the next vacant CID should be assigned. An ABR 458 detecting the use of an obsoleted CID SHOULD immediately send an RA 459 with updated Context Information. Header compression based on CIDs 460 MUST NOT be used for RA messages carrying Context Information. An 461 expired CID and the associated prefix SHOULD NOT be reset but rather 462 retained in receive-only mode if there is no other current need for 463 the CID value. This will allow an ABR to detect if a sleeping node 464 without clock uses an expired CID and in response, the LBR SHOULD 465 immediately return an RA with fresh Context Information to the 466 originator. Except for the specific redefinition of the RA Router 467 Lifetime value 0xFFFF, the above text is in compliance with 468 [RFC6775]. 470 6. Header Compression 471 IPv6 header fields SHOULD be compressed. If IPv6 header compression 472 is used, it MUST be according to [RFC6282]. This section will simply 473 identify substitutions that should be made when interpreting the text 474 of [RFC6282]. 476 In general the following substitutions should be made: 478 o Replace "802.15.4" with "G.9959" 480 o Replace "802.15.4 short address" with "" 482 o Replace "802.15.4 PAN ID" with "G.9959 HomeID" 484 When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short 485 address") it MUST be formed by prepending an Interface label byte to 486 the G.9959 NodeID: 488 0 1 489 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Interface | NodeID | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 A transmitting node may be sending to an IPv6 destination address 495 which can be reconstructed from the link-layer destination address. 496 If the Interface number is zero (the default value), all IPv6 address 497 bytes may be elided. Likewise, the Interface number of a fully 498 elided IPv6 address (i.e. SAM/DAM=11) may be reconstructed to the 499 value zero by a receiving node. 501 64 bit 802.15.4 address details MUST be ignored. This document only 502 specifies the use of short addresses. 504 7. IANA Considerations 506 This document makes no request of IANA. 508 Note to RFC Editor: this section may be removed on publication as an 509 RFC. 511 8. Z-Wave Alliance Considerations 513 This document requests that the Z-Wave Alliance assigns a Command 514 Class identifier for the LoWPAN Command Class; refer to Section 4.1. 516 Note to RFC Editor: this section may be removed on publication as an 517 RFC. 519 9. Security Considerations 521 The method of derivation of Interface Identifiers from 8-bit NodeIDs 522 preserves uniqueness within the logical network. However, there is 523 no protection from duplication through forgery. Neighbor Discovery 524 in G.9959 links may be susceptible to threats as detailed in 525 [RFC3756]. G.9959 networks may feature mesh routing. This implies 526 additional threats due to ad hoc routing as per [KW03]. G.9959 527 provides capability for link-layer security. G.9959 nodes MUST use 528 link-layer security with a common key. Doing so will alleviate the 529 majority of threats stated above. A sizeable portion of G.9959 530 devices is expected to always communicate within their PAN (i.e., 531 within their subnet, in IPv6 terms). In response to cost and power 532 consumption considerations, these devices will typically implement 533 the minimum set of features necessary. Accordingly, security for 534 such devices may rely on the mechanisms defined at the link layer by 535 G.9959. G.9959 relies on the Advanced Encryption Standard (AES) for 536 authentication and encryption of G.9959 frames and further employs 537 challenge-response handshaking to prevent replay attacks. 539 It is also expected that some G.9959 devices (e.g. billing and/or 540 safety critical products) will implement coordination or integration 541 functions. These may communicate regularly with IPv6 peers outside 542 the subnet. Such IPv6 devices are expected to secure their end-to- 543 end communications with standard security mechanisms (e.g., IPsec, 544 TLS, etc). 546 10. Acknowledgements 548 Thanks to the authors of RFC 4944 and RFC 6282 and members of the 549 IETF 6LoWPAN working group; this document borrows extensively from 550 their work. Thanks to Kerry Lynn, Tommas Jess Christensen and Erez 551 Ben-Tovim for useful discussions which helped shape this document. 553 11. References 555 11.1. Normative References 557 [EUI64] IEEE, "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 558 REGISTRATION AUTHORITY", IEEE Std http:// 559 standards.ieee.org/regauth/oui/tutorials/EUI64.html, 560 November 2012. 562 [G.9959.llc] 563 ITU-T, "G.9959 Contribution: Logical Link Control (LLC) 564 layer", ITU-T draft contribution 2013-04-Q15-023.doc, 565 April 2013. 567 [G.9959.sar] 568 ITU-T, "G.9959 Contribution: Segmentation And Reassembly 569 (SAR) adaptation layer", ITU-T draft contribution 570 2013-04-Q15-024.doc, April 2013. 572 [G.9959] ITU-T, "G.9959: Low-Power, narrowband radio for control 573 applications", January 2012. 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 579 6 (IPv6) Specification", RFC 2460, December 1998. 581 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 582 Networks", RFC 2464, December 1998. 584 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 585 Unicast Address Format", RFC 3587, August 2003. 587 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 588 Addresses", RFC 4193, October 2005. 590 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 591 Architecture", RFC 4291, February 2006. 593 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 594 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 595 September 2007. 597 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 598 Extensions for Stateless Address Autoconfiguration in 599 IPv6", RFC 4941, September 2007. 601 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 602 "Transmission of IPv6 Packets over IEEE 802.15.4 603 Networks", RFC 4944, September 2007. 605 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 606 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 607 September 2011. 609 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 610 "Neighbor Discovery Optimization for IPv6 over Low-Power 611 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 612 November 2012. 614 11.2. Informative References 616 [P2P-RPL] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 617 Martocci, "IETF, I-D.ietf-roll-p2p-rpl-15, Reactive 618 Discovery of Point-to-Point Routes in Low Power and Lossy 619 Networks", December 2012. 621 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 622 Discovery (ND) Trust Models and Threats", RFC 3756, May 623 2004. 625 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 626 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 627 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 628 RFC 3819, July 2004. 630 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 631 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 632 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 633 Lossy Networks", RFC 6550, March 2012. 635 Authors' Addresses 637 Anders Brandt 638 Sigma Designs 639 Emdrupvej 26A, 1. 640 Copenhagen O 2100 641 Denmark 643 Email: anders_brandt@sigmadesigns.com 645 Jakob Buron 646 Sigma Designs 647 Emdrupvej 26A, 1. 648 Copenhagen O 2100 649 Denmark 651 Email: jakob_buron@sigmadesigns.com