idnits 2.17.1 draft-bormann-6lowpan-roadmap-01.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 (March 26, 2012) is 4404 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-06 == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-18 == Outdated reference: A later version (-03) exists of draft-mariager-6lowpan-v6over-dect-ule-01 ** 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-03 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-09 -- 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 March 26, 2012 5 Expires: September 27, 2012 7 6LoWPAN Roadmap and Implementation Guide 8 draft-bormann-6lowpan-roadmap-01 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 attempts 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 -01 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 September 27, 2012. 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 specification. 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 WG that created the 112 specifications, nowadays refers to a specific way of building IP- 113 connected wireless networks for embedded use cases. The 6LoWPAN core 114 specifications are: 116 o [RFC4944], as updated by 118 o [RFC6282] and 120 o [I-D.ietf-6lowpan-nd]. 122 While [RFC4944] defines 6LoWPAN specifically for IEEE 802.15.4 123 networks, 6LoWPAN concepts have been applied to other PHY/MAC layers. 125 6LoWPANs MAY use additional protocols, such as [I-D.ietf-roll-rpl] 126 for routing, or [I-D.ietf-core-coap] for application data transfer. 127 However, the "6LoWPANness" of a network is caused by adherence to the 128 core specifications. 130 2.1. Optional components of 6LoWPAN 132 Additional sub-protocols are being discussed in the IETF that may 133 become optional protocols in 6LoWPANs. 135 For instance, [I-D.bormann-6lowpan-ghc] defines an extension to 136 [RFC6282] that enables header compression of additional headers and 137 header-like protocols, including ICMPv6 and RPL. 139 This document will track these sub-protocols and be amended once the 140 sub-protocols reach formal status in the IETF. 142 3. 6LoWPAN family 144 In addition to the support for IEEE 802.15.4 provided by [RFC4944], 145 additional PHY/MAC layers outside IEEE 802.15.4 (or even 802.15) are 146 being addressed by 6LoWPAN technology. 148 E.g., [I-D.ietf-6lowpan-btle] applies 6LoWPAN technology to Bluetooth 149 Low Energy ("Bluetooth Smart"). As this has passed 6LoWPAN Working- 150 Group Last-Call and is nearing IESG consideration, it is becoming 151 part of the "6LoWPAN family" as a companion specification to 152 [RFC4944], if not part of the (IEEE 802.15.4 focused) term 6LoWPAN 153 itself. 155 At an earlier stage of work, [I-D.mariager-6lowpan-v6over-dect-ule] 156 aims to define 6LoWPAN technology for DECT ULE (Ultra Low Energy), 157 which might become another companion spec to [RFC4944]. 159 In the further evolution of the 6LoWPAN family, we have to be careful 160 what changes apply to all members of the family, and which are PHY/ 161 MAC specific. 163 3.1. 6LoWPAN over Bluetooth Low Energy (BT-LE) 165 [I-D.ietf-6lowpan-btle] similarly specifies the combination of 167 o [RFC4944], as updated by 169 o [RFC6282] and 171 o [I-D.ietf-6lowpan-nd]. 173 as the basis for IPv6 over BT-LE, removing a couple of features from 174 [RFC4944] as they are covered by or become unnecessary in BT-LE: 176 o Mesh header 178 o Fragmentation 180 3.2. 6LoWPAN over DECT Ultra Low Energy (DECT-ULE) 182 [I-D.mariager-6lowpan-v6over-dect-ule] is stabilizing in parallel to 183 the base documents that are maturing within ETSI. While silicon is 184 already available, complete systems with final firmware (and thus 185 stable specs) are expected within 2012. 187 4. 6LoWPAN MTU 189 IPv6 defines a minimal value for the "Minimum Transmission Unit", 190 MTU, of 1280 bytes. This means that every IPv6 network must be able 191 to transfer a packet of at least 1280 bytes of IPv6 headers and data 192 without requiring fragmentation. 194 A common Internet MTU is 1500 bytes (motivated by the Ethernet MTU). 195 The gap between 1280 and 1500 allows tunneling protocols to insert 196 headers on the way from the source of a packet to a destination 197 without breaking the overall MTU of the path. As various tunneling 198 protocols do indeed insert bytes, it is unwise to simply assume an 199 end-to-end MTU of 1500 bytes even with the current dominance of 200 Ethernet. Path MTU discovery [RFC1981] [RFC4821] has been defined to 201 enable transport protocols to find an MTU value better than 1280 202 bytes, but still reliably within the MTU of the path being used. 203 Path MTU discovery places, however, additional strain on constrained 204 nodes, which therefore may want to stick with an MTU of 1280 bytes 205 for all IPv6 applications. 207 6LoWPAN was designed as a stub network, not requiring any tunneling. 208 As IEEE 802.15.4 packets are rather small (127 bytes maximum at the 209 physical layer, minus MAC/security and adaptation layer overhead), 210 1280 bytes was already considered a somewhat large packet size. 211 Therefore, the 6LoWPAN network MTU was simply set at the minimum size 212 allowable by IPv6, 1280 bytes, although the 6LoWPAN fragmentation 213 mechanism is able to support packets with total lengths (including 214 the initial IPv6 header) of up to 2047 bytes. 216 As a more recent development, some modes of operation of the RPL 217 protocol [I-D.ietf-roll-rpl] do indeed operate by tunneling data 218 packets between RPL routers. Maintaining the MTU visible to 219 applications at 1280 therefore requires making a larger MTU available 220 to the tunnels. 222 6LoWPAN routers that employ RPL therefore MUST support a more 223 appropriate MTU between routers that make use of tunneling between 224 them. [The specific MTU value is TBD, to be chosen between 1280 and 225 2047 based on RPL considerations that need to be added to this 226 document.] 228 5. PAN identifiers in IPv6 addresses 230 [RFC4944] incorporates PAN identifiers in IPv6 addresses created from 231 16-bit MAC addresses, in a somewhat awkward way (one of the 16 bits 232 needs to be cleared to enable the U/L bit.). 234 As the use of PAN identifiers in 6LoWPAN networks has since become 235 less and less meaningful, [RFC6282] provides specific support only 236 for interface IDs of the form 0000:00ff:fe00:XXXX, i.e. PAN 237 identifiers of zero. (Other forms can be supported by creating 238 sufficiently long pieces of compression context information for each 239 non-zero PAN identifier; however there is a limited number of context 240 elements and each consumes space in all nodes of a 6LoWPAN.) 242 It is therefore RECOMMENDED to employ a PAN identifier of zero with 243 6LoWPAN. 245 (While this discussion is specific to IEEE 802.15.4 networks, the 246 recommendation to build short addresses in a way that enables 247 [RFC6282] compression may apply to other PHY/MAC technologies as 248 well.) 250 6. IANA Considerations 252 This document has no actions for IANA. 254 7. Security Considerations 256 (None so far; this section will certainly grow as additional security 257 considerations beyond those listed in the base specifications become 258 known.) 260 8. Acknowledgements 262 (The concept for this document is borrowed from [RFC4815], which was 263 invented by Lars-Erik Jonsson. Thanks!) 265 9. References 267 9.1. Normative References 269 [I-D.ietf-6lowpan-btle] 270 Nieminen, J., Patil, B., Savolainen, T., Isomaki, M., 271 Shelby, Z., and C. Gomez, "Transmission of IPv6 Packets 272 over Bluetooth Low Energy", draft-ietf-6lowpan-btle-06 273 (work in progress), March 2012. 275 [I-D.ietf-6lowpan-nd] 276 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 277 Discovery Optimization for Low Power and Lossy Networks 278 (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress), 279 October 2011. 281 [I-D.mariager-6lowpan-v6over-dect-ule] 282 Mariager, P. and J. Petersen, "Transmission of IPv6 283 Packets over DECT Ultra Low Energy", 284 draft-mariager-6lowpan-v6over-dect-ule-01 (work in 285 progress), October 2011. 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 291 "Transmission of IPv6 Packets over IEEE 802.15.4 292 Networks", RFC 4944, September 2007. 294 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 295 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 296 September 2011. 298 9.2. Informative References 300 [I-D.bormann-6lowpan-ghc] 301 Bormann, C., "6LoWPAN Generic Compression of Headers and 302 Header-like Payloads", draft-bormann-6lowpan-ghc-03 (work 303 in progress), October 2011. 305 [I-D.ietf-core-coap] 306 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 307 "Constrained Application Protocol (CoAP)", 308 draft-ietf-core-coap-09 (work in progress), March 2012. 310 [I-D.ietf-roll-rpl] 311 Brandt, A., Vasseur, J., Hui, J., Pister, K., Thubert, P., 312 Levis, P., Struik, R., Kelsey, R., Clausen, T., and T. 314 Winter, "RPL: IPv6 Routing Protocol for Low power and 315 Lossy Networks", draft-ietf-roll-rpl-19 (work in 316 progress), March 2011. 318 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 319 for IP version 6", RFC 1981, August 1996. 321 [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, 322 "RObust Header Compression (ROHC): Corrections and 323 Clarifications to RFC 3095", RFC 4815, February 2007. 325 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 326 Discovery", RFC 4821, March 2007. 328 Author's Address 330 Carsten Bormann 331 Universitaet Bremen TZI 332 Postfach 330440 333 Bremen D-28359 334 Germany 336 Phone: +49-421-218-63921 337 Fax: +49-421-218-7000 338 Email: cabo@tzi.org