idnits 2.17.1 draft-bormann-6lowpan-roadmap-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 (September 06, 2012) is 4251 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-09 == 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-04 == Outdated reference: A later version (-04) exists of draft-bormann-intarea-alfi-01 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-11 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) Summary: 1 error (**), 0 flaws (~~), 6 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 September 06, 2012 5 Expires: March 10, 2013 7 6LoWPAN Roadmap and Implementation Guide 8 draft-bormann-6lowpan-roadmap-02 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 The current version -02 of this document is an early draft that is 35 intended to spark the further collection of relevant information. 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 10, 2013. 54 Copyright Notice 56 Copyright (c) 2012 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2.1. Optional components of 6LoWPAN . . . . . . . . . . . . . . 5 75 3. 6LoWPAN family . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.1. 6LoWPAN over Bluetooth Low Energy (BT-LE) . . . . . . . . 6 77 3.2. 6LoWPAN over DECT Ultra Low Energy (DECT-ULE) . . . . . . 6 78 4. 6LoWPAN MTU . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 5. PAN identifiers in IPv6 addresses . . . . . . . . . . . . . . 8 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 85 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 (To be written - for now please read the Abstract.) 92 1.1. Terminology 94 This document is a guide. However, it might evolve to make specific 95 recommendations on how to use standards-track specifications. 96 Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 97 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in RFC 99 2119. They indicate requirement levels for compliant 6LoWPAN 100 implementations [RFC2119]. Note that these keywords are not only 101 used where a correction or clarification is intended; the latter are 102 explicitly identified as such. 104 The term "byte" is used in its now customary sense as a synonym for 105 "octet". 107 2. 6LoWPAN 109 What is a 6LoWPAN? 111 The term, originally just the name of the IETF Working Group (WG) 112 that created the specifications, nowadays refers to a specific way of 113 building IP-connected wireless networks for embedded use cases. The 114 6LoWPAN core specifications are: 116 o [RFC4944], as updated by 118 o [RFC6282] and 120 o [I-D.ietf-6lowpan-nd]. 122 (Note that, while still being referenced here as an Internet-Draft, 123 [I-D.ietf-6lowpan-nd] has been approved as a standards-track RFC on 124 2012-08-24 and is now in the RFC editor queue waiting for final 125 editing in order to be published.) 127 While [RFC4944] defines 6LoWPAN specifically for IEEE 802.15.4 128 networks, 6LoWPAN concepts have been applied to other PHY/MAC layers. 130 6LoWPANs MAY use additional protocols, such as [RFC6550] for routing, 131 or [I-D.ietf-core-coap] for application data transfer. However, the 132 "6LoWPANness" of a network is caused by adherence to the core 133 specifications. 135 2.1. Optional components of 6LoWPAN 137 Additional sub-protocols are being discussed in the IETF that may 138 become optional protocols in 6LoWPANs. 140 For instance, [I-D.bormann-6lowpan-ghc] defines an extension to 141 [RFC6282] that enables header compression of additional headers and 142 header-like protocols, including ICMPv6 and RPL. 144 One other recent proposal that may be of interest to application 145 designers targeting link layers with small frame sizes is Adaptation 146 Layer Fragmentation Indication (ALFI), [I-D.bormann-intarea-alfi]. 148 The present document will track these sub-protocols and be amended 149 once the sub-protocols reach formal status in the IETF. 151 3. 6LoWPAN family 153 In addition to the support for IEEE 802.15.4 provided by [RFC4944], 154 additional PHY/MAC layers outside IEEE 802.15.4 (or even 802.15) are 155 being addressed by 6LoWPAN technology. 157 E.g., [I-D.ietf-6lowpan-btle] applies 6LoWPAN technology to Bluetooth 158 Low Energy ("Bluetooth Smart"). As this has passed both 6LoWPAN 159 Working-Group and IETF Last Call and has received one round of IESG 160 consideration (now necessitating some, mostly editorial, changes), it 161 is becoming part of the "6LoWPAN family" as a companion specification 162 to [RFC4944], if not part of the (IEEE 802.15.4 focused) term 6LoWPAN 163 itself. 165 At an earlier stage of work, [I-D.mariager-6lowpan-v6over-dect-ule] 166 aims to define 6LoWPAN technology for DECT ULE (Ultra Low Energy), 167 which might become another companion spec to [RFC4944]. 169 In the further evolution of the 6LoWPAN family, we have to be careful 170 what changes apply to all members of the family, and which are PHY/ 171 MAC specific. 173 3.1. 6LoWPAN over Bluetooth Low Energy (BT-LE) 175 [I-D.ietf-6lowpan-btle] similarly specifies the combination of 177 o [RFC4944], as updated by 179 o [RFC6282] and 181 o [I-D.ietf-6lowpan-nd]. 183 as the basis for IPv6 over BT-LE, removing a couple of features from 184 [RFC4944] as they are covered by or become unnecessary in BT-LE: 186 o Mesh header 188 o Fragmentation 190 3.2. 6LoWPAN over DECT Ultra Low Energy (DECT-ULE) 192 [I-D.mariager-6lowpan-v6over-dect-ule] is stabilizing in parallel to 193 the base documents that are maturing within ETSI. While silicon is 194 already available, complete systems with final firmware (and thus 195 stable specs) are expected within 2012. 197 4. 6LoWPAN MTU 199 IPv6 defines a minimal value for the "Minimum Transmission Unit", 200 MTU, of 1280 bytes. This means that every IPv6 network must be able 201 to transfer a packet of at least 1280 bytes of IPv6 headers and data 202 without requiring fragmentation. 204 A common Internet MTU is 1500 bytes (motivated by the Ethernet MTU). 205 The gap between 1280 and 1500 allows tunneling protocols to insert 206 headers on the way from the source of a packet to a destination 207 without breaking the overall MTU of the path. As various tunneling 208 protocols do indeed insert bytes, it is unwise to simply assume an 209 end-to-end MTU of 1500 bytes even with the current dominance of 210 Ethernet. Path MTU discovery [RFC1981] [RFC4821] has been defined to 211 enable transport protocols to find an MTU value better than 1280 212 bytes, but still reliably within the MTU of the path being used. 213 Path MTU discovery places, however, additional strain on constrained 214 nodes, which therefore may want to stick with an MTU of 1280 bytes 215 for all IPv6 applications. 217 6LoWPAN was designed as a stub network, not requiring any tunneling. 218 As IEEE 802.15.4 packets are rather small (127 bytes maximum at the 219 physical layer, minus MAC/security and adaptation layer overhead), 220 1280 bytes was already considered a somewhat large packet size. 221 Therefore, the 6LoWPAN network MTU was simply set at the minimum size 222 allowable by IPv6, 1280 bytes, although the 6LoWPAN fragmentation 223 mechanism is able to support packets with total lengths (including 224 the initial IPv6 header) of up to 2047 bytes. 226 As a more recent development, some modes of operation of the RPL 227 protocol [RFC6550] do indeed operate by tunneling data packets 228 between RPL routers. Maintaining the MTU visible to applications at 229 1280 therefore requires making a larger MTU available to the tunnels. 231 6LoWPAN routers that employ RPL therefore MUST support a more 232 appropriate MTU between routers that make use of tunneling between 233 them. [The specific MTU value is TBD, to be chosen between 1280 and 234 2047 based on RPL considerations that need to be added to this 235 document.] 237 5. PAN identifiers in IPv6 addresses 239 [RFC4944] incorporates PAN identifiers in IPv6 addresses created from 240 16-bit MAC addresses, in a somewhat awkward way (one of the 16 bits 241 needs to be cleared to enable the U/L bit.). 243 As the use of PAN identifiers in 6LoWPAN networks has since become 244 less and less meaningful, [RFC6282] provides specific support only 245 for interface IDs of the form 0000:00ff:fe00:XXXX, i.e. PAN 246 identifiers of zero. (Other forms can be supported by creating 247 sufficiently long pieces of compression context information for each 248 non-zero PAN identifier; however there is a limited number of context 249 elements and each consumes space in all nodes of a 6LoWPAN.) 251 It is therefore RECOMMENDED to employ a PAN identifier of zero with 252 6LoWPAN. 254 (While this discussion is specific to IEEE 802.15.4 networks, the 255 recommendation to build short addresses in a way that enables 256 [RFC6282] compression may apply to other PHY/MAC technologies as 257 well.) 259 6. IANA Considerations 261 This document has no actions for IANA. 263 7. Security Considerations 265 (None so far; this section will certainly grow as additional security 266 considerations beyond those listed in the base specifications become 267 known.) 269 8. Acknowledgements 271 (The concept for this document is borrowed from [RFC4815], which was 272 invented by Lars-Erik Jonsson. Thanks!) 274 9. References 276 9.1. Normative References 278 [I-D.ietf-6lowpan-btle] 279 Nieminen, J., Patil, B., Savolainen, T., Isomaki, M., 280 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 281 over Bluetooth Low Energy", draft-ietf-6lowpan-btle-09 282 (work in progress), July 2012. 284 [I-D.ietf-6lowpan-nd] 285 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 286 Discovery Optimization for Low Power and Lossy Networks 287 (6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress), 288 August 2012. 290 [I-D.mariager-6lowpan-v6over-dect-ule] 291 Mariager, P. and J. Petersen, "Transmission of IPv6 292 Packets over DECT Ultra Low Energy", 293 draft-mariager-6lowpan-v6over-dect-ule-02 (work in 294 progress), May 2012. 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, March 1997. 299 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 300 "Transmission of IPv6 Packets over IEEE 802.15.4 301 Networks", RFC 4944, September 2007. 303 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 304 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 305 September 2011. 307 9.2. Informative References 309 [I-D.bormann-6lowpan-ghc] 310 Bormann, C., "6LoWPAN Generic Compression of Headers and 311 Header-like Payloads", draft-bormann-6lowpan-ghc-04 (work 312 in progress), March 2012. 314 [I-D.bormann-intarea-alfi] 315 Bormann, C., "Adaptation Layer Fragmentation Indication", 316 draft-bormann-intarea-alfi-01 (work in progress), 317 July 2012. 319 [I-D.ietf-core-coap] 320 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 321 "Constrained Application Protocol (CoAP)", 322 draft-ietf-core-coap-11 (work in progress), July 2012. 324 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 325 for IP version 6", RFC 1981, August 1996. 327 [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, 328 "RObust Header Compression (ROHC): Corrections and 329 Clarifications to RFC 3095", RFC 4815, February 2007. 331 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 332 Discovery", RFC 4821, March 2007. 334 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 335 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 336 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 337 Lossy Networks", RFC 6550, March 2012. 339 Author's Address 341 Carsten Bormann 342 Universitaet Bremen TZI 343 Postfach 330440 344 Bremen D-28359 345 Germany 347 Phone: +49-421-218-63921 348 Fax: +49-421-218-7000 349 Email: cabo@tzi.org