idnits 2.17.1 draft-bormann-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 (March 7, 2011) is 4798 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-ietf-6lowpan-nd-15 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-04 == Outdated reference: A later version (-19) exists of draft-ietf-roll-rpl-18 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) Summary: 0 errors (**), 0 flaws (~~), 4 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: Informational March 7, 2011 5 Expires: September 8, 2011 7 6LoWPAN Roadmap and Implementation Guide 8 draft-bormann-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 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 31 using the existing specifications, but it may also document emerging 32 consensus where a correction needs to be made. 34 The current version -00 of this document is just an initial draft 35 that is intended to spark the 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 8, 2011. 54 Copyright Notice 56 Copyright (c) 2011 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 3. 6LoWPAN MTU . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 4. PAN identifiers in IPv6 addresses . . . . . . . . . . . . . . 7 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 84 1. Introduction 86 (To be written - for now please read the Abstract.) 88 1.1. Terminology 90 This document is a guide. However, it might evolve to make specific 91 recommendations on how to use standards-track specification. 92 Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 93 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 94 "OPTIONAL" in this document are to be interpreted as described in RFC 95 2119. They indicate requirement levels for compliant 6LoWPAN 96 implementations [RFC2119]. Note that these keywords are not only 97 used where a correction or clarification is intended; the latter are 98 explicitly identified as such. 100 The term "byte" is used in its now customary sense as a synonym for 101 "octet". 103 2. 6LoWPAN 105 What is a 6LoWPAN? 107 The term, originally just the name of the IETF WG that created the 108 specifications, nowadays refers to a specific way of building IP- 109 connected wireless networks for embedded use cases. The 6LoWPAN core 110 specifications are: 112 o [RFC4944], as updated by 114 o [I-D.ietf-6lowpan-hc] and 116 o [I-D.ietf-6lowpan-nd]. 118 While [RFC4944] defines 6LoWPAN specifically for IEEE 802.15.4 119 networks, 6LoWPAN concepts have been applied to other PHY/MAC layers. 121 6LoWPANs MAY use additional protocols, such as [I-D.ietf-roll-rpl] 122 for routing, or [I-D.ietf-core-coap] for application data transfer. 123 However, the "6LoWPANness" of a network is caused by adherence to the 124 core specifications. 126 3. 6LoWPAN MTU 128 IPv6 defines a minimal value for the "Minimum Transmission Unit", 129 MTU, of 1280 bytes. This means that every IPv6 network must be able 130 to transfer a packet of at least 1280 bytes of IPv6 headers and data 131 without requiring fragmentation. 133 A common Internet MTU is 1500 bytes (motivated by the Ethernet MTU). 134 The gap between 1280 and 1500 allows tunneling protocols to insert 135 headers on the way from the source of a packet to a destination 136 without breaking the overall MTU of the path. As various tunneling 137 protocols do indeed insert bytes, it is unwise to simply assume an 138 end-to-end MTU of 1500 bytes even with the current dominance of 139 Ethernet. Path MTU discovery [RFC1981] [RFC4821] has been defined to 140 enable transport protocols to find an MTU value better than 1280 141 bytes, but still reliably within the MTU of the path being used. 142 Path MTU discovery places, however, additional strain on constrained 143 nodes, which therefore may want to stick with an MTU of 1280 bytes 144 for all IPv6 applications. 146 6LoWPAN was designed as a stub network, not requiring any tunneling. 147 As IEEE 802.15.4 packets are rather small (127 bytes maximum at the 148 physical layer, minus MAC/security and adaptation layer overhead), 149 1280 bytes was already considered a somewhat large packet size. 150 Therefore, the 6LoWPAN network MTU was simply set at the minimum size 151 allowable by IPv6, 1280 bytes, although the 6LoWPAN fragmentation 152 mechanism is able to support packets with total lengths (including 153 the initial IPv6 header) of up to 2047 bytes. 155 As a more recent development, some modes of operation of the RPL 156 protocol [I-D.ietf-roll-rpl] do indeed operate by tunneling data 157 packets between RPL routers. Maintaining the MTU visible to 158 applications at 1280 therefore requires making a larger MTU available 159 to the tunnels. 161 6LoWPAN routers that employ RPL therefore MUST support a more 162 appropriate MTU between routers that make use of tunneling between 163 them. [The specific MTU value is TBD, to be chosen between 1280 and 164 2047 based on RPL considerations that need to be added to this 165 document.] 167 4. PAN identifiers in IPv6 addresses 169 [RFC4944] incorporates PAN identifiers in IPv6 addresses created from 170 16-bit MAC addresses, in a somewhat awkward way (one of the 16 bits 171 needs to be cleared to enable the U/L bit.). 173 As the use of PAN identifiers in 6LoWPAN networks has since become 174 less and less meaningful, [I-D.ietf-6lowpan-hc] provides specific 175 support only for interface IDs of the form 0000:00ff:fe00:XXXX, i.e. 176 PAN identifiers of zero. (Other forms can be supported by creating 177 sufficiently long pieces of compression context information for each 178 non-zero PAN identifier; however there is a limited number of context 179 elements and each consumes space in all nodes of a 6LoWPAN.) 181 It is therefore RECOMMENDED to employ a PAN identifier of zero with 182 6LoWPAN. 184 5. IANA Considerations 186 This document has no actions for IANA. 188 6. Security Considerations 190 (None so far; this section will certainly grow as additional security 191 considerations beyond those listed in the base specifications become 192 known.) 194 7. Acknowledgements 196 (The concept for this document is borrowed from [RFC4815], which was 197 invented by Lars-Erik Jonsson. Thanks!) 199 8. References 201 8.1. Normative References 203 [I-D.ietf-6lowpan-hc] 204 Hui, J. and P. Thubert, "Compression Format for IPv6 205 Datagrams in Low Power and Lossy Networks (6LoWPAN)", 206 draft-ietf-6lowpan-hc-15 (work in progress), 207 February 2011. 209 [I-D.ietf-6lowpan-nd] 210 Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor 211 Discovery Optimization for Low-power and Lossy Networks", 212 draft-ietf-6lowpan-nd-15 (work in progress), 213 December 2010. 215 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 216 Requirement Levels", BCP 14, RFC 2119, March 1997. 218 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 219 "Transmission of IPv6 Packets over IEEE 802.15.4 220 Networks", RFC 4944, September 2007. 222 8.2. Informative References 224 [I-D.ietf-core-coap] 225 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 226 "Constrained Application Protocol (CoAP)", 227 draft-ietf-core-coap-04 (work in progress), January 2011. 229 [I-D.ietf-roll-rpl] 230 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 231 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 232 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 233 Lossy Networks", draft-ietf-roll-rpl-18 (work in 234 progress), February 2011. 236 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 237 for IP version 6", RFC 1981, August 1996. 239 [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, 240 "RObust Header Compression (ROHC): Corrections and 241 Clarifications to RFC 3095", RFC 4815, February 2007. 243 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 244 Discovery", RFC 4821, March 2007. 246 Author's Address 248 Carsten Bormann 249 Universitaet Bremen TZI 250 Postfach 330440 251 Bremen D-28359 252 Germany 254 Phone: +49-421-218-63921 255 Fax: +49-421-218-7000 256 Email: cabo@tzi.org