idnits 2.17.1 draft-ietf-6lo-lowpanz-02.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 (February 3, 2014) is 3735 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 508, but not defined == Unused Reference: 'RFC2464' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 572, 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: 3 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: August 7, 2014 February 3, 2014 7 Transmission of IPv6 packets over ITU-T G.9959 Networks 8 draft-ietf-6lo-lowpanz-02 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 August 7, 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 . . . . . . . . . 3 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. LoWPAN Adaptation Layer and Frame Format . . . . . . . . . . 6 65 3.1. Dispatch Header . . . . . . . . . . . . . . . . . . . . . 6 66 4. LoWPAN 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. Change Log . . . . . . . . . . . . . . . . . . . . . 14 82 A.1. Changes since -00 . . . . . . . . . . . . . . . . . . . . 14 83 A.2. Changes since -01 . . . . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 86 1. Introduction 88 The ITU-T G.9959 recommendation [G.9959] targets low-power Personal 89 Area Networks (PANs). This document defines the frame format for 90 transmission of IPv6 [RFC2460] packets as well as the formation of 91 IPv6 link-local addresses and statelessly autoconfigured IPv6 92 addresses on G.9959 networks. 94 The general approach is to adapt elements of [RFC4944] to G.9959 95 networks. G.9959 provides a Segmentation and Reassembly (SAR) layer 96 for transmission of datagrams larger than the G.9959 MAC PDU. 98 [RFC6775] updates [RFC4944] by specifying 6LoWPAN optimizations for 99 IPv6 Neighbor Discovery (ND) (originally defined by [RFC4861]). This 100 document limits the use of [RFC6775] to prefix and Context ID 101 assignment. It is described how to construct an IID from a G.9959 102 link-layer address. If using that method, Duplicate Address 103 Detection (DAD) is not needed. Address registration is only needed 104 in certain cases. 106 In addition to IPv6 application communication, the frame format 107 defined in this document may be used by IPv6 routing protocols such 108 as RPL [RFC6550] or P2P-RPL [RFC6997] to implement IPv6 routing over 109 G.9959 networks. 111 The encapsulation frame defined by this specification may optionally 112 be transported via mesh routing below the 6LoWPAN layer. Routing 113 protocol specifications are out of scope of this document. 115 1.1. Terms used 117 ABR: Authoritative Border Router ([RFC6775]) 119 AES: Advanced Encryption Scheme 121 EUI-64: Extended Unique Identifier 123 HomeID: G.9959 Link-Layer Network Identifier 125 IID: Interface IDentifier 127 MAC: Media Access Control 129 MTU: Maximum Transmission Unit 131 NodeID: G.9959 Link-Layer Node Identifier (Short Address) 133 PAN: Personal Area Network 135 PDU: Protocol Data Unit 137 SAR: Segmentation And Reassembly 139 ULA: Unique Local Address 141 2. G.9959 parameters to use for IPv6 transport 143 This chapter outlines properties applying to the PHY and MAC of 144 G.9959 and how to use these for IPv6 transport. 146 2.1. Addressing mode 148 G.9959 defines how a unique 32-bit HomeID network identifier is 149 assigned by a network controller and how an 8-bit NodeID host 150 identifier is allocated. NodeIDs are unique within the logical 151 network identified by the HomeID. The logical network identified by 152 the HomeID maps directly to an IPv6 subnet identified by one or more 153 IPv6 prefixes. 155 An IPv6 host MUST construct its link-local IPv6 address and routable 156 IPv6 addresses from the NodeID in order to facilitate IP header 157 compression as described in [RFC6282]. 159 A word of caution: since HomeIDs and NodeIDs are handed out by a 160 network controller function during inclusion, identifier validity and 161 uniqueness is limited by the lifetime of the logical network 162 membership. This can be cut short by a mishap occurring to the 163 network controller. Having a single point of failure at the network 164 controller suggests that deployers of high-reliability applications 165 should carefully consider adding redundancy to the network controller 166 function. 168 2.2. IPv6 Multicast support 170 [RFC3819] recommends that IP subnetworks support (subnet-wide) 171 multicast. G.9959 supports direct-range IPv6 multicast while subnet- 172 wide multicast is not supported natively by G.9959. Subnet-wide 173 multicast may be provided by an IP routing protocol or a mesh routing 174 protocol operating below the 6LoWPAN layer. Routing protocol 175 specifications are out of scope of this document. 177 IPv6 multicast packets MUST be carried via G.9959 broadcast. 179 As per [G.9959], this is accomplished as follows: 181 1. The destination HomeID of the G.9959 MAC PDU MUST be the HomeID 182 of the logical network 184 2. The destination NodeID of the G.9959 MAC PDU MUST be the 185 broadcast NodeID (0xff) 187 G.9959 broadcast MAC PDUs are only intercepted by nodes within the 188 logical network identified by the HomeID. 190 2.3. G.9959 MAC PDU size and IPv6 MTU 192 IPv6 packets MUST use G.9959 transmission profiles which support MAC 193 PDU payload sizes of 150 bytes or higher, e.g. the R3 profile. 194 G.9959 profiles R1 and R2 only supports MPDU payloads around 40 bytes 195 and the transmission speed is down to 9.6kbit/s. 197 [RFC2460] specifies that IPv6 packets may be up to 1280 octets. 198 However, a full IPv6 packet does not fit in an G.9959 MAC PDU. The 199 maximum G.9959 R3 MAC PDU payload size is 158 octets. Link-layer 200 security imposes an overhead, which in the extreme case leaves 130 201 octets available. 203 G.9959 provides Segmentation And Reassembly for payloads up to 1350 204 octets. Segmentation however adds further overhead. It is desirable 205 that datagrams can fit into a single G.9959 MAC PDU. IPv6 Header 206 Compression [RFC6282] improves the chances that a short IPv6 packet 207 can fit into a single G.9959 frame. Therefore, section Section 3 208 specifies that [RFC6282] MUST be supported. 210 2.4. Transmission status indications 212 The G.9959 MAC layer provides native acknowledgement and 213 retransmission of MAC PDUs. The G.9959 SAR layer does the same for 214 larger datagrams. A mesh routing layer may provide a similar feature 215 for routed communication. Acknowledgment and retransmission improves 216 the transmission success rate and frees higher layers from the burden 217 of implementing individual retransmission schemes. An IPv6 routing 218 stack communicating over G.9959 may utilize link-layer status 219 indications such as delivery confirmation and Ack timeout from the 220 MAC layer. 222 2.5. Transmission security 224 Implementations claiming conformance with this document MUST enable 225 G.9959 shared network key security. 227 The shared network key is intended to address security requirements 228 in the home at the normal security requirements level. For 229 applications with high or very high requirements on confidentiality 230 and/or integrity, additional application layer security measures for 231 end-to-end authentication and encryption may need to be applied. The 232 availability of the network relies on the security properties of the 233 network key in any case. 235 3. LoWPAN Adaptation Layer and Frame Format 237 The 6LoWPAN encapsulation formats defined in this chapter are carried 238 as payload in the G.9959 MAC PDU. IPv6 header compression [RFC6282] 239 MUST be supported by implementations of this specification. 241 All 6LoWPAN datagrams transported over G.9959 are prefixed by a 242 6LoWPAN encapsulation header stack. The 6LoWPAN payload (e.g. an 243 IPv6 packet) follows this encapsulation header. Each header in the 244 header stack contains a header type followed by zero or more header 245 fields. An IPv6 header stack may contain, in the following order, 246 addressing, hop-by-hop options, routing, fragmentation, destination 247 options, and finally payload [RFC2460]. The 6LoWPAN header format is 248 structured the same way. Currently only payload options are defined 249 for the 6LoWPAN header format. 251 The definition of 6LoWPAN headers consists of the dispatch value, the 252 definition of the header fields that follow, and their ordering 253 constraints relative to all other headers. Although the header stack 254 structure provides a mechanism to address future demands on the 255 6LoWPAN adaptation layer, it is not intended to provide general 256 purpose extensibility. This document specifies a small set of 257 6LoWPAN header types using the 6LoWPAN header stack for clarity, 258 compactness, and orthogonality. 260 3.1. Dispatch Header 262 The dispatch header is shown below: 264 0 1 2 3 265 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 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | 6LoWPAN CmdCls | Dispatch | Type-specific header | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Figure 1: Dispatch Type and Header 272 6LoWPAN CmdCls: 6LoWPAN Command Class identifier. This field MUST 273 carry the value 0x4F [G.9959]. The value specifies that the 274 following bits are a 6LoWPAN encapsulated datagram. Non-6LoWPAN 275 protocols MUST ignore the contents following the 6LoWPAN Command 276 Class identifier. 278 Dispatch: Identifies the header type immediately following the 279 Dispatch Header. 281 Type-specific header: A header determined by the Dispatch Header. 283 The dispatch value may be treated as an unstructured namespace. Only 284 a few symbols are required to represent current 6LoWPAN 285 functionality. Although some additional savings could be achieved by 286 encoding additional functionality into the dispatch byte, these 287 measures would tend to constrain the ability to address future 288 alternatives. 290 Dispatch values used in this specification are compatible with the 291 dispatch values defined by [RFC4944] and [RFC6282]. 293 +------------+------------------------------------------+-----------+ 294 | Pattern | Header Type | Reference | 295 +------------+------------------------------------------+-----------+ 296 | 01 1xxxxx | 6LoWPAN_IPHC - Compressed IPv6 Addresses | [RFC6282] | 297 +------------+------------------------------------------+-----------+ 298 All other Dispatch values are unassigned in this document. 300 Figure 2: Dispatch values 302 6LoWPAN_IPHC: IPv6 Header Compression. Refer to [RFC6282]. 304 4. LoWPAN addressing 306 IPv6 addresses are autoconfigured from IIDs which are again 307 constructed from link-layer address information to save memory in 308 devices and to facilitate efficient IP header compression as per 309 [RFC6282]. 311 A G.9959 NodeID is 8 bits in length. A NodeID is mapped into an IEEE 312 EUI-64 identifier as follows: 314 IID = 0000:00ff:fe00:YYXX 316 Figure 3: Constructing a compressible IID 318 where XX carries the G.9959 NodeID and YY is a one byte value chosen 319 by the individual node. The default YY value MUST be zero. A node 320 MAY use other values of YY than zero to form additional IIDs in order 321 to instantiate multiple IPv6 interfaces. The YY value MUST be 322 ignored when computing the corresponding NodeID (the XX value) from 323 an IID. 325 A 6LoWPAN network typically is used for M2M-style communication. The 326 method of constructing IIDs from the link-layer address obviously 327 does not support addresses assigned or constructed by other means. A 328 node MUST NOT compute the NodeID from the IID if the first 6 bytes of 329 the IID do not comply with the format defined in Figure 3. In that 330 case, the address resolution mechanisms of RFC 6775 apply. 332 4.1. Stateless Address Autoconfiguration of routable IPv6 addresses 334 The IID defined above MUST be used whether autoconfiguring a ULA IPv6 335 address [RFC4193] or a globally routable IPv6 address [RFC3587] in 336 G.9959 subnets. 338 4.2. IPv6 Link Local Address 340 The IPv6 link-local address [RFC4291] for a G.9959 interface is 341 formed by appending the IID defined above to the IPv6 link local 342 prefix FE80::/64. 344 The "Universal/Local" (U/L) bit MUST be set to zero in keeping with 345 the fact that this is not a globally unique value [EUI64]. 347 The resulting link local address is formed as follows: 349 10 bits 54 bits 64 bits 350 +----------+-----------------------+----------------------------+ 351 |1111111010| (zeros) | Interface Identifier (IID) | 352 +----------+-----------------------+----------------------------+ 354 Figure 4: IPv6 Link Local Address 356 4.3. Unicast Address Mapping 358 The address resolution procedure for mapping IPv6 unicast addresses 359 into G.9959 link-layer addresses follows the general description in 360 Section 7.2 of [RFC4861]. The Source/Target Link-layer Address 361 option MUST have the following form when the link layer is G.9959. 363 0 1 364 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Length=1 | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | 0x00 | NodeID | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Padding | 371 +- -+ 372 | (All zeros) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 Figure 5: IPv6 Unicast Address Mapping 377 Option fields: 379 Type: The value 1 signifies the Source Link-layer address. The value 380 2 signifies the Destination Link-layer address. 382 Length: This is the length of this option (including the type and 383 length fields) in units of 8 octets. The value of this field is 384 always 1 for G.9959 NodeIDs. 386 NodeID: This is the G.9959 NodeID the actual interface currently 387 responds to. The link-layer address may change if the interface 388 joins another network at a later time. 390 4.4. On the use of Neighbor Discovery technologies 392 [RFC4861] specifies how IPv6 nodes may resolve link layer addresses 393 from IPv6 addresses via the use of link-local IPv6 multicast. 394 [RFC6775] is an optimization of [RFC4861], specifically targeting 395 6LoWPAN networks. [RFC6775] defines how a 6LoWPAN node may register 396 IPv6 addresses with an authoritative border router (ABR). Mesh-under 397 networks MUST NOT use [RFC6775] address registration. However, 398 [RFC6775] address registration MUST be used if the first 6 bytes of 399 the IID do not comply with the format defined in Figure 3. 401 In route-over environments, IPv6 hosts MUST use [RFC6775] address 402 registration. [RFC6775] Duplicate Address Detection (DAD) MUST NOT 403 be used, since the link-layer inclusion process of G.9959 ensures 404 that a NodeID is unique for a given HomeID. 406 4.4.1. Prefix and CID management (Route-over) 408 A node implementation for route-over operation MAY use RFC6775 409 mechanisms for obtaining IPv6 prefixes and corresponding header 410 compression context information [RFC6282]. RFC6775 Route-over 411 requirements apply with no modifications. 413 4.4.2. Prefix and CID management (Mesh-under) 415 An implementation for mesh-under operation MUST use [RFC6775] 416 mechanisms for managing IPv6 prefixes and corresponding header 417 compression context information [RFC6282]. Except for the specific 418 redefinition of the RA Router Lifetime value 0xFFFF (refer to 419 Section 4.4.2.3), the text of the following subsections is in 420 compliance with [RFC6775]. 422 4.4.2.1. Prefix assignment considerations 424 When using [RFC6775] mechanisms for sending RAs, the M flag MUST NOT 425 be set. As stated by [RFC6775], an ABR is responsible for managing 426 prefix(es). Global prefixes may change over time. It is RECOMMENDED 427 that a ULA prefix is always assigned to the 6LoWPAN subnet to 428 facilitate stable site-local application associations based on IPv6 429 addresses. Prefixes used in the 6LoWPAN subnet are distributed by 430 normal RA mechanisms. 432 4.4.2.2. Robust and efficient CID management 434 The 6LoWPAN Context Option (6CO) is used according to [RFC6775] in an 435 RA to disseminate Context IDs (CID) to use for compressing prefixes. 436 Prefixes and corresponding Context IDs MUST be assigned during 437 initial node inclusion. 439 When updating context information, a CID may have its lifetime set to 440 zero to obsolete it. The CID MUST NOT be reused immediately; rather 441 the next vacant CID should be assigned. Header compression based on 442 CIDs MUST NOT be used for RA messages carrying Context Information. 443 An expired CID and the associated prefix MUST NOT be reset but rather 444 retained in receive-only mode if there is no other current need for 445 the CID value. This will allow an ABR to detect if a sleeping node 446 without clock uses an expired CID and in response, the ABR MUST 447 return an RA with fresh Context Information to the originator. 449 4.4.2.3. Infinite prefix lifetime support for island-mode networks 451 Nodes MUST renew the prefix and CID according to the lifetime 452 signaled by the ABR. [RFC6775] specifies that the maximum value of 453 the RA Router Lifetime field MAY be up to 0xFFFF. This document 454 further specifies that the value 0xFFFF MUST be interpreted as 455 infinite lifetime. This value MUST NOT be used by ABRs. Its use is 456 only intended for a sleeping network controller; for instance a 457 battery powered remote control being master for a small island-mode 458 network of light modules. 460 5. Header Compression 462 IPv6 header compression [RFC6282] MUST be implemented according to 463 [RFC6282]. This section will simply identify substitutions that 464 should be made when interpreting the text of [RFC6282]. 466 In general the following substitutions should be made: 468 o Replace "802.15.4" with "G.9959" 470 o Replace "802.15.4 short address" with "" 472 o Replace "802.15.4 PAN ID" with "G.9959 HomeID" 474 When a 16-bit address is called for (i.e., an IEEE 802.15.4 "short 475 address") it MUST be formed by prepending an Interface label byte to 476 the G.9959 NodeID: 478 0 1 479 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Interface | NodeID | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 A transmitting node may be sending to an IPv6 destination address 485 which can be reconstructed from the link-layer destination address. 486 If the Interface number is zero (the default value), all IPv6 address 487 bytes may be elided. Likewise, the Interface number of a fully 488 elided IPv6 address (i.e. SAM/DAM=11) may be reconstructed to the 489 value zero by a receiving node. 491 64 bit 802.15.4 address details MUST be ignored. This document only 492 specifies the use of short addresses. 494 6. IANA Considerations 496 This document makes no request of IANA. 498 Note to RFC Editor: this section may be removed on publication as an 499 RFC. 501 7. Security Considerations 503 The method of derivation of Interface Identifiers from 8-bit NodeIDs 504 preserves uniqueness within the logical network. However, there is 505 no protection from duplication through forgery. Neighbor Discovery 506 in G.9959 links may be susceptible to threats as detailed in 507 [RFC3756]. G.9959 networks may feature mesh routing. This implies 508 additional threats due to ad hoc routing as per [KW03]. G.9959 509 provides capability for link-layer security. G.9959 nodes MUST use 510 link-layer security with a shared key. Doing so will alleviate the 511 majority of threats stated above. A sizeable portion of G.9959 512 devices is expected to always communicate within their PAN (i.e., 513 within their subnet, in IPv6 terms). In response to cost and power 514 consumption considerations, these devices will typically implement 515 the minimum set of features necessary. Accordingly, security for 516 such devices may rely on the mechanisms defined at the link layer by 517 G.9959. G.9959 relies on the Advanced Encryption Standard (AES) for 518 authentication and encryption of G.9959 frames and further employs 519 challenge-response handshaking to prevent replay attacks. 521 It is also expected that some G.9959 devices (e.g. billing and/or 522 safety critical products) will implement coordination or integration 523 functions. These may communicate regularly with IPv6 peers outside 524 the subnet. Such IPv6 devices are expected to secure their end-to- 525 end communications with standard security mechanisms (e.g., IPsec, 526 TLS, etc). 528 8. Acknowledgements 530 Thanks to the authors of RFC 4944 and RFC 6282 and members of the 531 IETF 6LoWPAN working group; this document borrows extensively from 532 their work. Thanks to Erez Ben-Tovim, Kerry Lynn, Michael 533 Richardson, Tommas Jess Christensen for useful comments. Thanks to 534 Carsten Bormann for extensive feedback which improved this document 535 significantly. 537 9. References 539 9.1. Normative References 541 [EUI64] IEEE, "communicationIDELINES FOR 64-BIT GLOBAL IDENTIFIER 542 (EUI-64) REGISTRATION AUTHORITY", IEEE Std http:// 543 standards.ieee.org/regauth/oui/tutorials/EUI64.html, 544 November 2012. 546 [G.9959] "G.9959 (02/12) + G.9959 Amendment 1 (10/13): Short range, 547 narrow-band digital radiocommunication transceivers", 548 February 2012. 550 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 551 Requirement Levels", BCP 14, RFC 2119, March 1997. 553 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 554 (IPv6) Specification", RFC 2460, December 1998. 556 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 557 Networks", RFC 2464, December 1998. 559 [RFC3587] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global 560 Unicast Address Format", RFC 3587, August 2003. 562 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 563 Addresses", RFC 4193, October 2005. 565 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 566 Architecture", RFC 4291, February 2006. 568 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 569 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 570 September 2007. 572 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 573 Extensions for Stateless Address Autoconfiguration in 574 IPv6", RFC 4941, September 2007. 576 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 577 "Transmission of IPv6 Packets over IEEE 802.15.4 578 Networks", RFC 4944, September 2007. 580 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 581 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 582 September 2011. 584 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 585 "Neighbor Discovery Optimization for IPv6 over Low-Power 586 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 587 November 2012. 589 9.2. Informative References 591 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 592 Discovery (ND) Trust Models and Threats", RFC 3756, May 593 2004. 595 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 596 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 597 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 598 RFC 3819, July 2004. 600 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 601 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 602 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 603 Lossy Networks", RFC 6550, March 2012. 605 [RFC6997] Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. 606 Martocci, "Reactive Discovery of Point-to-Point Routes in 607 Low-Power and Lossy Networks", RFC 6997, August 2013. 609 Appendix A. Change Log 611 A.1. Changes since -00 613 o Clarified that mesh-under routing may take place below the 6lowpan 614 layer but that specific mesh-under routing protocols are not 615 within the scope of this doc. 617 o Clarified that RFC6282 IPv6 Header Compression MUST be supported. 619 o Clarified the text of section 5.4 on the use of RFC6775 address 620 registration in mesh-under networks. 622 o Split 5.4.2 into multiple paragraphs. 624 A.2. Changes since -01 626 o Added this Change Log 628 o Editorial nits. 630 o Made IPv6 Header Compression mandatory. Therefore, the Dispatch 631 value "01 000001 - Uncompressed IPv6 Addresses" was removed from 632 figure 2. 634 o Changed SHOULD to MUST: An IPv6 host SHOULD construct its link- 635 local IPv6 address and routable IPv6 addresses from the NodeID in 636 order to facilitate IP header compression as described in 637 [RFC6282]. 639 o Changed SHOULD NOT to MUST NOT: Mesh-under networks MUST NOT use 640 [RFC6775] address registration. 642 o Changed SHOULD NOT to MUST NOT: [RFC6775] Duplicate Address 643 Detection (DAD) MUST NOT be used. 645 o Changed SHOULD NOT to MUST NOT: The CID MUST NOT be reused 646 immediately; 648 o Changed SHOULD NOT to MUST NOT: An expired CID and the associated 649 prefix MUST NOT be reset but rather retained in receive-only mode 651 o Changed LBR -> ABR 653 o Changed SHOULD to MUST: , the ABR MUST return an RA with fresh 654 Context Information to the originator. 656 o Changed SHOULD NOT to MUST NOT: This value MUST NOT be used by 657 ABRs. Its use is only intended for a sleeping network controller; 659 o 661 Authors' Addresses 663 Anders Brandt 664 Sigma Designs 665 Emdrupvej 26A, 1. 666 Copenhagen O 2100 667 Denmark 669 Email: anders_brandt@sigmadesigns.com 671 Jakob Buron 672 Sigma Designs 673 Emdrupvej 26A, 1. 674 Copenhagen O 2100 675 Denmark 677 Email: jakob_buron@sigmadesigns.com