idnits 2.17.00 (12 Aug 2021) /tmp/idnits30864/draft-ietf-6lo-dispatch-iana-registry-05.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 (September 16, 2016) is 2073 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 100, but not defined == Unused Reference: '6loCHART' is defined on line 319, 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. -------------------------------------------------------------------------------- 1 6lo S. Chakrabarti 2 Internet-Draft Ericsson 3 Updates: 4944, 6282 (if approved) G. Montenegro 4 Intended status: Standards Track Microsoft 5 Expires: March 20, 2017 R. Droms 6 Cisco 7 J. Woodyatt 8 Nest 9 September 16, 2016 11 6lowpan ESC Dispatch Code Points and Guidelines 12 draft-ietf-6lo-dispatch-iana-registry-05 14 Abstract 16 RFC4944 defines the ESC dispatch type to allow for additional 17 dispatch bytes in the 6lowpan header. The value of the ESC byte was 18 updated by RFC6282, however, its usage was not defined either in 19 RFC6282 or in RFC4944. This document updates RFC4944 and RFC6282 by 20 defining the ESC extension byte code points including registration of 21 entries for known use cases at the time of writing of this document. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on March 20, 2017. 40 Copyright Notice 42 Copyright (c) 2016 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Usage of ESC dispatch bytes . . . . . . . . . . . . . . . . . . 3 60 3.1. Interaction with other RFC4944 implementations . . . . . . 4 61 3.2. ESC Extension Bytes Typical Sequence . . . . . . . . . . . 5 62 3.3. ITU-T G.9903 ESC type usage . . . . . . . . . . . . . . . 5 63 3.4. NALP and ESC bytes . . . . . . . . . . . . . . . . . . . . 6 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 66 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 [RFC4944] section 5.1 defines the dispatch header and types. The ESC 75 type is defined for using additional dispatch bytes in the 6lowpan 76 header. RFC 6282 modifies the value of the ESC dispatch type and it 77 is recorded in IANA registry [6LOWPAN-IANA]. However, the bytes and 78 usage following the ESC byte are not defined in either [RFC4944] and 79 [RFC6282]. However, in recent years with 6lowpan deployments, 80 implementations and standards organizations have started using the 81 ESC extension bytes and co-ordination between the respective 82 organizations and IETF/IANA is needed. 84 The following sections record the ITU-T specification for ESC 85 dispatch byte code points as an existing known usage and propose the 86 definition of ESC extension bytes for future applications. The 87 document also requests IANA actions for the first extension byte 88 following the ESC byte. 90 2. Terminology 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. Usage of ESC dispatch bytes 98 RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type 99 for extension of dispatch bytes. RFC 6282 [RFC6282] subsequently 100 modified its value to [01 000000]. 102 This document specifies that the first octet following the ESC byte 103 be used for extension type (extended dispatch values). Subsequent 104 octets are left unstructured for the specific use of the extension 105 type: 107 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 108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 109 |0 1| ESC | ESC EXT Type | Extended Dispatch Payload 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 112 Figure 1: Frame Format with ESC Byte 114 ESC: The left-most byte is the ESC dispatch type containing '0100000' 115 ESC Extension Type (EET): It is the first byte following the ESC 116 byte. Extension type defines the payload for the additional dispatch 117 bytes. The values are from 0 to 255. Values 0 and 255 are reserved 118 for future use. These values are assigned by IANA. The EET values 119 are similar to dispatch values in the 6lowpan header except they are 120 preceded by the ESC byte. Thus, ESC extension types and dispatch 121 values are using orthogonal code spaces. Though not desirable, 122 multiple ESC bytes MAY appear in a 6lowpan header. Section 3.1 123 describes how to handle an unknown ESC dispatch type. 125 Extended Dispatch Payload(EDP): This part of the frame format must be 126 defined by the corresponding extension type. A specification is 127 required to define each usage of extension type and its corresponding 128 Extension Payload. For the sake of interoperability, specifications 129 of extension bytes MUST NOT redefine the existing ESC Extension Type 130 codes. 132 Section 5.1 in RFC4944 indicates that the Extension Type field may 133 contain additional dispatch values larger than 63, as corrected by 134 [4944-ERRATA]. For the sake of interoperability, the new dispatch 135 type (EET) MUST NOT modify the behavior of existing dispatch types 136 [RFC4944]. 138 3.1. Interaction with other RFC4944 implementations 140 It is expected that RFC4944 existing implementations are not capable 141 of processing ESC extension data bytes as defined in this document. 142 However, implementers have to assume that existing implementation 143 that attempt to process an EET unknown to them will simply drop the 144 packet or ignore the ESC dispatch bytes. 146 If an implementation following this document, during processing of 147 the received packet reaches an ESC byte for which it does not 148 understand the extension bytes (EET), it MUST drop that packet. 149 However, it is important to clarify that a router node SHOULD forward 150 a 6lowpan packet with the EET bytes as long as it does not attempt to 151 process any unknown ESC extension bytes. 153 Sequence Of dispatch bytes and ESC bytes: Multiple ESC extension 154 bytes may appear in a packet. The ESC bytes can appear as the first, 155 last or middle dispatch bytes. However, a packet will get dropped by 156 any node that does not understand the EET at the beginning of the 157 packet. The closer to the end of the packet are the EET's, the 158 higher chance there is that a legacy node will recognize and 159 successfully process some dispatch type [RFC4944] before the EET and 160 then ignore the EET instead of dropping the entire packet. 162 3.2. ESC Extension Bytes Typical Sequence 164 ESC Extension bytes sequence and order with respect to 6LoWPAN Mesh 165 header and LoWPAN_IPHC header are described below. When LOWPAN_IPHC 166 dispatch type is present, ESC bytes MUST appear before the 167 LOWPAN_IPHC dispatch type in order to maintain backward compatibility 168 with RFC6282 section 3.2. The following diagrams provide examples of 169 ESC extension byte usages: 171 A LoWPAN encapsulated IPv6 Header compressed packet: 173 +-------+------+--------+--------+-----------------+--------+ 174 | ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payld | 175 +-------+------+--------+--------+-----------------+--------+ 177 A LoWPAN_IPHC Header, Mesh header and an ESC extension byte: 179 +-----+-----+-----+----+------+-------+---------------+------+ 180 |M typ| Mhdr| ESC | EET|EDP |Disptch|LOWPAN_IPHC hdr| Payld| 181 +-----+-----+-----+----+------+-------+---------------+------+ 183 A Mesh header with ESC bytes 184 +-------+-------+-----+-----+-------+ 185 | M Typ | M Hdr | ESC | EET |EDP | 186 +-------+-------+-----+-----+-------+ 188 With Fragment header 190 +-------+-------+--------+------+-----+-----+-------+ 191 | M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP | 192 +-------+-------+--------+------+-----+-----+-------+ 194 ESC byte as a LowPAN encapsulation 196 +--------+--------+--------+ 197 | ESC | EET | EDP | 198 +--------+--------+--------+ 200 Figure 2: A 6lowpan packet with ESC Bytes 202 3.3. ITU-T G.9903 ESC type usage 204 The ESC dispatch type is used in [G3-PLC] to provide native mesh 205 routing and bootstrapping functionalities. The ITU-T recommendation 206 defines command IDs in the [G3-PLC] section 9.4.2.3 which operates 207 like ESC Extension type field. The command ID values are 0x01 to 208 0x1F. 210 The frame format is defined as follows: 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |0 1| ESC | Command ID | Command Payload 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 3: G.9903 Frame Format with ESC Byte 219 3.4. NALP and ESC bytes 221 According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are 222 reserved for use as a kind of escape code for identification of non- 223 6lowpan payloads. Since ESC bytes are part of 6lowpan dispatch types 224 (extended), they are orthogonal to NALP bytes. 226 This document clarifies that NALP dispatch codes only provide an 227 escape method for non-6LoWPAN payloads when they appear as the 228 initial byte of a LoWPAN encapsulation, and that the potential 229 meaning of their appearance in any other location is reserved for 230 future use. 232 4. IANA Considerations 234 This document requests IANA to register the 'ESC Extension Type' 235 values per the policy 'Specification Required' [RFC5226], following 236 the same policy as in the IANA section of [RFC4944]. For each 237 Extension Type (except the Reserved values) the specification MUST 238 define corresponding Extended Dispatch Payload frame bytes for the 239 receiver implementation to read the ESC bytes in an interoperable 240 fashion. 242 [RFC5226] section 4.1 also indicates that "Specification Required" 243 implies a Designated Expert review of the public specification 244 requesting registration of the ESC Extension Type values. 246 The allocation of code points should follow the guidelines on "Usage 247 Of ESC Dispatch Bytes" and the typical example sections. ESC 248 Extension type code points MUST be used in conjunction with 6lo 249 protocols following [RFC4944] or its derivatives. The requesting 250 document MUST specify how the ESC dispatch bytes will be used along 251 with 6LOWPAN headers in their use cases. 253 The initial values for the 'ESC Extension Type' fields are: 255 +-------+---------------------------------+---------------+ 256 | Value | Description | Reference | 257 +-------+---------------------------------+---------------+ 258 | 0 | Reserved for future use | This document | 259 | | | | 260 | 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &| 261 | | Command IDs | ITU-T G.9905 | 262 | | | | 263 | 32-254| Unassigned | This document | 264 | |(Reserved for future IANA | | 265 | | Assignment-- Spec Required) | | 266 | | | | 267 | 255 | Reserved for future use | This document | 268 +-------+---------------------------------+---------------+ 270 Figure 4: Initial Values for IANA Registry 272 5. Security Considerations 274 There are no additional security threats due to the assignments of 275 ESC byte usage described in this document. Furthermore, this 276 document forbids defining any extended dispatch values or extension 277 types that modify the behavior of existing Dispatch types. 279 6. Acknowledgements 281 The authors would like to thank the members of the 6lo WG for their 282 comments. Many thanks to Carsten Bormann, Ralph Droms, Thierry Lys, 283 Cedric Lavenu, Pascal Thubert for discussions regarding the bits 284 allocation issues, which led to this document. Jonathan Hui and 285 Robert Cragie provided extensive reviews and guidance for 286 interoperability. The authors acknowledge the comments from the 287 following people that helped shape this document: Paul Duffy, Don 288 Sturek, Michael Richardson, Xavier Vilajosana and Scott Mansfield. 289 Thanks to Brian Haberman, our document shepherd, for guidance in the 290 IANA section. 292 7. References 293 7.1. Normative References 295 [4944-ERRATA] 296 "https://www.rfc-editor.org/errata_search.php?rfc=4944". 298 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 299 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 300 RFC2119, March 1997, 301 . 303 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 304 "Transmission of IPv6 Packets over IEEE 802.15.4 305 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 306 . 308 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 309 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 310 DOI 10.17487/RFC6282, September 2011, 311 . 313 7.2. Informative References 315 [6LOWPAN-IANA] 316 "https://www.iana.org/assignments/_6lowpan-parameters/ 317 _6lowpan-parameters.xhtml". 319 [6loCHART] 320 "https://datatracker.ietf.org/wg/6lo/charter". 322 [G3-PLC] "http://www.itu.int/rec/T-REC-G.9903-201402-I". 324 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 325 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 326 DOI 10.17487/RFC5226, May 2008, 327 . 329 Authors' Addresses 331 Samita Chakrabarti 332 Ericsson 333 300 Holger Way 334 San Jose, CA 335 USA 337 Email: samitac.ietf@gmail.com 338 Gabriel Montenegro 339 Microsoft 340 USA 342 Email: gabriel.montenegro@microsoft.com 344 Ralph Droms 345 Cisco 346 USA 348 Email: rdroms.ietf@gmail.com 350 James Woodyatt 351 Nest 352 Mountain View, CA 353 USA 355 Email: jhw@netstlabs.com