idnits 2.17.1 draft-bormann-6lowpan-roadmap-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 22, 2012) is 4175 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) == Outdated reference: A later version (-12) exists of draft-ietf-6lowpan-btle-11 == Outdated reference: A later version (-03) exists of draft-mariager-6lowpan-v6over-dect-ule-02 ** 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 (-06) exists of draft-bormann-6lowpan-ghc-05 == Outdated reference: A later version (-04) exists of draft-bormann-intarea-alfi-01 == Outdated reference: A later version (-03) exists of draft-ersue-constrained-mgmt-02 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-12 == Outdated reference: A later version (-02) exists of draft-lhotka-netmod-yang-json-00 == Outdated reference: A later version (-03) exists of draft-schoenw-6lowpan-mib-01 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track October 22, 2012 5 Expires: April 25, 2013 7 6LoWPAN Roadmap and Implementation Guide 8 draft-bormann-6lowpan-roadmap-03 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 acceptance curve 27 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 25, 2013. 50 Copyright Notice 52 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Optional components of 6LoWPAN . . . . . . . . . . . . . . 5 71 2.2. 6LoWPAN MIB work . . . . . . . . . . . . . . . . . . . . . 5 72 3. 6LoWPAN family . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3.1. 6LoWPAN over Bluetooth Low Energy (BT-LE) . . . . . . . . 7 74 3.2. 6LoWPAN over DECT Ultra Low Energy (DECT-ULE) . . . . . . 7 75 4. 6LoWPAN MTU . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. PAN identifiers in IPv6 addresses . . . . . . . . . . . . . . 9 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 (To be written - for now please read the Abstract.) 89 1.1. Terminology 91 This document is a guide. However, it might evolve to make specific 92 recommendations on how to use standards-track specifications. 93 Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 94 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 95 "OPTIONAL" in this document are to be interpreted as described in RFC 96 2119. They indicate requirement levels for compliant 6LoWPAN 97 implementations [RFC2119]. Note that these keywords are not only 98 used where a correction or clarification is intended; the latter are 99 explicitly identified as such. 101 The term "byte" is used in its now customary sense as a synonym for 102 "octet". 104 2. 6LoWPAN 106 What is a 6LoWPAN? 108 The term, originally just the name of the IETF Working Group (WG) 109 that created the specifications, nowadays refers to a specific way of 110 building IP-connected wireless networks for embedded use cases. The 111 6LoWPAN core specifications are: 113 o [RFC4944], as updated by 115 o [RFC6282] and 117 o [I-D.ietf-6lowpan-nd]. 119 (Note that, while still being referenced here as an Internet-Draft, 120 [I-D.ietf-6lowpan-nd] has been approved as a standards-track RFC on 121 2012-08-24 and is now in final RFC editor processing in order to be 122 published as RFC 6775.) 124 While [RFC4944] defines 6LoWPAN specifically for IEEE 802.15.4 125 networks, 6LoWPAN concepts have been applied to other PHY/MAC layers. 127 6LoWPANs MAY use additional protocols, such as [RFC6550] for routing, 128 or [I-D.ietf-core-coap] for application data transfer. However, the 129 "6LoWPANness" of a network is caused by adherence to the core 130 specifications. 132 2.1. Optional components of 6LoWPAN 134 Additional sub-protocols are being discussed in the IETF that may 135 become optional protocols in 6LoWPANs. 137 For instance, [I-D.bormann-6lowpan-ghc] defines an extension to 138 [RFC6282] that enables header compression of additional headers and 139 header-like protocols, including ICMPv6 and RPL. 141 One other recent proposal that may be of interest to application 142 designers targeting link layers with small frame sizes is Adaptation 143 Layer Fragmentation Indication (ALFI), [I-D.bormann-intarea-alfi]. 145 The present document will track these sub-protocols and be amended 146 once the sub-protocols reach formal status in the IETF. 148 2.2. 6LoWPAN MIB work 150 For management of 6LoWPAN networks, a MIB is being proposed in 151 [I-D.schoenw-6lowpan-mib]. Besides the usual SMIv2 MIB format that 152 directly enables management access via SNMP, this draft also 153 demonstrates a JSON format using a version of the MIB translated into 154 YANG [RFC6020] as defined in [RFC6643] and made available using the 155 JSON representation defined in [I-D.lhotka-netmod-yang-json]. This 156 may facilitate using CoRE protocols for management access 157 [I-D.ersue-constrained-mgmt], reducing the number transfer protocols 158 that need to be implemented on a constrained node. 160 3. 6LoWPAN family 162 In addition to the support for IEEE 802.15.4 provided by [RFC4944], 163 additional PHY/MAC layers outside IEEE 802.15.4 (or even 802.15) are 164 being addressed by 6LoWPAN technology. 166 E.g., [I-D.ietf-6lowpan-btle] applies 6LoWPAN technology to Bluetooth 167 Low Energy ("Bluetooth Smart"). As this has passed both 6LoWPAN 168 Working-Group and IETF Last Call and has received one round of IESG 169 consideration (now necessitating some, mostly editorial, changes), it 170 is becoming part of the "6LoWPAN family" as a companion specification 171 to [RFC4944], if not part of the (IEEE 802.15.4 focused) term 6LoWPAN 172 itself. 174 At an earlier stage of work, [I-D.mariager-6lowpan-v6over-dect-ule] 175 aims to define 6LoWPAN technology for DECT ULE (Ultra Low Energy), 176 which might become another companion spec to [RFC4944]. 178 In the further evolution of the 6LoWPAN family, we have to be careful 179 what changes apply to all members of the family, and which are PHY/ 180 MAC specific. 182 3.1. 6LoWPAN over Bluetooth Low Energy (BT-LE) 184 [I-D.ietf-6lowpan-btle] similarly specifies the combination of 186 o [RFC4944], as updated by 188 o [RFC6282] and 190 o [I-D.ietf-6lowpan-nd]. 192 as the basis for IPv6 over BT-LE, removing a couple of features from 193 [RFC4944] as they are covered by or become unnecessary in BT-LE: 195 o Mesh header 197 o Fragmentation 199 3.2. 6LoWPAN over DECT Ultra Low Energy (DECT-ULE) 201 [I-D.mariager-6lowpan-v6over-dect-ule] is stabilizing in parallel to 202 the base documents that are maturing within ETSI. While silicon is 203 already available, complete systems with final firmware (and thus 204 stable specs) are expected within 2012. 206 4. 6LoWPAN MTU 208 IPv6 defines a minimal value for the "Minimum Transmission Unit", 209 MTU, of 1280 bytes. This means that every IPv6 network must be able 210 to transfer a packet of at least 1280 bytes of IPv6 headers and data 211 without requiring fragmentation. 213 A common Internet MTU is 1500 bytes (motivated by the Ethernet MTU). 214 The gap between 1280 and 1500 allows tunneling protocols to insert 215 headers on the way from the source of a packet to a destination 216 without breaking the overall MTU of the path. As various tunneling 217 protocols do indeed insert bytes, it is unwise to simply assume an 218 end-to-end MTU of 1500 bytes even with the current dominance of 219 Ethernet. Path MTU discovery [RFC1981] [RFC4821] has been defined to 220 enable transport protocols to find an MTU value better than 1280 221 bytes, but still reliably within the MTU of the path being used. 222 Path MTU discovery places, however, additional strain on constrained 223 nodes, which therefore may want to stick with an MTU of 1280 bytes 224 for all IPv6 applications. 226 6LoWPAN was designed as a stub network, not requiring any tunneling. 227 As IEEE 802.15.4 packets are rather small (127 bytes maximum at the 228 physical layer, minus MAC/security and adaptation layer overhead), 229 1280 bytes was already considered a somewhat large packet size. 230 Therefore, the 6LoWPAN network MTU was simply set at the minimum size 231 allowable by IPv6, 1280 bytes, although the 6LoWPAN fragmentation 232 mechanism is able to support packets with total lengths (including 233 the initial IPv6 header) of up to 2047 bytes. 235 As a more recent development, some modes of operation of the RPL 236 protocol [RFC6550] do indeed operate by tunneling data packets 237 between RPL routers. Maintaining the MTU visible to applications at 238 1280 therefore requires making a larger MTU available to the tunnels. 240 6LoWPAN routers that employ RPL therefore MUST support a more 241 appropriate MTU between routers that make use of tunneling between 242 them. [The specific MTU value is TBD, to be chosen between 1280 and 243 2047 based on RPL considerations that need to be added to this 244 document.] 246 5. PAN identifiers in IPv6 addresses 248 [RFC4944] incorporates PAN identifiers in IPv6 addresses created from 249 16-bit MAC addresses, in a somewhat awkward way (one of the 16 bits 250 needs to be cleared to enable the U/L bit.). 252 As the use of PAN identifiers in 6LoWPAN networks has since become 253 less and less meaningful, [RFC6282] provides specific support only 254 for interface IDs of the form 0000:00ff:fe00:XXXX, i.e. PAN 255 identifiers of zero. (Other forms can be supported by creating 256 sufficiently long pieces of compression context information for each 257 non-zero PAN identifier; however there is a limited number of context 258 elements and each consumes space in all nodes of a 6LoWPAN.) 260 It is therefore RECOMMENDED to employ a PAN identifier of zero with 261 6LoWPAN. 263 (While this discussion is specific to IEEE 802.15.4 networks, the 264 recommendation to build short addresses in a way that enables 265 [RFC6282] compression may apply to other PHY/MAC technologies as 266 well.) 268 6. IANA Considerations 270 This document has no actions for IANA. 272 7. Security Considerations 274 (None so far; this section will certainly grow as additional security 275 considerations beyond those listed in the base specifications become 276 known.) 278 8. Acknowledgements 280 (The concept for this document is borrowed from [RFC4815], which was 281 invented by Lars-Erik Jonsson. Thanks!) 283 9. References 285 9.1. Normative References 287 [I-D.ietf-6lowpan-btle] 288 Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., 289 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 290 over BLUETOOTH Low Energy", draft-ietf-6lowpan-btle-11 291 (work in progress), October 2012. 293 [I-D.ietf-6lowpan-nd] 294 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 295 Discovery Optimization for Low Power and Lossy Networks 296 (6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress), 297 August 2012. 299 [I-D.mariager-6lowpan-v6over-dect-ule] 300 Mariager, P. and J. Petersen, "Transmission of IPv6 301 Packets over DECT Ultra Low Energy", 302 draft-mariager-6lowpan-v6over-dect-ule-02 (work in 303 progress), May 2012. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 309 "Transmission of IPv6 Packets over IEEE 802.15.4 310 Networks", RFC 4944, September 2007. 312 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 313 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 314 September 2011. 316 9.2. Informative References 318 [I-D.bormann-6lowpan-ghc] 319 Bormann, C., "6LoWPAN Generic Compression of Headers and 320 Header-like Payloads", draft-bormann-6lowpan-ghc-05 (work 321 in progress), September 2012. 323 [I-D.bormann-intarea-alfi] 324 Bormann, C., "Adaptation Layer Fragmentation Indication", 325 draft-bormann-intarea-alfi-01 (work in progress), 326 July 2012. 328 [I-D.ersue-constrained-mgmt] 329 Ersue, M., Romascanu, D., and J. Schoenwaelder, 330 "Management of Networks with Constrained Devices: Use 331 Cases and Requirements", draft-ersue-constrained-mgmt-02 332 (work in progress), October 2012. 334 [I-D.ietf-core-coap] 335 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 336 "Constrained Application Protocol (CoAP)", 337 draft-ietf-core-coap-12 (work in progress), October 2012. 339 [I-D.lhotka-netmod-yang-json] 340 Lhotka, L., "Modeling JSON Text with YANG", 341 draft-lhotka-netmod-yang-json-00 (work in progress), 342 October 2012. 344 [I-D.schoenw-6lowpan-mib] 345 Schoenwaelder, J., Sehgal, A., Tsou, T., and C. Zhou, 346 "Definition of Managed Objects for IPv6 over Low-Power 347 Wireless Personal Area Networks (6LoWPANs)", 348 draft-schoenw-6lowpan-mib-01 (work in progress), 349 October 2012. 351 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 352 for IP version 6", RFC 1981, August 1996. 354 [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, 355 "RObust Header Compression (ROHC): Corrections and 356 Clarifications to RFC 3095", RFC 4815, February 2007. 358 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 359 Discovery", RFC 4821, March 2007. 361 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 362 Network Configuration Protocol (NETCONF)", RFC 6020, 363 October 2010. 365 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 366 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 367 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 368 Lossy Networks", RFC 6550, March 2012. 370 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 371 Information Version 2 (SMIv2) MIB Modules to YANG 372 Modules", RFC 6643, July 2012. 374 Author's Address 376 Carsten Bormann 377 Universitaet Bremen TZI 378 Postfach 330440 379 Bremen D-28359 380 Germany 382 Phone: +49-421-218-63921 383 Email: cabo@tzi.org