idnits 2.17.1 draft-chairs-6lo-dispatch-iana-registry-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6282, but the abstract doesn't seem to directly say this. It does mention RFC6282 though, so this could be OK. -- The draft header indicates that this document updates RFC4944, but the abstract doesn't seem to directly say this. It does mention RFC4944 though, so this could be OK. 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 (October 19, 2015) is 3111 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 101, but not defined == Unused Reference: 'RFC5226' is defined on line 296, 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 (==), 6 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: April 21, 2016 R. Droms 7 Cisco 8 J. Woodyatt 9 Nest 10 October 19, 2015 12 IANA Registry for 6lowpan ESC Dispatch Code points 13 draft-chairs-6lo-dispatch-iana-registry-01 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. The purpose of this document is to 21 define the ESC extension byte code points and to request 22 corresponding IANA actions. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 21, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Usage of ESC dispatch bytes . . . . . . . . . . . . . . . . . . 3 61 3.1. Interaction with other RFC4944 implementations . . . . . . 4 62 3.2. ESC Extension Bytes Typical Sequence . . . . . . . . . . . 5 63 3.3. Example: ITU-T G.9903 ESC type usage . . . . . . . . . . . 5 64 3.4. NALP Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 70 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 73 1. Introduction 75 [RFC4944] section 5.1 defines the dispatch header and types. The ESC 76 type is defined for using additional dispatch bytes in the 6lowpan 77 header. RFC 6282 modifies the value of the ESC dispatch type and it 78 is recorded in IANA registry [6LOWPAN-IANA]. However, the bytes and 79 usage following the ESC byte are not defined in either [RFC4944] and 80 [RFC6282]. However, in recent years with 6lowpan deployments, the 81 implementations and Standards organizations have started using the 82 ESC extension bytes and a co-ordination between the respective 83 organizations and IETF/IANA are needed. 85 The following sections record the ITU-T specification for ESC 86 dispatch byte code points as an existing known usage and propose the 87 definition of ESC extension bytes for future applications. The 88 document also requests IANA actions for the first extension byte 89 following the ESC byte. 91 2. Terminology 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Usage of ESC dispatch bytes 99 RFC 4944 [RFC4944] first introduces this "ESC" dispatch header type 100 for extension of dispatch bytes. RFC 6282 [RFC6282] subsequently 101 modified its value to [01 000000]. 103 This document specifies that the first octet following the ESC byte 104 be used for extension type(extended dispatch values). Subsequent 105 octets are left unstructured for the specific use of the extension 106 type: 108 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 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 |0 1| ESC | ESC EXT Type | Extended Dispatch Payload 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 Figure 1: Frame Format with ESC Byte 115 ESC: The left-most byte is the ESC dispatch type containing '0100000' 116 ESC Extension Type(EET): It is the first byte following the ESC byte. 117 Extension type defines the payload for the additional dispatch bytes. 118 The values are from 0 to 255. Value 0 and 255 are reserved for 119 future use. These values are assigned by IANA. The EET values are 120 similar to dispatch values in the 6lowpan header except they are 121 preceeded by the ESC byte. Thus, ESC extension types and dispatch 122 values are using orthogonal code spaces. Though not desirable, 123 multiple ESC bytes MAY appear in a 6lowpan header. Section 3.1 124 describes how to handle unknown ESC dispatch type. 126 Extended Dispatch Payload(EDP): This part of frame format must be 127 defined by the corresponding extension type. A specification is 128 required to define each usage of extension type and its corresponding 129 Extension Payload. 131 Note that section 5.1 in RFC4944 indicates that the Extension Type 132 field may contain additional dispatch values larger than 63 133 [4944-ERRATA]. Note that the new dispatch type MUST NOT modify the 134 behavior of existing dispatch types for the sake of interoperability. 136 3.1. Interaction with other RFC4944 implementations 138 It is expected that RFC4944 existing implementations are not capable 139 of processing ESC extension data bytes as defined in this document. 140 However, implementors have to assume that existing implementation 141 that attempt to process an EET unknown to them will simply drop the 142 packet or ignore the ESC dispatch bytes. 144 If an implementation following this document, during processing of 145 the received packet reaches the ESC byte for which it does not 146 understand the extension bytes (EET), it MUST drop that packet. 147 However, it is important to clarify that a router node SHOULD forward 148 a 6lowpan packet with the EET bytes as long as it does not attempt to 149 process any ESC extension bytes. 151 Sequence Of dispatch bytes and ESC bytes: Multiple ESC extension 152 bytes may appear in a packet. Could a 6lowpan packet start with a 153 ESC dispatch type? In another word, should ESC extension always be 154 preceeded by non-ESC dispatch bytes? 156 gab: I think the answer is no. But per the previous sentence, you 157 have to assume that your packet will get dropped immediately by any 158 node that does not understand the EET at the beginning of the packet. 159 The closer to the end of the packet are the EET's, the higher chance 160 there is that a legacy node will recognize and successfully process 161 some dispatch type before the EET and then ignore the EET instead of 162 dropping the entire packet. Unless you know for sure that all nodes 163 in your network understand a given EET (by definition a private and 164 non-standard deployment), placing it at the beginning is a good way 165 to guarantee that the packet will get dropped. 167 3.2. ESC Extension Bytes Typical Sequence 169 The following diagram provides an example when ESC extension bytes 170 might be used: 172 A LoWPAN encapsulated HC1 compressed packet: 173 +----------+-----------------+---------+-----+-----+--------+ 174 | Dispatch | LOWPAN_IPHC hdr | Payld |ESC | EET |EPayld | 175 +----------------------------+---------+-----+-----+--------+ 177 A LoWPAN_IPHC Header, Mesh header and an ESC extenstion byte: 179 +-------+-------+--------+--------+-------+-----+-----+-------+ 180 | M Typ | M Hdr | LOWPAN_IPHC Hdr | Payld |ESC | EET | EPayld| 181 +-------+-------+--------+--------+-------+-----+-----+-------+ 183 Figure 2: A 6lowpan packet with ESC Bytes 185 3.3. Example: ITU-T G.9903 ESC type usage 187 [G3-PLC] provides native mesh-under functionalities. The ESC 188 dispatch type is used with the command frames specified in figure 189 9-12 and Table 9-35 in [G3-PLC] . The command ID values are 0x01 to 190 0x1F. 192 The frame format is defined as follows: 194 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 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |0 1| ESC | Command ID | Command Payload 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Figure 3: G.9903 Frame Format with ESC Byte 201 3.4. NALP Usage 203 There were several comments on 00 draft -- that this draft should 204 provide guidance on NALP usage as there was no clear distinction 205 between ITU-T command mode usage and NALP usage. In order to avaoid 206 such confusion, a NALP usage guidance should be provided. This is a 207 space holder section in order to decide whether NALP usage indeed 208 should belong here. 210 gab: I don't think we need to say anything beyond what we already say 211 in 4944: it is not a 6lowpan frame. This was done recognizing that 212 some SDO's would also define their own frame structure, in 213 particular, Zigbee. There was some effort to agree with them on some 214 way for our definitions to not collide. So prescribing usage of 215 NALP, beyond saying it is not 6lowpan nor the subject of any IETF 216 document, would defeat the purpose. 218 4. IANA Considerations 220 This document requests IANA to register the 'ESC Extension Type' 221 values as per the policy 'Specification Required'[RFC5226] as 222 specified in this document which follows the same policy as in the 223 IANA section of [RFC4944]. For each Extension Type(except the 224 Reserved values)the specification MUST define corresponding Extended 225 Dispatch Payload frame bytes for the receiver implementation to read 226 the ESC bytes with interoperability. 228 The initial values for the 'ESC Extension Type' fields are: 230 +-------+---------------------------------+---------------+ 231 | Value | Description | Reference | 232 +-------+---------------------------------+---------------+ 233 | 0 | Reserved for future use | This document | 234 | | | | 235 | 1-31 | Used by ITU-T G.9903 and G.9905 | ITU-T G.9903 &| 236 | | Command IDs | ITU-T G.9905 | 237 | | | | 238 | 32-254| Unassigned | This document | 239 | |(Reserved for future IANA | | 240 | | Assignment-- Spec Required) | | 241 | | | | 242 | 255 | Reserved for future use | This document | 243 +-------+---------------------------------+---------------+ 245 Figure 4: Initial Values for IANA Registry 247 5. Security Considerations 249 There is no additional security threats due to the assignments of ESC 250 byte usage described in this document. However, this document 251 forbids defining any extended dispatch values or extension types that 252 modifies the behavior of existing Dispatch types. 254 6. Acknowledgements 256 The authors would like to thank the members of the 6lo WG members for 257 the comments in the mailing list. Many thanks to Carsten Bormann, 258 Ralph Droms, Thierry Lys, Cedric Lavenu, Pascal Thubert for their 259 discussions regarding resolving the bits allocation issues which led 260 to this document. Jonathan Hui and Robert Cregie provided extensive 261 reviews and guidance for interoperability. The authors acknowledges 262 the comments from the following people for shaping this document: 263 Paul Duffy, Don Sturek, Michael Richardson, Xavier Vilajosana and 264 Scott Mansfield. 266 7. References 268 7.1. Normative References 270 [4944-ERRATA] 271 "https://www.rfc-editor.org/errata_search.php?rfc=4944". 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 275 RFC2119, March 1997, 276 . 278 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 279 "Transmission of IPv6 Packets over IEEE 802.15.4 280 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 281 . 283 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 284 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 285 DOI 10.17487/RFC6282, September 2011, 286 . 288 7.2. Informative References 290 [6LOWPAN-IANA] 291 "https://www.iana.org/assignments/_6lowpan-parameters/ 292 _6lowpan-parameters.xhtml". 294 [G3-PLC] "http://www.itu.int/rec/T-REC-G.9903-201402-I". 296 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 297 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 298 DOI 10.17487/RFC5226, May 2008, 299 . 301 Authors' Addresses 303 Samita Chakrabarti 304 Ericsson 305 300 Holger Way 306 San Jose, CA 307 US 309 Phone: +1 408 750 5843 310 Email: samita.chakrabarti@ericsson.com 312 Gabriel Montenegro 313 Microsoft 314 Seattle 315 US 317 Email: gabriel.montenegro@microsoft.com 319 Ralph Droms 320 Cisco 321 USA 323 Email: rdroms@cisco.com 325 James Woodyatt 326 Nest 327 Mountain View, CA 328 USA 330 Email: jhw@netstlabs.com