idnits 2.17.1 draft-eddy-tcpm-addl-exp-options-00.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 RFC4727, but the abstract doesn't seem to directly say this. It does mention RFC4727 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 RFC4727, updated by this document, for RFC5378 checks: 2005-07-12) -- 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 16, 2011) is 4636 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) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Eddy 3 Internet-Draft MTI Systems 4 Updates: 4727 (if approved) August 16, 2011 5 Intended status: Standards Track 6 Expires: February 17, 2012 8 Additional TCP Experimental-Use Options 9 draft-eddy-tcpm-addl-exp-options-00 11 Abstract 13 There have been multiple issues with the allocation of TCP option 14 kind numbers recently. Two of these issues, which this document 15 attempts to address, are that there were only a small number of 16 options reserved by RFC 4727 for experiment and test use in the RFC 17 3692 style to begin with, and both of these have been used in 18 shipping products. This impacts the ability of other research and 19 experimental efforts to develop and test running code since 20 registration of other option numbers requires either IESG Approval or 21 Standards Action. This document proposes designation of additional 22 experimental options in the IANA registry for TCP Option Kind 23 Numbers, intended to resolve the possible barriers to using the 24 existing RFC 3962 experimental-use options. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. This document may not be modified, 30 and derivative works of it may not be created, except to format it 31 for publication as an RFC and to translate it into languages other 32 than English. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 17, 2012. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Additional Experimental-Use Options . . . . . . . . . . . . . . 4 65 3. Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 68 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 70 6.2. Informative References . . . . . . . . . . . . . . . . . . 6 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 1. Introduction 75 TCP options are a fundamental mechanism for extending and enhancing 76 TCP's functionality. In the past, the addition of TCP options (e.g. 77 Window Scale, Timestamp [RFC1323], and Selective Acknowledgements 78 [RFC2018]) has supported the protocol's evolution and helped its 79 applicability to expand as the Internet and types of links available 80 grew. 82 However, there has been significant confusion with regards to how TCP 83 option kind numbers are managed. This is, frankly, dangerous to the 84 Internet, if it persists. There is a limited pool of options and due 85 to misunderstandings the usable portion of this pool has shrunk to an 86 unknown extent. 88 Registration of TCP option kind numbers is a function of the IANA 89 [RFC2780]. Values are assigned following either (1) IESG Approval, 90 or (2) Standards Action process, which are defined in [RFC2434]. 91 Some vendors have not followed these procedures and simply shipped 92 products using option kind numbers chosen themselves. This poisons 93 the pool of options available, as it potentially causes conflicts if 94 IANA later registers those same kind numbers for a use that followed 95 the proper registration process. This has been recognized as a 96 mistake, and vendors have expressed a desire to avoid it in the 97 future and are working towards possible transition of such products 98 to registered options numbers. 100 Two TCP option numbers have been designated for experimental use 101 [RFC4727], which are not intended to be used in general deployments 102 or enabled by default in products or other general releases unless 103 explicitly enabled by an end-user [RFC3692]. 105 Unfortunately, at least one vendor intending to avoid shipping its 106 products using unregistered option numbers, actually shipped products 107 using the experimental-use numbers. These numbers are being used by 108 some deployed middleboxes and the impacts to other people trying to 109 use the same kind numbers for other purposes is not broadly 110 understood, especially since the presence of such middleboxes on a 111 path may be unknown a priori. 113 A recent TCP research effort testing running code over the Internet 114 that would have been a perfect candidate for using the experimental- 115 use numbers shied away from this due to the deployed middlebox issue 116 and chose to improperly use yet more unregistered TCP option kind 117 numbers. 119 Another recent issue is that with multiple ongoing efforts to extend 120 TCP, there may be implementations that integrate a number of 121 extensions requiring experimental-use options. Two kind numbers may 122 not be sufficient for such cases, and adding sub-kind identifiers 123 within the option payload may be complex or even impossible. 125 This document attempts to mitigate the situation and remove excuses 126 for such instances in the future by requesting IANA to register a 127 greater number of TCP experimental-use options that would also follow 128 the RFC 3692 spirit for their intended use. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119. [RFC2119] 134 2. Additional Experimental-Use Options 136 This document proposes to create an additional sixteen experimental- 137 use TCP option kinds in the spirit of RFC 3692. As this may seem 138 like a large number compared to the current two that RFC 4727 139 requested, some rationale is provided in the next section. 141 Of these sixteen option kinds, the option-length field for all of 142 them will be defined as variable, but in all cases will hold a value 143 of at least 2 in order to account for the kind and length fields. 145 The option kind numbers allocated should be contiguous in order to 146 support potential ease of updating filter rules and other databases 147 used in firewalls and other middleboxes, as well as various other 148 software tools for packet analysis and other uses. 150 3. Rationale 152 There are only 8 bits that comprise a TCP Option Kind field, lending 153 256 possible unique codepoints. Of these, there are the 2 identified 154 in RFC 4727 for experimental-use and 19 with registrations that are 155 currently not identified as obsolete (historic and currently unused) 156 or unassigned due to release of prior registrations. Of these, 157 several are not known to be in general use and could likely be reaped 158 if needed. Additionally, 11 kind numbers have been identified as 159 obsolete or unassigned due to registration being released, and 6 more 160 are known to be deployed without proper IANA assignment. One further 161 protocol under development in the IETF (Multipath TCP) requires an 162 IANA option kind assignment yet-to-be-made. 164 This leaves 217 option kind values that both have never been 165 registered and are not known to have been under deployment without 166 registration. Even though this document proposes to claim 16 of 167 these values for experimental-use, there will still be 201 option 168 kind values seemingly fully available, which represents over 78% of 169 the option kind numbers. Based on TCP's existence for several 170 decades without even using a quarter of the available options space, 171 the remaining pool of kind numbers should be sufficient for many more 172 decades to come. 174 Further, 16 option numbers for experimental use should be more than 175 sufficient by a factor of 2 to 4 in order to permit implementing and 176 testing combinations of experimental TCP extensions that do not yet 177 have their own registered option kind numbers. This is especially 178 true as recently Multipath TCP design has set an example for using a 179 sub-kind / subtype field in order to avoid requiring multiple kind 180 numbers from the TCP registry. This practice could be reused by 181 future similar extensions making extensive use of TCP options. 183 4. Security Considerations 185 This document creates no additional security considerations for TCP 186 implementations. 188 Firewalls and other network devices that aggressively filter 189 unrecognized TCP options may cause difficulties in using the new 190 experimental-use kind numbers defined by this document. Managers and 191 vendors of such firewalls should reconsider whether such filtering is 192 necessary or useful as this practice represents a major impediment to 193 innovation in TCP. 195 5. IANA Considerations 197 This document requests that IANA allocate sixteen contiguous TCP 198 option values for experimental-use in the spirit of RFC 3692, which 199 will be described in the registry as: 201 o Length: N 203 o Meaning: RFC3692-style Experiment - MUST NOT be used by default in 204 shipping products, or other uncontrolled wide-scale deployments 205 outside of an experimental context 207 o Reference: (this document's RFC number, to be filled in) 209 Allocation from the rear of the available reserved space adjacent 210 below the two existing experimental-use options (253 and 254) is 211 desirable. 213 6. References 215 6.1. Normative References 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, March 1997. 220 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 221 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 223 6.2. Informative References 225 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 226 for High Performance", RFC 1323, May 1992. 228 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 229 Selective Acknowledgment Options", RFC 2018, October 1996. 231 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 232 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 233 October 1998. 235 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 236 Values In the Internet Protocol and Related Headers", 237 BCP 37, RFC 2780, March 2000. 239 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 240 Considered Useful", BCP 82, RFC 3692, January 2004. 242 Author's Address 244 Wesley M. Eddy 245 MTI Systems 246 MS 500-ASRC 247 NASA Glenn Research Center 248 21000 Brookpark Road 249 Cleveland, OH 44135 250 USA 252 Phone: +1-216-433-6682 253 Email: wes@mti-systems.com