idnits 2.17.1 draft-herbert-6man-exp-opts-02.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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 180: '...public Internet, MUST use ExIDs as des...' RFC 2119 keyword, line 181: '...scribed in this document MUST register...' RFC 2119 keyword, line 198: '... priority. ExIDs MUST be unique. It is...' RFC 2119 keyword, line 201: '...ID value of 0x0 is reserved and MAY be...' RFC 2119 keyword, line 235: '...termediate nodes MUST NOT modify an ex...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 21, 2019) is 1709 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2119' is mentioned on line 150, but not defined == Missing Reference: 'RFC8174' is mentioned on line 150, but not defined == Missing Reference: 'RFC5226' is mentioned on line 319, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Proposed Standard RFC: RFC 4727 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT T. Herbert 3 Intended Status: Standard Quantonium 4 Expires: February 2020 6 August 21, 2019 8 Shared Use of Experimental Hop-by-Hop and Destination Options 9 draft-herbert-6man-exp-opts-02 11 Abstract 13 This document describes how the experimental IPv6 Hop-by-Hop and 14 Destinations Option types can concurrently support different 15 experimental options. This is accomplished by employing a format in 16 the Option Data for experimental option types. The format contains an 17 experiment identifier that indicates an experimental option contained 18 in the trailing Option Data. This approach is robust to experiments 19 that are not registered and to those that do not use this sharing 20 mechanism. It is recommended for all new Destination and Hop-by-Hop 21 options that use experimental codepoints. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2 Requirements Language . . . . . . . . . . . . . . . . . . . . . 4 63 3 Hop-by-Hop and Destination Experimental Option Format . . . . . 4 64 3.1 Selecting an ExID . . . . . . . . . . . . . . . . . . . . . 5 65 3.2 Impact on Option Processing . . . . . . . . . . . . . . . . 6 66 3.3 Interaction with the Authentication Header . . . . . . . . . 6 67 4 Reducing the Impact of False Positives . . . . . . . . . . . . 7 68 5 Migration to Assigned Options . . . . . . . . . . . . . . . . . 7 69 6 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 7 71 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 72 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 9.1 Normative References . . . . . . . . . . . . . . . . . . . 9 74 9.2 Informative References . . . . . . . . . . . . . . . . . . 9 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 1 Introduction 79 IPv6 Hop-by-Hop and Destination Options extension headers contain 80 lists of TLV (Type-Length-Value) options as the means to extend the 81 IPv6 protocol and to enable new protocol capabilities [RFC8200]. This 82 document describes how the experimental IPv6 Hop-by-Hop and 83 Destinations Option experimental types can concurrently support 84 different experimental options. 86 The space for identifying Hop-by-Hop and Destination options is 87 small. An Option Type is eight bits, however the three high order 88 bits are defined by [RFC8200] to hold a directive on what processing 89 is to be done if the option is not recognized ("act" bits), as well 90 as an indication of whether the Option Data is modifiable in flight 91 ("chg" bit). Effectively, for a given combination of these three 92 control bits there are only thirty-two possible types. 94 [RFC4727] defines experimental option types for Hop-by-Hop and 95 Destination options. A single base option type is assigned with all 96 possible values of the "act" and "chg" fields, resulting in eight 97 distinct option type codes (types 0x1e, 0x3e, 0x5e, 0x7e, 0x9e, 0xbe, 98 0xde, and 0xfe). These values are intended for testing purposes or 99 for use when an assigned codepoint is either not warranted or not 100 available, e.g., based on the maturity status of the defined 101 capability (i.e., Experimental or Informational, rather than 102 Standards Track). 104 Here, the term "experimental IPv6 Hop-by-Hop and Destination options" 105 refers to options that use the Hop-by-Hop or Destination experimental 106 option codepoints [RFC4727]. Such experiments can be described in an 107 RFC of any status (e.g., Experimental, Informational, etc.) and are 108 intended to be used in controlled environments and are allowed in 109 public deployments (when not enabled as default [RFC3692]). Nothing 110 prohibits the deployment of multiple experiments in the same 111 environment -- controlled or public. Furthermore, some protocols are 112 specified in Experimental or Informational RFCs, which either include 113 parameters or design choices not yet understood or which might not be 114 widely deployed [RFC2026]. 116 There is currently no mechanism to support shared use of the Hop-by- 117 Hop and Destination experimental option codepoints. Different 118 implementations use the same experimental option type for different 119 purposes which results in collisions in which a single codepoint can 120 be received at different times with different meanings intended by 121 the sender. 123 The approach proposed in this document does not require additional 124 Hop-by-Hop and Destination option codepoints and is robust to those 125 who choose either not to support it or not to register their 126 experiments. The solution defines a field in the Option Data of 127 experimental Hop-by-Hop and Destination options. This field is 128 populated with an "experiment identifier" (ExID) defined as part of a 129 specific option experiment. The ExID helps reduce the probability of 130 a collision of independent experimental uses of the same option 131 codepoint, both for those who follow this document (using registered 132 ExIDs) and those who do not (squatters who either ignore this 133 extension or do not register their ExIDs). 135 The solution proposed in this document is recommended for all new 136 protocols that use Hop-by-Hop or Destination experimental option 137 codepoints. 139 The techniques described in this document are adapted from [RFC6994] 140 which describes the mechanism to concurrently support different 141 experimental TCP options. 143 2 Requirements Language 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described in BCP 148 14 [RFC2119] [RFC8174] when, and only when, they appear in all 149 capitals, as shown here. 151 3 Hop-by-Hop and Destination Experimental Option Format 153 Hop-by-Hop and Destination options share a common format [RFC8200], 154 in which the first byte is the codepoint (Option Type) and the second 155 byte is the length of the option data in bytes (Opt Data Len): 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 158 | Option Type | Opt Data Len | Option Data 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 161 This document extends the option format for experimental Hop-by-Hop 162 and Destination option codepoints with an experiment identifier 163 (ExID), which is four bytes in length. The ExID is used to 164 differentiate experiments and is the first field after the Option 165 Type and Opt Data Len, as follows: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Option Type | Opt Data Len | ExID | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | ExID (cont) | | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 174 | | 175 + Option contents + 176 | | 178 All protocols using the experimental Hop-by-Hop or Destination option 179 codepoints that are deployed outside controlled environments, such as 180 in the public Internet, MUST use ExIDs as described in this document. 181 All protocols using ExIDs as described in this document MUST register 182 those ExIDs with IANA. Applicants register their desired ExID by 183 contacting IANA [IANA]. 185 3.1 Selecting an ExID 187 ExIDs are selected at design time, when the protocol designer first 188 implements or specifies the experimental option. An ExID is thirty- 189 two bits. The value is stored in the header in network-standard (big- 190 endian) byte order. ExIDs combine properties of IANA registered 191 codepoints with "magic numbers". 193 Use of the ExID helps reduce the probability of a false positive 194 collision with those who either do not register their experiment or 195 who do not implement this mechanism. 197 ExIDs are registered with IANA using "first come, first served" 198 (FCFS) priority. ExIDs MUST be unique. It is RECOMMENDED to use 199 random numbers with sufficient entropy and to avoid any values that 200 might commonly be present in unrelated data (e.g. 0x1, 0xffffffff 201 would be poor choices). The ExID value of 0x0 is reserved and MAY be 202 used internally in an implementation to represent the absence of an 203 ExID value. 205 The use of randomly assigned 32-bit identifiers in a sparsely 206 populated space takes on the characteristics of a "magic number". A 207 magic number is a randomized codepoint whose primary value is its 208 unlikely collision with values selected by others [RFC6994]. 210 A thirty-bit ExID maintains four byte alignment of the trailing 211 Option Data. A common alignment requirement of Hop-by-Hop and 212 Destination Options is 4n + 2, so maintaining four byte alignment 213 reduces the potential for implementation errors, especially in using 214 the same word-alignment padding, if the same implementation is later 215 modified to use a conventional codepoint. 217 3.2 Impact on Option Processing 219 The ExID number is part of the Hop-by-Hop or Destination Option Data. 220 The presence of the ExID increases the effective Option Data Length 221 field by the size of the ExID. The presence of an ExID is transparent 222 to implementations that do not implement the experimental option 223 types or the mechanism described here. 225 During receive processing, ExIDs in experimental options are matched 226 against the ExIDs for each implemented protocol. If an ExID is not 227 recognized, then the whole option is assumed to be unrecognized per 228 the definition in [RFC8200]. The high order 2 bits of the Option Type 229 specify the action in this case. If the action bits indicate that an 230 ICMP error is warranted then an ICMP Parameter Problem, Code 2, is 231 sent pointing to the first byte of the unrecognized ExID. 233 Although an ExID is in Option Data, it is considered to always be 234 immutable in flight even if the change bit is set in the Option Type. 235 Intermediate nodes MUST NOT modify an experimental identifier, or 236 equivalently, intermediate nodes MUST NOT modify the first four bytes 237 of Option Data in an option with an experimental Hop-by-Hop or 238 Destination option type. 240 3.3 Interaction with the Authentication Header 242 When an Authentication header is present, the ExID in any 243 experimental Hop-by-Hop or Destination option is included in the 244 computation for authenticating a packet, regardless of whether the 245 change bit is set. Specifically, the requirements of [RFC8200] are 246 updated so that if the Hop-by-Hop or Destination option type is 0x3e, 247 0x7e, 0xbe, or 0xfe, and an authentication header is present in a 248 packet, then the bytes in the Option Data field after the first four 249 bytes MUST be treated as zero-valued octets when computing or 250 verifying the packet's authenticating value (note that the first four 251 bytes of Option Data are not treated as zero-valued octets). 253 In a controlled environment, not on the public Internet for instance, 254 this requirement MAY be relaxed at the discretion of the 255 administrator in order to maintain backwards compatibility. In a 256 controlled environment, for Hop-by-Hop and Destination option types 257 0x3e, 0x7e, 0xbe, or 0xfe, the first four bytes of the Option Data 258 MAY be treated as zero-valued octets when computing or verifying the 259 packet's authenticating value. This SHOULD be controlled by 260 configuration where the RECOMMENED default is to always include the 261 first four bytes in authentication calculations. Configuration can be 262 system wide or selective based on matching the ExID (e.g. if a 263 receiver receives an experimental option with a known ExID it might 264 include the ExID in calculations, otherwise it could zero the first 265 four bytes for calculation). Note that the sender and receiver MUST 266 agree on whether the ExID bytes are included or not included in 267 calculations for authentication. Mechanisms to achieve such agreement 268 are out of scope of this document. 270 4 Reducing the Impact of False Positives 272 False positives occur where the registered ExID of an experiment 273 matches the value of an option that does not use ExIDs. Such 274 collisions can cause an option to be interpreted by the incorrect 275 processing routine. Experiments that are not robust to ExID false 276 positives SHOULD implement other detection measures, such as 277 checksums or minimal digital signatures over the experimental options 278 they support. 280 5 Migration to Assigned Options 282 Some experiments may transition away from being experimental and 283 become eligible for an assigned Hop-by-Hop or Destination option 284 codepoint. This document does not recommend a specific migration 285 plan to transition from use of the experimental Hop-by-Hop or 286 Destination options/ExIDs to use of an assigned codepoint. 288 Once an assigned codepoint is allocated, use of an ExID represents 289 unnecessary overhead. Therefore, once a Hop-by-Hop or Destination 290 option codepoint is assigned to a protocol, that protocol SHOULD NOT 291 continue to send the corresponding experimental option. An 292 implementation MAY continue receiving the experimental option and MAY 293 allow a fallback to sending the experimental option during some 294 transition period to maintain backwards compatibility. 296 6 Rationale 298 The rationale for 32-bit ExIDs as a combination of an assigned value 299 and a magic number is provided in section 6 of [RFC6994]. 301 7 Security Considerations 303 The interaction between the mechanisms described in this document and 304 the Authentication Header is described in section 3.3. Otherwise, the 305 mechanism neither weakens nor enhances the existing security of Hop- 306 by-Hop and Destination options. 308 8 IANA Considerations 310 IANA is requested to create an "IPv6 Hop-by-Hop and Destination 311 Option Experiment Identifiers (IPv6 Opt ExIDs)" registry. The 312 registry records 32-bit ExIDs, as well as a reference (description, 313 document pointer, assignee name, and e-mail contact) for each entry. 314 ExIDs are registered for use with any of the experimental Hop-by-Hop 315 and Destination option codepoints (i.e. option types 0x1e, 0x3e, 316 0x5e, 0x7e, 0x9e, 0xbe, 0xde, and 0xfe). 318 Entries are assigned on a First Come, First Served (FCFS) basis 319 [RFC5226]. The registry operates FCFS on the entire ExID (in network- 320 standard order). 322 IANA will advise applicants of duplicate entries to select an 323 alternate value, as per typical FCFS processing. 325 IANA will record known duplicate uses to assist the community in both 326 debugging assigned uses as well as correcting unauthorized duplicate 327 uses. 329 IANA should impose no requirements on making a registration other 330 than indicating the desired codepoint and providing a point of 331 contact. A short description or acronym for the use is desired but 332 should not be required. 334 Initial assignments are: 336 +----------------+----------------+---------------+ 337 | ExI D | Description | Reference | 338 +----------------+----------------+---------------+ 339 | 0 | Invalid ExID, | This document | 340 | | Implementation | | 341 | | internal use | | 342 | | | | 343 | 1..x0ffffffff | Unassigned | | 344 +----------------+----------------+---------------+ 346 9 References 348 9.1 Normative References 350 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 351 (IPv6) Specification", STD 86, RFC 8200, DOI 352 10.17487/RFC8200, July 2017, . 355 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 356 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 358 9.2 Informative References 360 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 361 Considered Useful", BCP 82, RFC 3692, January 2004. 363 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 364 3", BCP 9, RFC 2026, October 1996. 366 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 367 6994, DOI 10.17487/RFC6994, August 2013, . 370 [IANA] IANA, . 372 Author's Address 374 Tom Herbert 375 Quantonium 376 Santa Clara, CA 377 USA 379 Email: tom@quantonium.net