idnits 2.17.1 draft-ietf-6lo-dispatch-iana-registry-07.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 (Using the creation date from RFC4944, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 8, 2016) is 2689 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) == Missing Reference: '01 000000' is mentioned on line 102, but not defined == Unused Reference: '6loCHART' is defined on line 328, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '4944-ERRATA' -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo S. Chakrabarti 3 Internet-Draft 4 Updates: 4944, 6282 (if approved) G. Montenegro 5 Intended status: Standards Track Microsoft 6 Expires: June 11, 2017 R. Droms 8 J. Woodyatt 9 Google 10 December 8, 2016 12 6lowpan ESC Dispatch Code Points and Guidelines 13 draft-ietf-6lo-dispatch-iana-registry-07 15 Abstract 17 RFC4944 defines the ESC dispatch type to allow for additional 18 dispatch octets in the 6lowpan header. The value of the ESC dispatch 19 type was updated by RFC6282, however, its usage was not defined 20 either in RFC6282 or in RFC4944. This document updates RFC4944 and 21 RFC6282 by defining the ESC extension octet code points including 22 registration of entries for known use cases at the time of writing of 23 this document. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 11, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Usage of ESC dispatch octets . . . . . . . . . . . . . . . . . 3 62 3.1. Interaction with other RFC4944 implementations . . . . . . 4 63 3.2. ESC Extension Octets Typical Sequence . . . . . . . . . . . 5 64 3.3. ITU-T G.9903 ESC type usage . . . . . . . . . . . . . . . 6 65 3.4. NALP and ESC dispatch types . . . . . . . . . . . . . . . . 6 66 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 [RFC4944] section 5.1 defines the dispatch header and types. The ESC 77 type is defined for using additional dispatch octets in the 6lowpan 78 header. RFC 6282 modifies the value of the ESC dispatch type and 79 that value is recorded in IANA registry [6LOWPAN-IANA]. However, the 80 octets and usage following the ESC dispatch type are not defined in 81 either [RFC4944] and [RFC6282]. In recent years with 6lowpan 82 deployments, implementations and standards organizations have started 83 using the ESC extension octets. This highlights the need for an 84 updated IANA registration policy. 86 The following sections record the ITU-T specification for ESC 87 dispatch octet code points as an existing known usage and propose the 88 definition of ESC extension octets for future applications. The 89 document also requests IANA actions for the first extension octet 90 following the ESC dispatch type. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Usage of ESC dispatch octets 100 RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type 101 for extension of dispatch octets. RFC 6282 [RFC6282] subsequently 102 modified its value to [01 000000]. 104 This document specifies that the first octet following the ESC 105 dispatch type be used for extension type (extended dispatch values). 106 Subsequent octets are left unstructured for the specific use of the 107 extension type: 109 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 | ESC | ESC EXT Type | Extended Dispatch Payload 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Figure 1: Frame Format with ESC dispatch type 116 ESC: The left-most octet is the ESC dispatch type containing 117 '01000000' 119 ESC Extension Type (EET): It is the first octet following the ESC 120 dispatch type. Extension type defines the payload for the additional 121 dispatch octets. The values are from 0 to 255. Values 0 and 255 are 122 reserved for future use. The remaining values from 1 to 254 are 123 assigned by IANA. The EET values are similar to dispatch values in 124 the 6lowpan header except they are preceded by the ESC dispatch type. 125 Thus, ESC extension types and dispatch values are using orthogonal 126 code spaces. Though not desirable, multiple ESC dispatch types MAY 127 appear in a 6lowpan header. Section 3.1 describes how to handle an 128 unknown ESC dispatch type. 130 Extended Dispatch Payload (EDP): This part of the frame format must 131 be defined by the corresponding extension type. A specification is 132 required to define each usage of extension type and its corresponding 133 Extension Payload. For the sake of interoperability, specifications 134 of extension octets MUST NOT redefine the existing ESC Extension Type 135 codes. 137 Section 5.1 in RFC4944 indicates that the Extension Type field may 138 contain additional dispatch values larger than 63, as corrected by 139 [4944-ERRATA]. For the sake of interoperability, the new dispatch 140 type (EET) MUST NOT modify the behavior of existing dispatch types 141 [RFC4944]. 143 3.1. Interaction with other RFC4944 implementations 145 It is expected that existing implementations of RFC4944 are not 146 capable of processing ESC extension data octets as defined in this 147 document. However, implementers have to assume that existing 148 implementation that attempt to process an EET unknown to them will 149 simply drop the packet or ignore the ESC dispatch octets. 151 If an implementation following this document, during processing of 152 the received packet reaches an ESC dispatch type for which it does 153 not understand the extension octets (EET), it MUST drop that packet. 154 However, it is important to clarify that a router node SHOULD forward 155 a 6lowpan packet with the EET octets as long as it does not attempt 156 to process any unknown ESC extension octets. 158 Multiple ESC extension octets may appear in a packet. The ESC 159 dispatch types can appear as the first, last or middle dispatch 160 octets. However, a packet will get dropped by any node that does not 161 understand the EET at the beginning of the packet. Placing an EET 162 toward the front of the packet has a greater probability of causing 163 the packet to be dropped than placing the same EET later in the 164 packet. Placement of an EET later in the packet increases the chance 165 that a legacy device will recognize and successfully process some 166 dispatch type [RFC4944] before the EET. In this case, the legacy 167 device will ignore the EET instead of dropping the entire packet. 169 3.2. ESC Extension Octets Typical Sequence 171 ESC Extension octets sequence and order with respect to 6LoWPAN Mesh 172 header and LoWPAN_IPHC header are described below. When LOWPAN_IPHC 173 dispatch type is present, ESC dispatch types MUST appear before the 174 LOWPAN_IPHC dispatch type in order to maintain backward compatibility 175 with RFC6282 section 3.2. The following diagrams provide examples of 176 ESC extension octet usages: 178 A LoWPAN encapsulated IPv6 Header compressed packet: 180 +-------+------+--------+--------+-----------------+--------+ 181 | ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payld | 182 +-------+------+--------+--------+-----------------+--------+ 184 A LoWPAN_IPHC Header, Mesh header and an ESC extension octet: 186 +-----+-----+-----+----+------+-------+---------------+------+ 187 |M typ| Mhdr| ESC | EET|EDP |Disptch|LOWPAN_IPHC hdr| Payld| 188 +-----+-----+-----+----+------+-------+---------------+------+ 190 A Mesh header with ESC dispatch types 191 +-------+-------+-----+-----+-------+ 192 | M Typ | M Hdr | ESC | EET |EDP | 193 +-------+-------+-----+-----+-------+ 195 With Fragment header 197 +-------+-------+--------+------+-----+-----+-------+ 198 | M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP | 199 +-------+-------+--------+------+-----+-----+-------+ 201 ESC dispatch type as a LowPAN encapsulation 203 +--------+--------+--------+ 204 | ESC | EET | EDP | 205 +--------+--------+--------+ 207 Figure 2: A 6lowpan packet with ESC dispatch types 209 3.3. ITU-T G.9903 ESC type usage 211 The ESC dispatch type is used in [G3-PLC] to provide native mesh 212 routing and bootstrapping functionalities. The ITU-T recommendation 213 [G3-PLC] section 9.4.2.3 defines commands which are formatted like 214 ESC Extension type fields. The command ID values are 0x01 to 0x1F. 216 The frame format is defined as follows: 218 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 |0 1| ESC | Command ID | Command Payload 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 3: G.9903 Frame Format with ESC dispatch type 225 3.4. NALP and ESC dispatch types 227 According to RFC4944 [RFC4944] section 5.1, NALP dispatch octets are 228 reserved for use as a kind of escape code for identification of non- 229 6lowpan payloads. Since ESC dispatch types are part of 6lowpan 230 dispatch types (extended), they are orthogonal to NALP octets. 232 This document clarifies that NALP dispatch codes only provide an 233 escape method for non-6LoWPAN payloads when they appear as the 234 initial octet of a LoWPAN encapsulation, and that the potential 235 meaning of their appearance in any other location is reserved for 236 future use. 238 4. IANA Considerations 240 This document requests IANA to register the 'ESC Extension Type' 241 values per the policy 'Specification Required' [RFC5226], following 242 the same policy as in the IANA Considerations section of [RFC4944]. 243 For each Extension Type (except the Reserved values) the 244 specification MUST define corresponding Extended Dispatch Payload 245 frame octets for the receiver implementation to read the ESC dispatch 246 types in an interoperable fashion. 248 [RFC5226] section 4.1 also indicates that "Specification Required" 249 calls for a Designated Expert review of the public specification 250 requesting registration of the ESC Extension Type values. 252 The allocation of code points should follow the guidelines on "Usage 253 of ESC dispatch octets" and the typical example sections. ESC 254 Extension type code points MUST be used in conjunction with 6lo 255 protocols following [RFC4944] or its derivatives. The requesting 256 document MUST specify how the ESC dispatch octets will be used along 257 with 6LOWPAN headers in their use cases. 259 The initial values for the 'ESC Extension Type' fields are: 261 +-------+---------------------------------+---------------+ 262 | Value | Description | Reference | 263 +-------+---------------------------------+---------------+ 264 | 0 | Reserved for future use | This document | 265 | | | | 266 | 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &| 267 | | Command IDs | ITU-T G.9905 | 268 | | | | 269 | 32-254| Unassigned | This document | 270 | |(Reserved for future IANA | | 271 | | Assignment-- Spec Required) | | 272 | | | | 273 | 255 | Reserved for future use | This document | 274 +-------+---------------------------------+---------------+ 276 Figure 4: Initial Values for IANA Registry 278 5. Security Considerations 280 There are no additional security threats due to the assignments of 281 ESC dispatch type usage described in this document. Furthermore, 282 this document forbids defining any extended dispatch values or 283 extension types that modify the behavior of existing Dispatch types. 285 6. Acknowledgements 287 The authors would like to thank the members of the 6lo WG for their 288 comments. Many thanks to Carsten Bormann, Ralph Droms, Thierry Lys, 289 Cedric Lavenu, Pascal Thubert for discussions regarding the bits 290 allocation issues, which led to this document. Jonathan Hui and 291 Robert Cragie provided extensive reviews and guidance for 292 interoperability. The authors acknowledge the comments from the 293 following people that helped shape this document: Paul Duffy, Don 294 Sturek, Michael Richardson, Xavier Vilajosana, Scott Mansfield, Dale 295 Worley and Russ Housley. Thanks to Brian Haberman, our document 296 shepherd, for guidance in the IANA Considerations section. 298 This document was produced using the xml2rfc tool. 300 7. References 302 7.1. Normative References 304 [4944-ERRATA] 305 "https://www.rfc-editor.org/errata_search.php?rfc=4944". 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 309 RFC2119, March 1997, 310 . 312 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 313 "Transmission of IPv6 Packets over IEEE 802.15.4 314 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 315 . 317 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 318 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 319 DOI 10.17487/RFC6282, September 2011, 320 . 322 7.2. Informative References 324 [6LOWPAN-IANA] 325 "https://www.iana.org/assignments/_6lowpan-parameters/ 326 _6lowpan-parameters.xhtml". 328 [6loCHART] 329 "https://datatracker.ietf.org/wg/6lo/charter". 331 [G3-PLC] "http://www.itu.int/rec/T-REC-G.9903-201402-I". 333 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 334 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 335 DOI 10.17487/RFC5226, May 2008, 336 . 338 Authors' Addresses 340 Samita Chakrabarti 341 San Jose, CA 342 USA 344 Email: samitac.ietf@gmail.com 346 Gabriel Montenegro 347 Microsoft 348 USA 350 Email: gabriel.montenegro@microsoft.com 352 Ralph Droms 353 USA 355 Email: rdroms.ietf@gmail.com 357 James Woodyatt 358 Google 359 Mountain View, CA 360 USA 362 Email: jhw@google.com