idnits 2.17.1 draft-bormann-6lo-6lowpan-roadmap-00.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 21, 2013) is 3832 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) ** Downref: Normative reference to an Informational draft: draft-mariager-6lowpan-v6over-dect-ule (ref. 'I-D.mariager-6lowpan-v6over-dect-ule') == Outdated reference: A later version (-01) exists of draft-schoenw-6lo-lowpan-mib-00 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6Lo Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track October 21, 2013 5 Expires: April 24, 2014 7 6LoWPAN Roadmap and Implementation Guide 8 draft-bormann-6lo-6lowpan-roadmap-00 10 Abstract 12 6LoWPAN is defined in RFC 4944 in conjunction with a number of 13 specifications that are currently nearing completion. The entirety 14 of these specifications may be hard to understand, pose specific 15 implementation problems, or be simply inconsistent. 17 The present guide aims to provide a roadmap to these documents as 18 well as provide specific advice how to use these specifications in 19 combination. In certain cases, it may provide clarifications or even 20 corrections to the specifications referenced. 22 This guide is intended as a continued work-in-progress, i.e. a long- 23 lived Internet-Draft, to be updated whenever new information becomes 24 available and new consensus on how to handle issues is formed. 25 Similar to the ROHC implementation guide, RFC 4815, it might be 26 published as an RFC at some future time later in the maintenance 27 curve of the specifications. 29 This document does not describe a new protocol or attempt to set a 30 new standard of any kind - it mostly describes good practice in using 31 the existing specifications, but it may also document emerging 32 consensus where a correction needs to be made. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 24, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Optional components of 6LoWPAN . . . . . . . . . . . . . 3 71 2.2. 6LoWPAN MIB work . . . . . . . . . . . . . . . . . . . . 4 72 3. 6LoWPAN family . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.1. 6LoWPAN over Bluetooth Low Energy (BT-LE) . . . . . . . . 4 74 3.2. 6LoWPAN over DECT Ultra Low Energy (DECT-ULE) . . . . . . 5 75 3.3. 6LoWPAN over G.9959 (lowpanz) . . . . . . . . . . . . . . 5 76 4. 6LoWPAN MTU . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 5. PAN identifiers in IPv6 addresses . . . . . . . . . . . . . . 6 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 83 9.2. Informative References . . . . . . . . . . . . . . . . . 7 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 (To be written - for now please read the Abstract.) 90 1.1. Terminology 92 This document is a guide. However, it might evolve to make specific 93 recommendations on how to use standards-track specifications. 94 Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 95 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in RFC 97 2119. They indicate requirement levels for compliant 6LoWPAN 98 implementations [RFC2119]. Note that these keywords are not only 99 used where a correction or clarification is intended; the latter are 100 explicitly identified as such. 102 The term "byte" is used in its now customary sense as a synonym for 103 "octet". 105 2. 6LoWPAN 107 What is a 6LoWPAN? 109 The term, originally just the name of the IETF Working Group (WG) 110 that created the specifications, nowadays refers to a specific way of 111 building IP-connected wireless networks for embedded use cases. The 112 6LoWPAN core specifications are: 114 o [RFC4944], as updated by 116 o [RFC6282] and 118 o [RFC6775]. 120 While [RFC4944] defines 6LoWPAN specifically for IEEE 802.15.4 121 networks, 6LoWPAN concepts have been applied to other PHY/MAC layers. 123 6LoWPANs MAY use additional protocols, such as [RFC6550] for routing, 124 or [I-D.ietf-core-coap] for application data transfer. However, the 125 "6LoWPANness" of a network is caused by adherence to the core 126 specifications. 128 2.1. Optional components of 6LoWPAN 130 Additional sub-protocols are being discussed in the IETF that may 131 become optional protocols in 6LoWPANs. 133 For instance, [I-D.bormann-6lo-ghc] defines an extension to [RFC6282] 134 that enables header compression of additional headers and header-like 135 protocols, including ICMPv6 and RPL. 137 One other recent proposal, in a much more nascent stage, that may be 138 of interest to application designers targeting link layers with small 139 frame sizes is Adaptation Layer Fragmentation Indication (ALFI), 140 [I-D.bormann-intarea-alfi]. 142 The present document will track these sub-protocols and be amended 143 once the sub-protocols reach formal status in the IETF. 145 2.2. 6LoWPAN MIB work 147 For management of 6LoWPAN networks, a MIB is being proposed in 148 [I-D.schoenw-6lo-lowpan-mib]. Besides the usual SMIv2 MIB format 149 that directly enables management access via SNMP, this draft also 150 demonstrates a JSON format using a version of the MIB translated into 151 YANG [RFC6020] as defined in [RFC6643] and made available using the 152 JSON representation defined in [I-D.lhotka-netmod-yang-json]. This 153 may facilitate using CoRE protocols for management access 154 [I-D.ersue-constrained-mgmt], reducing the number transfer protocols 155 that need to be implemented on a constrained node. 157 3. 6LoWPAN family 159 In addition to the support for IEEE 802.15.4 provided by [RFC4944], 160 additional PHY/MAC layers outside IEEE 802.15.4 (or even 802.15) are 161 being addressed by 6LoWPAN technology. 163 E.g., [I-D.ietf-6lowpan-btle] applies 6LoWPAN technology to Bluetooth 164 Low Energy ("Bluetooth Smart"). As this has passed both 6LoWPAN 165 Working-Group and IETF Last Call and has received one round of IESG 166 consideration (now waiting for the allocation of a number from the 167 BT-SIG), it is becoming part of the "6LoWPAN family" as a companion 168 specification to [RFC4944], if not part of the (IEEE 802.15.4 169 focused) term 6LoWPAN itself. 171 At an earlier stage of work, [I-D.mariager-6lowpan-v6over-dect-ule] 172 aims to define 6LoWPAN technology for DECT ULE (Ultra Low Energy), 173 which might become another companion spec to [RFC4944]. Similarly, 174 [I-D.brandt-6man-lowpanz] is a now complete draft defining 6LoWPAN 175 technology for the ITU-T G.9959 radio. 177 In the further evolution of the 6LoWPAN family, we have to be careful 178 what changes apply to all members of the family, and which are PHY/ 179 MAC specific. 181 3.1. 6LoWPAN over Bluetooth Low Energy (BT-LE) 183 [I-D.ietf-6lowpan-btle] similarly specifies the combination of 185 o [RFC4944], as updated by 187 o [RFC6282] and 189 o [RFC6775]. 191 as the basis for IPv6 over BT-LE, removing a couple of features from 192 [RFC4944] as they are covered by or become unnecessary in BT-LE: 194 o Mesh header 196 o Fragmentation 198 3.2. 6LoWPAN over DECT Ultra Low Energy (DECT-ULE) 200 [I-D.mariager-6lowpan-v6over-dect-ule] is stabilizing in parallel to 201 the base documents that are maturing within ETSI. While silicon is 202 already available, complete systems with final firmware (and thus 203 stable specs) are expected within 2012. 205 3.3. 6LoWPAN over G.9959 (lowpanz) 207 [I-D.brandt-6man-lowpanz] was discussed at IETF86 in Orlando and 208 received updates based on this discussion and further mailing list 209 work. The G.9959 radio used in this specification operates in 210 various regionally available frequencies around 900 MHz ("sub-GHz") 211 and is best known for its use in the Z-Wave suite of products. As 212 with BT-LE, this MAC layer already defines a Segmentation and 213 Reassembly (SAR) layer, so packets larger than the G.9959 MAC PDU can 214 be transmitted without the need for [RFC4944] fragmentation. 215 Similarly, MAC layer mesh forwarding is available for G.9959 already. 217 4. 6LoWPAN MTU 219 IPv6 defines a minimal value for the "Minimum Transmission Unit", 220 MTU, of 1280 bytes. This means that every IPv6 network must be able 221 to transfer a packet of at least 1280 bytes of IPv6 headers and data 222 without requiring fragmentation. 224 A common Internet MTU is 1500 bytes (motivated by the Ethernet MTU). 225 The gap between 1280 and 1500 allows tunneling protocols to insert 226 headers on the way from the source of a packet to a destination 227 without breaking the overall MTU of the path. As various tunneling 228 protocols do indeed insert bytes, it is unwise to simply assume an 229 end-to-end MTU of 1500 bytes even with the current dominance of 230 Ethernet. Path MTU discovery [RFC1981] [RFC4821] has been defined to 231 enable transport protocols to find an MTU value better than 1280 232 bytes, but still reliably within the MTU of the path being used. 233 Path MTU discovery places, however, additional strain on constrained 234 nodes, which therefore may want to stick with an MTU of 1280 bytes 235 for all IPv6 applications. 237 6LoWPAN was designed as a stub network, not requiring any tunneling. 238 As IEEE 802.15.4 packets are rather small (127 bytes maximum at the 239 physical layer, minus MAC/security and adaptation layer overhead), 240 1280 bytes was already considered a somewhat large packet size. 241 Therefore, the 6LoWPAN network MTU was simply set at the minimum size 242 allowable by IPv6, 1280 bytes, although the 6LoWPAN fragmentation 243 mechanism is able to support packets with total lengths (including 244 the initial IPv6 header) of up to 2047 bytes. 246 As a more recent development, some modes of operation of the RPL 247 protocol [RFC6550] do indeed operate by tunneling data packets 248 between RPL routers. Maintaining the MTU visible to applications at 249 1280 therefore requires making a larger MTU available to the tunnels. 251 6LoWPAN routers that employ RPL therefore MUST support a more 252 appropriate MTU between routers that make use of tunneling between 253 them. [The specific MTU value is TBD, to be chosen between 1280 and 254 2047 based on RPL considerations that need to be added to this 255 document.] 257 5. PAN identifiers in IPv6 addresses 259 [RFC4944] incorporates PAN identifiers in IPv6 addresses created from 260 16-bit MAC addresses, in a somewhat awkward way (one of the 16 bits 261 needs to be cleared to enable the U/L bit.). 263 As the use of PAN identifiers in 6LoWPAN networks has since become 264 less and less meaningful, [RFC6282] provides specific support only 265 for interface IDs of the form 0000:00ff:fe00:XXXX, i.e. PAN 266 identifiers of zero. (Other forms can be supported by creating 267 sufficiently long pieces of compression context information for each 268 non-zero PAN identifier; however there is a limited number of context 269 elements and each consumes space in all nodes of a 6LoWPAN.) 271 It is therefore RECOMMENDED to employ a PAN identifier of zero with 272 6LoWPAN. 274 (While this discussion is specific to IEEE 802.15.4 networks, the 275 recommendation to build short addresses in a way that enables 276 [RFC6282] compression may apply to other PHY/MAC technologies as 277 well.) 279 6. IANA Considerations 281 This document has no actions for IANA. 283 7. Security Considerations 285 (None so far; this section will certainly grow as additional security 286 considerations beyond those listed in the base specifications become 287 known.) 289 8. Acknowledgements 291 (The concept for this document is borrowed from [RFC4815], which was 292 invented by Lars-Erik Jonsson. Thanks!) 294 9. References 296 9.1. Normative References 298 [I-D.brandt-6man-lowpanz] 299 Brandt, A. and J. Buron, "Transmission of IPv6 packets 300 over ITU-T G.9959 Networks", draft-brandt-6man-lowpanz-02 301 (work in progress), June 2013. 303 [I-D.ietf-6lowpan-btle] 304 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 305 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 306 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-12 307 (work in progress), February 2013. 309 [I-D.mariager-6lowpan-v6over-dect-ule] 310 Mariager, P., Petersen, J., and Z. Shelby, "Transmission 311 of IPv6 Packets over DECT Ultra Low Energy", draft- 312 mariager-6lowpan-v6over-dect-ule-03 (work in progress), 313 July 2013. 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, March 1997. 318 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 319 "Transmission of IPv6 Packets over IEEE 802.15.4 320 Networks", RFC 4944, September 2007. 322 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 323 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 324 September 2011. 326 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 327 "Neighbor Discovery Optimization for IPv6 over Low-Power 328 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 329 November 2012. 331 9.2. Informative References 333 [I-D.bormann-6lo-ghc] 334 Bormann, C., "6LoWPAN Generic Compression of Headers and 335 Header-like Payloads", draft-bormann-6lo-ghc-00 (work in 336 progress), October 2013. 338 [I-D.bormann-intarea-alfi] 339 Bormann, C., "Adaptation Layer Fragmentation Indication", 340 draft-bormann-intarea-alfi-04 (work in progress), 341 September 2013. 343 [I-D.ersue-constrained-mgmt] 344 Ersue, M., Romascanu, D., and J. Schoenwaelder, 345 "Management of Networks with Constrained Devices: Problem 346 Statement, Use Cases and Requirements", draft-ersue- 347 constrained-mgmt-03 (work in progress), February 2013. 349 [I-D.ietf-core-coap] 350 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 351 Application Protocol (CoAP)", draft-ietf-core-coap-18 352 (work in progress), June 2013. 354 [I-D.lhotka-netmod-yang-json] 355 Lhotka, L., "Modeling JSON Text with YANG", draft-lhotka- 356 netmod-yang-json-02 (work in progress), September 2013. 358 [I-D.schoenw-6lo-lowpan-mib] 359 Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 360 "Definition of Managed Objects for IPv6 over Low-Power 361 Wireless Personal Area Networks (6LoWPANs)", draft- 362 schoenw-6lo-lowpan-mib-00 (work in progress), October 363 2013. 365 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 366 for IP version 6", RFC 1981, August 1996. 368 [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, 369 "RObust Header Compression (ROHC): Corrections and 370 Clarifications to RFC 3095", RFC 4815, February 2007. 372 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 373 Discovery", RFC 4821, March 2007. 375 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 376 Network Configuration Protocol (NETCONF)", RFC 6020, 377 October 2010. 379 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 380 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 381 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 382 Lossy Networks", RFC 6550, March 2012. 384 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 385 Information Version 2 (SMIv2) MIB Modules to YANG 386 Modules", RFC 6643, July 2012. 388 Author's Address 390 Carsten Bormann 391 Universitaet Bremen TZI 392 Postfach 330440 393 Bremen D-28359 394 Germany 396 Phone: +49-421-218-63921 397 Email: cabo@tzi.org