idnits 2.17.00 (12 Aug 2021) /tmp/idnits30284/draft-ietf-6lo-dispatch-iana-registry-04.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 (August 8, 2016) is 2112 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 321, 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 Ericsson 4 Updates: 4944, 6282 (if approved) G. Montenegro 5 Intended status: Standards Track Microsoft 6 Expires: February 9, 2017 R. Droms 7 Cisco 8 J. Woodyatt 9 Nest 10 August 8, 2016 12 6lowpan ESC Dispatch Code Points and Guidelines 13 draft-ietf-6lo-dispatch-iana-registry-04 15 Abstract 17 RFC4944 defines ESC dispatch type for additional dispatch bytes in 18 the 6lowpan header. The value of ESC byte has been updated by 19 RFC6282. However, the usage of ESC extension byte has not been 20 defined in RFC6282 and RFC4944. This document updates RFC4944 and 21 RFC6282 by defining the ESC extension byte 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 February 9, 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 bytes . . . . . . . . . . . . . . . . . . 3 62 3.1. Interaction with other RFC4944 implementations . . . . . . 4 63 3.2. ESC Extension Bytes Typical Sequence . . . . . . . . . . . 5 64 3.3. ITU-T G.9903 ESC type usage . . . . . . . . . . . . . . . 5 65 3.4. NALP and ESC bytes . . . . . . . . . . . . . . . . . . . . 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 bytes in the 6lowpan 78 header. RFC 6282 modifies the value of the ESC dispatch type and it 79 is recorded in IANA registry [6LOWPAN-IANA]. However, the bytes and 80 usage following the ESC byte are not defined in either [RFC4944] and 81 [RFC6282]. However, in recent years with 6lowpan deployments, the 82 implementations and Standards organizations have started using the 83 ESC extension bytes and a co-ordination between the respective 84 organizations and IETF/IANA are needed. 86 The following sections record the ITU-T specification for ESC 87 dispatch byte code points as an existing known usage and propose the 88 definition of ESC extension bytes for future applications. The 89 document also requests IANA actions for the first extension byte 90 following the ESC byte. 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 bytes 100 RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type 101 for extension of dispatch bytes. RFC 6282 [RFC6282] subsequently 102 modified its value to [01 000000]. 104 This document specifies that the first octet following the ESC byte 105 be used for extension type (extended dispatch values). Subsequent 106 octets are left unstructured for the specific use of the extension 107 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 |0 1| ESC | ESC EXT Type | Extended Dispatch Payload 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 114 Figure 1: Frame Format with ESC Byte 116 ESC: The left-most byte is the ESC dispatch type containing '0100000' 117 ESC Extension Type (EET): It is the first byte following the ESC 118 byte. Extension type defines the payload for the additional dispatch 119 bytes. The values are from 0 to 255. Value 0 and 255 are reserved 120 for future use. These values are assigned by IANA. The EET values 121 are similar to dispatch values in the 6lowpan header except they are 122 preceded by the ESC byte. Thus, ESC extension types and dispatch 123 values are using orthogonal code spaces. Though not desirable, 124 multiple ESC bytes MAY appear in a 6lowpan header. Section 3.1 125 describes how to handle unknown ESC dispatch type. 127 Extended Dispatch Payload(EDP): This part of frame format must be 128 defined by the corresponding extension type. A specification is 129 required to define each usage of extension type and its corresponding 130 Extension Payload. For the sake of interoperability, specifications 131 of extension bytes MUST NOT redefine the existing ESC Extension Type 132 codes. 134 Section 5.1 in RFC4944 indicates that the Extension Type field may 135 contain additional dispatch values larger than 63, as corrected by 136 [4944-ERRATA]. For the sake of interoperability, the new dispatch 137 type (EET) MUST NOT modify the behavior of existing dispatch types 138 [RFC4944]. 140 3.1. Interaction with other RFC4944 implementations 142 It is expected that RFC4944 existing implementations are not capable 143 of processing ESC extension data bytes as defined in this document. 144 However, implementers have to assume that existing implementation 145 that attempt to process an EET unknown to them will simply drop the 146 packet or ignore the ESC dispatch bytes. 148 If an implementation following this document, during processing of 149 the received packet reaches the ESC byte for which it does not 150 understand the extension bytes (EET), it MUST drop that packet. 151 However, it is important to clarify that a router node SHOULD forward 152 a 6lowpan packet with the EET bytes as long as it does not attempt to 153 process any unknown ESC extension bytes. 155 Sequence Of dispatch bytes and ESC bytes: Multiple ESC extension 156 bytes may appear in a packet. The ESC bytes can appear as the first, 157 last or middle dispatch bytes. However, a packet will get dropped by 158 any node that does not understand the EET at the beginning of the 159 packet. The closer to the end of the packet are the EET's, the 160 higher chance there is that a legacy node will recognize and 161 successfully process some dispatch type [RFC4944] before the EET and 162 then ignore the EET instead of dropping the entire packet. 164 3.2. ESC Extension Bytes Typical Sequence 166 ESC Extension bytes sequence and order with respect to 6LoWPAN Mesh 167 header and LoWPAN_IPHC header are described below. When LOWPAN_IPHC 168 dispatch type is present, ESC bytes MUST appear before the 169 LOWPAN_IPHC dispatch type in order to maintain backward compatibility 170 with RFC6282 section 3.2. The following diagrams provide examples of 171 ESC extension byte usages: 173 A LoWPAN encapsulated IPv6 Header compressed packet: 175 +-------+------+--------+--------+-----------------+--------+ 176 | ESC | EET | EDP |Dispatch| LOWPAN_IPHC hdr | Payld | 177 +-------+------+--------+--------+-----------------+--------+ 179 A LoWPAN_IPHC Header, Mesh header and an ESC extension byte: 181 +-----+-----+-----+----+------+-------+---------------+------+ 182 |M typ| Mhdr| ESC | EET|EDP |Disptch|LOWPAN_IPHC hdr| Payld| 183 +-----+-----+-----+----+------+-------+---------------+------+ 185 A Mesh header with ESC bytes 186 +-------+-------+-----+-----+-------+ 187 | M Typ | M Hdr | ESC | EET |EDP | 188 +-------+-------+-----+-----+-------+ 190 With Fragment header 192 +-------+-------+--------+------+-----+-----+-------+ 193 | M Typ | M Hdr | F Typ | F hdr|ESC | EET | EDP | 194 +-------+-------+--------+------+-----+-----+-------+ 196 ESC byte as a LowPAN encapsulation 198 +--------+--------+--------+ 199 | ESC | EET | EDP | 200 +--------+--------+--------+ 202 Figure 2: A 6lowpan packet with ESC Bytes 204 3.3. ITU-T G.9903 ESC type usage 206 The ESC dispatch type is used in [G3-PLC] to provide native mesh 207 routing and bootstrapping functionalities. The ITU-T recommendation 208 defines command IDs in the [G3-PLC] section 9.4.2.3 which operates 209 like ESC Extension type field. The command ID values are 0x01 to 210 0x1F. 212 The frame format is defined as follows: 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 |0 1| ESC | Command ID | Command Payload 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 3: G.9903 Frame Format with ESC Byte 221 3.4. NALP and ESC bytes 223 According to RFC4944 [RFC4944] section 5.1, NALP dispatch bytes are 224 reserved for use as a kind of escape code for identification of non- 225 6lowpan payloads. Since ESC bytes are part of 6lowpan dispatch types 226 (extended), they are orthogonal to NALP bytes. 228 This document clarifies that NALP dispatch codes only provide an 229 escape method for non-6LoWPAN payloads when they appear as the 230 initial byte of a LoWPAN encapsulation, and that the potential 231 meaning of their appearance in any other location is reserved for 232 future use. 234 4. IANA Considerations 236 This document requests IANA to register the 'ESC Extension Type' 237 values as per the policy 'Specification Required'[RFC5226] as 238 specified in this document which follows the same policy as in the 239 IANA section of [RFC4944]. For each Extension Type (except the 240 Reserved values) the specification MUST define corresponding Extended 241 Dispatch Payload frame bytes for the receiver implementation to read 242 the ESC bytes with interoperability. 244 [RFC5226] section 4.1 also indicates that "Specification Srequired" 245 implies a Designated expert review of the public specification which 246 is requesting registry for the ESC Extenstion Type values. 248 The allocation of code-points should follow the guidelines on "Usage 249 Of ESC Dispatch Bytes" and the typical example sections. ESC 250 Extension type code points MUST be used in conjunction with 6lo 251 protocols following [RFC4944] or its derivatives. The requesting 252 document MUST specify how the ESC dispatch bytes will be used along 253 with 6LOWPAN headers in their use-cases. 255 The initial values for the 'ESC Extension Type' fields are: 257 +-------+---------------------------------+---------------+ 258 | Value | Description | Reference | 259 +-------+---------------------------------+---------------+ 260 | 0 | Reserved for future use | This document | 261 | | | | 262 | 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &| 263 | | Command IDs | ITU-T G.9905 | 264 | | | | 265 | 32-254| Unassigned | This document | 266 | |(Reserved for future IANA | | 267 | | Assignment-- Spec Required) | | 268 | | | | 269 | 255 | Reserved for future use | This document | 270 +-------+---------------------------------+---------------+ 272 Figure 4: Initial Values for IANA Registry 274 5. Security Considerations 276 There is no additional security threats due to the assignments of ESC 277 byte usage described in this document. However, this document 278 forbids defining any extended dispatch values or extension types that 279 modifies the behavior of existing Dispatch types. 281 6. Acknowledgements 283 The authors would like to thank the members of the 6lo WG members for 284 the comments in the mailing list. Many thanks to Carsten Bormann, 285 Ralph Droms, Thierry Lys, Cedric Lavenu, Pascal Thubert for their 286 discussions regarding resolving the bits allocation issues which led 287 to this document. Jonathan Hui and Robert Cregie provided extensive 288 reviews and guidance for interoperability. The authors acknowledges 289 the comments from the following people for shaping this document: 290 Paul Duffy, Don Sturek, Michael Richardson, Xavier Vilajosana and 291 Scott Mansfield. Brian Haberman, our document shepherd helped us 292 modify the IANA section for guideline. 294 7. References 295 7.1. Normative References 297 [4944-ERRATA] 298 "https://www.rfc-editor.org/errata_search.php?rfc=4944". 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 302 RFC2119, March 1997, 303 . 305 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 306 "Transmission of IPv6 Packets over IEEE 802.15.4 307 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 308 . 310 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 311 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 312 DOI 10.17487/RFC6282, September 2011, 313 . 315 7.2. Informative References 317 [6LOWPAN-IANA] 318 "https://www.iana.org/assignments/_6lowpan-parameters/ 319 _6lowpan-parameters.xhtml". 321 [6loCHART] 322 "https://datatracker.ietf.org/wg/6lo/charter". 324 [G3-PLC] "http://www.itu.int/rec/T-REC-G.9903-201402-I". 326 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 327 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 328 DOI 10.17487/RFC5226, May 2008, 329 . 331 Authors' Addresses 333 Samita Chakrabarti 334 Ericsson 335 300 Holger Way 336 San Jose, CA 337 US 339 Email: samita.chakrabarti@ericsson.com 340 Gabriel Montenegro 341 Microsoft 342 Seattle 343 US 345 Email: gabriel.montenegro@microsoft.com 347 Ralph Droms 348 Cisco 349 USA 351 Email: rdroms@cisco.com 353 James Woodyatt 354 Nest 355 Mountain View, CA 356 USA 358 Email: jhw@netstlabs.com