idnits 2.17.00 (12 Aug 2021) /tmp/idnits16625/draft-ietf-6lo-lowpanz-08.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 (October 30, 2014) is 2753 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'G.9959' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 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: May 3, 2015 October 30, 2014 7 Transmission of IPv6 packets over ITU-T G.9959 Networks 8 draft-ietf-6lo-lowpanz-08 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 May 3, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terms used . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. G.9959 parameters to use for IPv6 transport . . . . . . . . . 5 59 2.1. Addressing mode . . . . . . . . . . . . . . . . . . . . . 5 60 2.2. IPv6 Multicast support . . . . . . . . . . . . . . . . . 6 61 2.3. G.9959 MAC PDU size and IPv6 MTU . . . . . . . . . . . . 6 62 2.4. Transmission status indications . . . . . . . . . . . . . 7 63 2.5. Transmission security . . . . . . . . . . . . . . . . . . 7 64 3. 6LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 7 65 3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 8 66 4. 6LoWPAN addressing . . . . . . . . . . . . . . . . . . . . . 9 67 4.1. Stateless Address Autoconfiguration of routable IPv6 68 addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 69 4.2. IPv6 Link Local Address . . . . . . . . . . . . . . . . . 9 70 4.3. Unicast Address Mapping . . . . . . . . . . . . . . . . . 10 71 4.4. On the use of Neighbor Discovery technologies . . . . . . 10 72 4.4.1. Prefix and CID management (Route-over) . . . . . . . 11 73 4.4.2. Prefix and CID management (Mesh-under) . . . . . . . 11 74 5. Header Compression . . . . . . . . . . . . . . . . . . . . . 12 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 81 10.2. Informative References . . . . . . . . . . . . . . . . . 15 82 Appendix A. G.9959 6LoWPAN datagram example . . . . . . . . . . 16 83 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 20 84 B.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 20 85 B.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 20 86 B.3. Changes since -02 . . . . . . . . . . . . . . . . . . . . 21 87 B.4. Changes since -03 . . . . . . . . . . . . . . . . . . . . 21 88 B.5. Changes since -04 . . . . . . . . . . . . . . . . . . . . 22 89 B.6. Changes since -05 . . . . . . . . . . . . . . . . . . . . 22 90 B.7. Changes since -06 . . . . . . . . . . . . . . . . . . . . 22 91 B.8. Changes since -07 . . . . . . . . . . . . . . . . . . . . 22 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 94 1. Introduction 96 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal 97 Area Networks (PANs). This document defines the frame format for 98 transmission of IPv6 [RFC2460] packets as well as the formation of 99 IPv6 link-local addresses and statelessly autoconfigured IPv6 100 addresses on G.9959 networks. 102 The general approach is to adapt elements of [RFC4944] to G.9959 103 networks. G.9959 provides a Segmentation and Reassembly (SAR) layer 104 for transmission of datagrams larger than the G.9959 MAC PDU. 106 [RFC6775] updates [RFC4944] by specifying 6LoWPAN optimizations for 107 IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This 108 document limits the use of [RFC6775] to prefix and Context ID 109 assignment. An IID may be constructed from a G.9959 link-layer 110 address, leading to a "link-layer-derived IPv6 address". If using 111 that method, Duplicate Address Detection (DAD) is not needed. 112 Alternatively, IPv6 addresses may be assigned centrally via DHCP, 113 leading to a "non-link-layer-derived IPv6 address". Address 114 registration is only needed in certain cases. 116 In addition to IPv6 application communication, the frame format 117 defined in this document may be used by IPv6 routing protocols such 118 as RPL [RFC6550] or P2P-RPL [RFC6997] to implement IPv6 routing over 119 G.9959 networks. 121 The encapsulation frame defined by this specification may optionally 122 be transported via mesh routing below the 6LoWPAN layer. Mesh-under 123 and route-over routing protocol specifications are out of scope of 124 this document. 126 1.1. Terms used 128 6LoWPAN: IPv6-based Low-power Personal Area Network 130 ABR: Authoritative 6LBR ([RFC6775]) 132 Ack: Acknowedgement 134 AES: Advanced Encryption Scheme 136 CID: Context Identifier ([RFC6775]) 138 DAD: Duplicate Address Detection ([RFC6775]) 140 DHCPv6: Dynamic Host Configuration Protocol for IPv6 ([RFC3315]) 141 EUI-64: Extended Unique Identifier ([EUI64]) 143 G.9959: Short range, narrow-band digital radiocommunication 144 transceiver ([G.9959]) 146 GHC: Generic Header Compression ([RFC_TBD_GHC]) 148 HomeID: G.9959 Link-Layer Network Identifier 150 IID: Interface IDentifier 152 Link-layer-derived address: IPv6 Address constructed on basis of link 153 layer address information 155 MAC: Media Access Control 157 Mesh-under: Forwarding via mesh routing below the 6LoWPAN layer 159 MTU: Maximum Transmission Unit 161 ND: Neighbor discovery ([RFC4861], [RFC6775]) 163 NodeID: G.9959 Link-Layer Node Identifier 165 Non-link-layer-derived address: IPv6 Address assigned by a managed 166 process, e.g. DHCPv6. 168 NVM: Non-volatile Memory 170 P2P-RPL: Reactive Discovery of Point-to-Point Routes in Low-Power and 171 Lossy Networks ([RFC6997]) 173 PAN: Personal Area Network 175 PDU: Protocol Data Unit 177 PHY: Physical Layer 179 RA: Router Advertisement ([RFC4861], [RFC6775]) 181 Route-over: Forwarding via IP routing above the 6LoWPAN layer 183 RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 184 ([RFC6550]) 186 SAR: G.9959 Segmentation And Reassembly 188 ULA: Unique Local Address [RFC4193] 190 2. G.9959 parameters to use for IPv6 transport 192 This chapter outlines properties applying to the PHY and MAC of 193 G.9959 and how to use these for IPv6 transport. 195 2.1. Addressing mode 197 G.9959 defines how a unique 32-bit HomeID network identifier is 198 assigned by a network controller and how an 8-bit NodeID host 199 identifier is allocated to each node. NodeIDs are unique within the 200 network identified by the HomeID. The G.9959 HomeID represents an 201 IPv6 subnet which is identified by one or more IPv6 prefixes. 203 An IPv6 host MUST construct its link-local IPv6 address from the 204 link-layer-derived IID in order to facilitate IP header compression 205 as described in [RFC6282]. 207 A node interface MAY support the M flag of the RA message for the 208 construction of routable IPv6 addresses. A cost optimized node 209 implementation may save memory by skipping support for the M flag. 210 The M flag MUST be interpreted as defined in Figure 1. 212 +--------+--------+---------------------------------------------+ 213 | M Flag | M flag | Required node behavior | 214 | support| value | | 215 +--------+--------+---------------------------------------------+ 216 | No |(ignore)| Node MUST use link-layer-derived addressing | 217 +--------+--------+---------------------------------------------+ 218 | Yes | 0 | Node MUST use link-layer-derived addressing | 219 | +--------+---------------------------------------------+ 220 | | 1 | Node MUST use DHCPv6 based addressing and | 221 | | | Node MUST comply fully with [RFC6775] | 222 +--------+--------+---------------------------------------------+ 224 Figure 1: RA M flag support and interpretation 226 A node that uses DHCPv6 based addressing MUST comply fully with the 227 text of [RFC6775]. 229 If DHCPv6 based addressing is used, the DHCPv6 client must use a DUID 230 of type DUID-UUID, as described in [RFC6355]. The UUID used in the 231 DUID-UUID must be generated as specified in [RFC4122], section 4.5, 232 starting at the second paragraph in that section (the 47-bit random 233 number-based UUID). The DUID must be stored persistently by the node 234 as specified in section 3 of [RFC6355]. 236 A word of caution: since HomeIDs and NodeIDs are handed out by a 237 network controller function during inclusion, identifier validity and 238 uniqueness is limited by the lifetime of the network membership. 239 This can be cut short by a mishap occurring to the network 240 controller. Having a single point of failure at the network 241 controller suggests that high-reliability network deployments may 242 benefit from a redundant network controller function. 244 This warning applies to link-layer-derived addressing as well as to 245 non-link-layer-derived addressing deployments. 247 2.2. IPv6 Multicast support 249 [RFC3819] recommends that IP subnetworks support (subnet-wide) 250 multicast. G.9959 supports direct-range IPv6 multicast while subnet- 251 wide multicast is not supported natively by G.9959. Subnet-wide 252 multicast may be provided by an IP routing protocol or a mesh routing 253 protocol operating below the 6LoWPAN layer. Routing protocol 254 specifications are out of scope of this document. 256 IPv6 multicast packets MUST be carried via G.9959 broadcast. 258 As per [G.9959], this is accomplished as follows: 260 1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID 261 of the network 263 2. The destination NodeID of the G.9959 MAC PDU MUST be the 264 broadcast NodeID (0xff) 266 G.9959 broadcast MAC PDUs are only intercepted by nodes within the 267 network identified by the HomeID. 269 2.3. G.9959 MAC PDU size and IPv6 MTU 271 IPv6 packets MUST be transmitted using G.9959 transmission profile R3 272 or higher. 274 [RFC2460] specifies that any link that cannot convey a 1280-octet 275 packet in one piece, must provide link-specific fragmentation and 276 reassembly at a layer below IPv6. 278 G.9959 provides Segmentation And Reassembly for payloads up to 1350 279 octets. IPv6 Header Compression [RFC6282] improves the chances that 280 a short IPv6 packet can fit into a single G.9959 frame. Therefore, 281 Section 3 specifies that [RFC6282] MUST be supported. With the 282 mandatory link-layer security enabled, a G.9959 R3 MAC PDU may 283 accommodate 6LoWPAN datagrams of up to 130 octets without triggering 284 G.9959 Segmentation and Reassembly (SAR). Longer 6LoWPAN datagrams 285 will lead to the transmission of multiple G.9959 PDUs. 287 2.4. Transmission status indications 289 The G.9959 MAC layer provides native acknowledgement and 290 retransmission of MAC PDUs. The G.9959 SAR layer does the same for 291 larger datagrams. A mesh routing layer may provide a similar feature 292 for routed communication. An IPv6 routing stack communicating over 293 G.9959 may utilize link-layer status indications such as delivery 294 confirmation and Ack timeout from the MAC layer. 296 2.5. Transmission security 298 Implementations claiming conformance with this document MUST enable 299 G.9959 shared network key security. 301 The shared network key is intended to address security requirements 302 in the home at the normal security requirements level. For 303 applications with high or very high requirements on confidentiality 304 and/or integrity, additional application layer security measures for 305 end-to-end authentication and encryption may need to be applied. 306 (The availability of the network relies on the security properties of 307 the network key in any case) 309 3. 6LoWPAN Adaptation Layer and Frame Format 311 The 6LoWPAN encapsulation formats defined in this chapter are carried 312 as payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282] 313 MUST be supported by implementations of this specification. Further, 314 implementations MAY support Generic Header Compression (GHC) 315 [RFC_TBD_GHC]. A node implementing [RFC_TBD_GHC] MUST probe its 316 peers for GHC support before applying GHC compression. 318 All 6LoWPAN datagrams transported over G.9959 are prefixed by a 319 6LoWPAN encapsulation header stack. The 6LoWPAN payload follows this 320 encapsulation header stack. Each header in the header stack contains 321 a header type followed by zero or more header fields. An IPv6 header 322 stack may contain, in the following order, addressing, hop-by-hop 323 options, routing, fragmentation, destination options, and finally 324 payload [RFC2460]. The 6LoWPAN header format is structured the same 325 way. Currently only one payload option is defined for the G.9959 326 6LoWPAN header format. 328 The definition of 6LoWPAN headers consists of the dispatch value, the 329 definition of the header fields that follow, and their ordering 330 constraints relative to all other headers. Although the header stack 331 structure provides a mechanism to address future demands on the 332 6LoWPAN adaptation layer, it is not intended to provide general 333 purpose extensibility. 335 An example of a complete G.9959 6LoWPAN datagram can be found in 336 Appendix A. 338 3.1. Dispatch Header 340 The dispatch header is shown below: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | 6LoWPAN CmdCls| Dispatch | Type-specific header | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 2: Dispatch Type and Header 350 6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST 351 carry the value 0x4F [G.9959]. The value is assigned by the ITU-T 352 and specifies that the following bits are a 6LoWPAN encapsulated 353 datagram. 6LoWPAN protocols MUST ignore the G.9959 frame if the 354 6LoWPAN Command Class identifier deviates from 0x4F. 356 Dispatch: Identifies the header type immediately following the 357 Dispatch Header. 359 Type-specific header: A header determined by the Dispatch Header. 361 The dispatch value may be treated as an unstructured namespace. Only 362 a few symbols are required to represent current 6LoWPAN 363 functionality. Although some additional savings could be achieved by 364 encoding additional functionality into the dispatch byte, these 365 measures would tend to constrain the ability to address future 366 alternatives. 368 Dispatch values used in this specification are compatible with the 369 dispatch values defined by [RFC4944] and [RFC6282]. 371 +------------+------------------------------------------+-----------+ 372 | Pattern | Header Type | Reference | 373 +------------+------------------------------------------+-----------+ 374 | 01 1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses | [RFC6282] | 375 +------------+------------------------------------------+-----------+ 376 All other Dispatch values are unassigned in this document. 378 Figure 3: Dispatch values 380 6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282]. 382 4. 6LoWPAN addressing 384 IPv6 addresses may be autoconfigured from IIDs which may again be 385 constructed from link-layer address information to save memory in 386 devices and to facilitate efficient IP header compression as per 387 [RFC6282]. Link-layer-derived addresses have a static nature and may 388 involuntarily expose private usage data on public networks. Refer to 389 Section 8. 391 A NodeID is mapped into an IEEE EUI-64 identifier as follows: 393 IID = 0000:00ff:fe00:YYXX 395 Figure 4: Constructing a compressible IID 397 where XX carries the G.9959 NodeID and YY is a one byte value chosen 398 by the individual node. The default YY value MUST be zero. A node 399 MAY use other values of YY than zero to form additional IIDs in order 400 to instantiate multiple IPv6 interfaces. The YY value MUST be 401 ignored when computing the corresponding NodeID (the XX value) from 402 an IID. 404 The method of constructing IIDs from the link-layer address obviously 405 does not support addresses assigned or constructed by other means. A 406 node MUST NOT compute the NodeID from the IID if the first 6 bytes of 407 the IID do not comply with the format defined in Figure 4. In that 408 case, the address resolution mechanisms of RFC 6775 apply. 410 4.1. Stateless Address Autoconfiguration of routable IPv6 addresses 412 The IID defined above MUST be used whether autoconfiguring a ULA IPv6 413 address [RFC4193] or a globally routable IPv6 address [RFC3587] in 414 G.9959 subnets. 416 4.2. IPv6 Link Local Address 418 The IPv6 link-local address [RFC4291] for a G.9959 interface is 419 formed by appending the IID defined above to the IPv6 link local 420 prefix FE80::/64. 422 The "Universal/Local" (U/L) bit MUST be set to zero in keeping with 423 the fact that this is not a globally unique value [EUI64]. 425 The resulting link local address is formed as follows: 427 10 bits 54 bits 64 bits 428 +----------+-----------------------+----------------------------+ 429 |1111111010| (zeros) | Interface Identifier (IID) | 430 +----------+-----------------------+----------------------------+ 432 Figure 5: IPv6 Link Local Address 434 4.3. Unicast Address Mapping 436 The address resolution procedure for mapping IPv6 unicast addresses 437 into G.9959 link-layer addresses follows the general description in 438 Section 7.2 of [RFC4861]. The Source/Target Link-layer Address 439 option MUST have the following form when the link layer is G.9959. 441 0 1 442 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | Length=1 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | 0x00 | NodeID | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Padding | 449 +- -+ 450 | (All zeros) | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 Figure 6: IPv6 Unicast Address Mapping 455 Option fields: 457 Type: The value 1 signifies the Source Link-layer address. The value 458 2 signifies the Destination Link-layer address. 460 Length: This is the length of this option (including the type and 461 length fields) in units of 8 octets. The value of this field is 462 always 1 for G.9959 NodeIDs. 464 NodeID: This is the G.9959 NodeID the actual interface currently 465 responds to. The link-layer address may change if the interface 466 joins another network at a later time. 468 4.4. On the use of Neighbor Discovery technologies 470 [RFC4861] specifies how IPv6 nodes may resolve link layer addresses 471 from IPv6 addresses via the use of link-local IPv6 multicast. 472 [RFC6775] is an optimization of [RFC4861], specifically targeting 473 6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register 474 IPv6 addresses with an authoritative border router (ABR). Mesh-under 475 networks MUST NOT use [RFC6775] address registration. However, 476 [RFC6775] address registration MUST be used if the first 6 bytes of 477 the IID do not comply with the format defined in Figure 3. 479 4.4.1. Prefix and CID management (Route-over) 481 In route-over environments, IPv6 hosts MUST use [RFC6775] address 482 registration. A node implementation for route-over operation MAY use 483 RFC6775 mechanisms for obtaining IPv6 prefixes and corresponding 484 header compression context information [RFC6282]. RFC6775 Route-over 485 requirements apply with no modifications. 487 4.4.2. Prefix and CID management (Mesh-under) 489 An implementation for mesh-under operation MUST use [RFC6775] 490 mechanisms for managing IPv6 prefixes and corresponding header 491 compression context information [RFC6282]. [RFC6775] Duplicate 492 Address Detection (DAD) MUST NOT be used, since the link-layer 493 inclusion process of G.9959 ensures that a NodeID is unique for a 494 given HomeID. 496 With this exception and the specific redefinition of the RA Router 497 Lifetime value 0xFFFF (refer to Section 4.4.2.3), the text of the 498 following subsections is in compliance with [RFC6775]. 500 4.4.2.1. Prefix assignment considerations 502 As stated by [RFC6775], an ABR is responsible for managing 503 prefix(es). Global routable prefixes may change over time. It is 504 RECOMMENDED that a ULA prefix is assigned to the 6LoWPAN subnet to 505 facilitate stable site-local application associations based on IPv6 506 addresses. A node MAY support the M flag of the RA message. This 507 influences the way IPv6 addresses are assigned. Refer to Section 2.1 508 for details. 510 4.4.2.2. Robust and efficient CID management 512 The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an 513 RA to disseminate Context IDs (CID) to use for compressing prefixes. 514 One or more prefixes and corresponding Context IDs MUST be assigned 515 during initial node inclusion. 517 When updating context information, a CID may have its lifetime set to 518 zero to obsolete it. The CID MUST NOT be reused immediately; rather 519 the next vacant CID should be assigned. Header compression based on 520 CIDs MUST NOT be used for RA messages carrying Context Information. 522 An expired CID and the associated prefix MUST NOT be reset but rather 523 retained in receive-only mode if there is no other current need for 524 the CID value. This will allow an ABR to detect if a sleeping node 525 without clock uses an expired CID and in response, the ABR MUST 526 return an RA with fresh Context Information to the originator. 528 4.4.2.3. Infinite prefix lifetime support for island-mode networks 530 Nodes MUST renew the prefix and CID according to the lifetime 531 signaled by the ABR. [RFC6775] specifies that the maximum value of 532 the RA Router Lifetime field MAY be up to 0xFFFF. This document 533 further specifies that the value 0xFFFF MUST be interpreted as 534 infinite lifetime. This value MUST NOT be used by ABRs. Its use is 535 only intended for a sleeping network controller; for instance a 536 battery powered remote control being master for a small island-mode 537 network of light modules. 539 5. Header Compression 541 IPv6 header compression [RFC6282] MUST be implemented and 542 [RFC_TBD_GHC] compression for higher layers MAY be implemented. This 543 section will simply identify substitutions that should be made when 544 interpreting the text of [RFC6282] and [RFC_TBD_GHC]. 546 In general the following substitutions should be made: 548 o Replace "802.15.4" with "G.9959" 550 o Replace "802.15.4 short address" with "" 552 o Replace "802.15.4 PAN ID" with "G.9959 HomeID" 554 When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short 555 address") it MUST be formed by prepending an Interface label byte to 556 the G.9959 NodeID: 558 0 1 559 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Interface | NodeID | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 A transmitting node may be sending to an IPv6 destination address 565 which can be reconstructed from the link-layer destination address. 566 If the Interface number is zero (the default value), all IPv6 address 567 bytes may be elided. Likewise, the Interface number of a fully 568 elided IPv6 address (i.e. SAM/DAM=11) may be reconstructed to the 569 value zero by a receiving node. 571 64 bit 802.15.4 address details do not apply. 573 6. IANA Considerations 575 This document makes no request of IANA. 577 Note to RFC Editor: this section may be removed on publication as an 578 RFC. 580 7. Security Considerations 582 The method of derivation of Interface Identifiers from 8-bit NodeIDs 583 preserves uniqueness within the network. However, there is no 584 protection from duplication through forgery. Neighbor Discovery in 585 G.9959 links may be susceptible to threats as detailed in [RFC3756]. 586 G.9959 networks may feature mesh routing. This implies additional 587 threats due to ad hoc routing as per [KW03]. G.9959 provides 588 capability for link-layer security. G.9959 nodes MUST use link-layer 589 security with a shared key. Doing so will alleviate the majority of 590 threats stated above. A sizeable portion of G.9959 devices is 591 expected to always communicate within their PAN (i.e., within their 592 subnet, in IPv6 terms). In response to cost and power consumption 593 considerations, these devices will typically implement the minimum 594 set of features necessary. Accordingly, security for such devices 595 may rely on the mechanisms defined at the link layer by G.9959. 596 G.9959 relies on the Advanced Encryption Standard (AES) for 597 authentication and encryption of G.9959 frames and further employs 598 challenge-response handshaking to prevent replay attacks. 600 It is also expected that some G.9959 devices (e.g. billing and/or 601 safety critical products) will implement coordination or integration 602 functions. These may communicate regularly with IPv6 peers outside 603 the subnet. Such IPv6 devices are expected to secure their end-to- 604 end communications with standard security mechanisms (e.g., IPsec, 605 TLS, etc). 607 8. Privacy Considerations 609 IP addresses may be used to track devices on the Internet, which in 610 turn can be linked to individuals and their activities. Depending on 611 the application and the actual use pattern, this may be undesirable. 612 To impede tracking, globally unique and non-changing characteristics 613 of IP addresses should be avoided, e.g. by frequently changing the 614 global prefix and avoiding unique link-layer-derived IIDs in 615 addresses. 617 Some link layers use a 48-bit or a 64-bit link layer address which 618 uniquely identifies the node on a global scale regardless of global 619 prefix changes. The risk of exposing a G.9959 device from its link- 620 layer-derived IID is limited because of the short 8-bit link layer 621 address. 623 While intended for central address management, DHCPv6 address 624 assignment also decouples the IPv6 address from the link layer 625 address. Addresses may be made dynamic by the use of a short DHCP 626 lease period and an assignment policy which makes the DHCP server 627 hand out a fresh IP address every time. For enhanced privacy, the 628 DHCP assigned addresses should be logged only for the duration of the 629 lease provided the implementation also allows logging for longer 630 durations as per the operational policies. 632 It should be noted that privacy and frequently changing address 633 assignment comes at a cost. Non-link-layer-derived IIDs require the 634 use of address registration and further, non-link-layer-derived IIDs 635 cannot be compressed, which leads to longer datagrams and increased 636 link layer segmentation. Finally, frequent prefix changes 637 necessitate more Context Identifier updates, which not only leads to 638 increased traffic but also may affect the battery lifetime of 639 sleeping nodes. 641 9. Acknowledgements 643 Thanks to the authors of RFC 4944 and RFC 6282 and members of the 644 IETF 6LoWPAN working group; this document borrows extensively from 645 their work. Thanks to Erez Ben-Tovim, Erik Nordmark, Kerry Lynn, 646 Michael Richardson, Tommas Jess Christensen for useful comments. 647 Thanks to Carsten Bormann for extensive feedback which improved this 648 document significantly. Thanks to Brian Haberman for pointing out 649 unclear details. 651 10. References 653 10.1. Normative References 655 [G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range, 656 narrow-band digital radiocommunication transceivers", 657 February 2012. 659 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 660 Requirement Levels", BCP 14, RFC 2119, March 1997. 662 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 663 (IPv6) Specification", RFC 2460, December 1998. 665 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 666 Unique IDentifier (UUID) URN Namespace", RFC 4122, July 667 2005. 669 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 670 Addresses", RFC 4193, October 2005. 672 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 673 Architecture", RFC 4291, February 2006. 675 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 676 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 677 September 2007. 679 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 680 "Transmission of IPv6 Packets over IEEE 802.15.4 681 Networks", RFC 4944, September 2007. 683 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 684 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 685 September 2011. 687 [RFC6355] Narten, T. and J. Johnson, "Definition of the UUID-Based 688 DHCPv6 Unique Identifier (DUID-UUID)", RFC 6355, August 689 2011. 691 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 692 "Neighbor Discovery Optimization for IPv6 over Low-Power 693 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 694 November 2012. 696 [RFC_TBD_GHC] 697 "draft-ietf-6lo-ghc: 6LoWPAN Generic Compression of 698 Headers and Header-like Payloads", September 2014. 700 10.2. Informative References 702 [EUI64] IEEE, "GUIIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 703 REGISTRATION AUTHORITY", IEEE Std http:// 704 standards.ieee.org/regauth/oui/tutorials/EUI64.html, 705 November 2012. 707 [KW03] Elsevier's AdHoc Networks Journal, ""Secure Routing in 708 Sensor Networks: Attacks and Countermeasures", Special 709 Issue on Sensor Network Applications and Protocols vol 1, 710 issues 2-3", , September 2003. 712 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 713 and M. Carney, "Dynamic Host Configuration Protocol for 714 IPv6 (DHCPv6)", RFC 3315, July 2003. 716 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 717 Unicast Address Format", RFC 3587, August 2003. 719 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 720 Discovery (ND) Trust Models and Threats", RFC 3756, May 721 2004. 723 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 724 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 725 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 726 RFC 3819, July 2004. 728 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 729 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 730 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 731 Lossy Networks", RFC 6550, March 2012. 733 [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 734 Martocci, "Reactive Discovery of Point-to-Point Routes in 735 Low-Power and Lossy Networks", RFC 6997, August 2013. 737 Appendix A. G.9959 6LoWPAN datagram example 739 This example outlines each individual bit of a sample IPv6 UDP packet 740 arriving to a G.9959 node from a host in the Internet via a PAN 741 border router. 743 In the G.9959 PAN, the complete frame has the following fields. 745 G.9959: 747 +------+---------+----------+---+-----+----------... 748 |HomeID|SrcNodeID|FrmControl|Len|SeqNo|DestNodeID| 749 +------+---------+----------+---+-----+----------+-... 751 6LoWPAN: 753 ...+--------------+----------------+-----------------------... 754 |6LoWPAN CmdCls|6LoWPAN_IPHC Hdr|Compressed IPv6 headers| 755 ...-------------+----------------+-----------------------+-... 757 6LoWPAN, TCP/UDP, App payload: 759 ...+-------------------------+------------+-----------+ 760 |Uncompressed IPv6 headers|TCP/UDP/ICMP|App payload| 761 ...------------------------+------------+-----------+ 763 The frame comes from the source IPv6 address 764 2001:0db8:ac10:ef01::ff:fe00:1206. The source prefix 765 2001:0db8:ac10:ef01/64 is identified by the IPHC CID = 3. 767 The frame is delivered in direct range from the gateway which has 768 source NodeID = 1. The Interface Identifier (IID) ff:fe00:1206 is 769 recognised as a link-layer-derived address and is compressed to the 770 16 bit value 0x1206. 772 The frame is sent to the destination IPv6 address 773 2001:0db8:27ef:42ca::ff:fe00:0004. The destination prefix 774 2001:0db8:27ef:42ca/64 is identified by the IPHC CID = 2. 776 The Interface Identifier (IID) ff:fe00:0004 is recognised as a link- 777 layer-derived address. 779 Thanks to the link-layer-derived addressing rules, the sender knows 780 that this is to be sent to G.9959 NodeID = 4; targeting the IPv6 781 interface instance number 0 (the default). 783 To reach the 6LoWPAN stack of the G.9959 node, (skipping the G.9959 784 header fields) the first octet must be the 6LoWPAN Command Class 785 (0x4F). 787 0 788 0 1 2 3 4 5 6 7 8 789 +-+-+-+-+-+-+-+-... 790 | 0x4F | 791 +-+-+-+-+-+-+-+-+-... 793 The Dispatch header bits '011' advertises a compressed IPv6 header. 795 0 1 796 0 1 2 3 4 5 6 7 8 9 0 797 +-+-+-+-+-+-+-+-+-+-+-... 798 | 0x4F |0 1 1 799 +-+-+-+-+-+-+-+-+-+-+-+-... 801 The following bits encode the first IPv6 header fields: 803 TF = '11' : Traffic Class and Flow Label are elided. 804 NH = '1' : Next Header is elided 805 HLIM = '10' : Hop limit is 64 807 0 1 808 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 810 | 0x4F |0 1 1 1 1 1 1 0| 811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 813 CID = '1' : CI data follows the DAM field 814 SAC = '1' : Src addr uses stateful, context-based compression 815 SAM = '10' : Use src CID and 16 bits for link-layer-derived addr 816 M = '0' : Dest addr is not a multicast addr 817 DAC = '1' : Dest addr uses stateful, context-based compression 818 DAM = '11' : Use dest CID and dest NodeID to link-layer-derived addr 820 0 1 2 821 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 823 | 0x4F |0 1 1 1 1 1 1 0|1 1 1 0 0 1 1 1| 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 826 Address compression context identifiers: 828 SCI = 0x3 829 DCI = 0x2 831 2 3 832 4 5 6 7 8 9 0 1 833 ...+-+-+-+-+-+-+-+-... 834 | 0x3 | 0x2 | 835 ...+-+-+-+-+-+-+-+-... 837 IPv6 header fields: 838 (skipping "version" field) 839 (skipping "Traffic Class") 840 (skipping "flow label") 841 (skipping "payload length") 843 IPv6 header address fields: 845 SrcIP = 0x1206 : Use SCI and 16 LS bits of link-layer-derived address 847 (skipping DestIP ) - completely reconstructed from Dest NodeID and DCI 849 2 3 4 850 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 851 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 852 | 0x3 | 0x2 | 0x12 | 0x06 | 853 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 855 Next header encoding for the UDP header: 857 Dispatch = '11110': Next Header dispatch code for UDP header 858 C = '0' : 16 bit checksum carried inline 859 P = '00' : Both src port and dest Port are carried in-line. 861 4 5 862 8 9 0 1 2 3 4 5 863 ...+-+-+-+-+-+-+-+-... 864 |1 1 1 1 0|0|0 0| 865 ...+-+-+-+-+-+-+-+-... 867 UDP header fields: 869 src Port = 0x1234 870 dest port = 0x5678 872 5 6 7 8 873 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 874 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 875 | 0x12 | 0x34 | 0x56 | 0x78 | 876 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-.. 878 (skipping "length") 879 checksum = .... (actual checksum value depends on 880 the actual UDP payload) 882 1 883 8 9 0 884 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 885 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 886 | (UDP checksum) | 887 ...+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... 889 Add your own UDP payload here... 891 Appendix B. Change Log 893 B.1. Changes since -00 895 o Clarified that mesh-under routing may take place below the 6LoWPAN 896 layer but that specific mesh-under routing protocols are not 897 within the scope of this doc. 899 o Clarified that RFC6282 IPv6 Header Compression MUST be supported. 901 o Clarified the text of section 5.4 on the use of RFC6775 address 902 registration in mesh-under networks. 904 o Split 5.4.2 into multiple paragraphs. 906 B.2. Changes since -01 908 o Added this Change Log 910 o Editorial nits. 912 o Made IPv6 Header Compression mandatory. Therefore, the Dispatch 913 value "01 000001 - Uncompressed IPv6 Addresses" was removed from 914 figure 2. 916 o Changed SHOULD to MUST: An IPv6 host SHOULD construct its link- 917 local IPv6 address and routable IPv6 addresses from the NodeID in 918 order to facilitate IP header compression as described in 919 [RFC6282]. 921 o Changed SHOULD NOT to MUST NOT: Mesh-under networks MUST NOT use 922 [RFC6775] address registration. 924 o Changed SHOULD NOT to MUST NOT: [RFC6775] Duplicate Address 925 Detection (DAD) MUST NOT be used. 927 o Changed SHOULD NOT to MUST NOT: The CID MUST NOT be reused 928 immediately; 930 o Changed SHOULD NOT to MUST NOT: An expired CID and the associated 931 prefix MUST NOT be reset but rather retained in receive-only mode 933 o Changed LBR -> ABR 935 o Changed SHOULD to MUST: , the ABR MUST return an RA with fresh 936 Context Information to the originator. 938 o Changed SHOULD NOT to MUST NOT: This value MUST NOT be used by 939 ABRs. Its use is only intended for a sleeping network controller. 941 B.3. Changes since -02 943 o Editorial nits. 945 o Moved text to the right section so that it does not prohibit DAD 946 for Route-Over deployments. 948 o Introduced RA M flag support so that nodes may be instructed to 949 use DHCPv6 for centralized address assignment. 951 o Added example appendix: Complete G.9959 6LoWPAN datagram 952 composition with CID-based header compression. 954 B.4. Changes since -03 956 o Corrected error in 6LoWPAN datagram example appendix: 64 hop limit 957 in comment => also 64 hop limit in actual frame format. 959 o Added section "Privacy Considerations" 961 B.5. Changes since -04 963 o Text on RA M flag support was replaced with a table to improve 964 clarity. 966 o Added further details to text on achieving privacy addressing with 967 DHCP. 969 B.6. Changes since -05 971 o Term ABR now points to Authoritative 6LBR as defined by RFC6775. 973 o Removed sentence "The G.9959 network controller function SHOULD be 974 integrated in the ABR." as this was an implementation guideline 975 with no relevance to network performance. 977 o Clarifying that network controller function redundancy is relevant 978 for network deployers; not user-level application designers. 980 o Clarified that RFC2460 specifies that link layer must provide 981 fragmentation if 1280 octet packets cannot be carried in one piece 982 by the link layer. 984 o Clarified that the 6LoWPAN CmdCls identifier value is assigned by 985 the ITU-T. 987 o Added reference to Privacy Considerations section from 6LoWPAN 988 Addressing section. 990 o Introducing optional GHC header compression. 992 B.7. Changes since -06 994 o Added a note to section 5, that the mapping of 802.15.4 terms to 995 similar G.9959 terms applies not only to RFC6282 but also to GHC. 997 B.8. Changes since -07 999 o Added a note to the Privacy considerations section on avoiding 1000 DHCP logging. 1002 o Added requirements for forming a UUID if DHCPv6 address assignment 1003 is used. 1005 Authors' Addresses 1007 Anders Brandt 1008 Sigma Designs 1009 Emdrupvej 26A, 1. 1010 Copenhagen O 2100 1011 Denmark 1013 Email: anders_brandt@sigmadesigns.com 1015 Jakob Buron 1016 Sigma Designs 1017 Emdrupvej 26A, 1. 1018 Copenhagen O 2100 1019 Denmark 1021 Email: jakob_buron@sigmadesigns.com