idnits 2.17.1 draft-nishida-tcpm-agg-syn-ext-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: When a responder receives 2 bytes length Aggregated Option in the 3rd segment, it MUST send back Aggregated Option to acknowledge the arrival of the option. If responder does not need to receive acknowledgement from initiator, it MUST send back a segment with Aggregated Option with the format shown in Figure 4 to indicate the end of option exchanges. If responder need to send additional options that requires acknowledgement, it MUST send 2-bytes Aggregated Option shown in Figure 3 and MUST start retransmission timer for retransmission. An endpoint that receives Fin Aggregated Option MUST not use Aggregated Options in subseqent segments. Similarly, an endpoint that sends Fin Aggregated Option MUST not use Aggregated Options once the segment is acknowledged. -- The document date (February 2, 2021) is 1176 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) == Outdated reference: A later version (-13) exists of draft-ietf-tcpm-tcp-edo-10 == Outdated reference: A later version (-12) exists of draft-touch-tcpm-tcp-syn-ext-opt-09 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Nishida 3 Internet-Draft Amazon Web Services 4 Intended status: Standards Track February 2, 2021 5 Expires: August 6, 2021 7 Aggregated Option for SYN Option Space Extension 8 draft-nishida-tcpm-agg-syn-ext-00 10 Abstract 12 TCP option space is scarce resource as its max length is limited to 13 40 bytes. This limitation becomes more significant in SYN segments 14 as all options used in a connection should be exchanged during SYN 15 negotiations. This document proposes a new SYN option negotiation 16 scheme that provide a feature to compress TCP options in SYN segments 17 and provide more option space. The proposed scheme does not update 18 the format of TCP header nor transmit any additional SYN or SYN-like 19 segments so that it has lower risks for middlebox interventions. In 20 addition, by combining another proposal for option space extension, 21 it is possible to provide further option space. 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 https://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 August 6, 2021. 40 Copyright Notice 42 Copyright (c) 2021 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 59 3. Basic Design . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Aggregated Option . . . . . . . . . . . . . . . . . . . . 4 61 3.2. Additional Information Exchange Using 3rd ACK Segments . 6 62 3.3. Examples of Option Exchanges with Aggregated Options . . 7 63 4. Option Bits Registration . . . . . . . . . . . . . . . . . . 9 64 5. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1. Incremental Deployments for Aggregated Option . . . . . . 10 66 5.2. Middlebox Considerations . . . . . . . . . . . . . . . . 10 67 5.3. Which Options are Aggregatable . . . . . . . . . . . . . 10 68 5.4. Further Extensions . . . . . . . . . . . . . . . . . . . 11 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 7.1. Aggregated Option . . . . . . . . . . . . . . . . . . . . 11 72 7.2. Option Bits Registry for Aggregated Option . . . . . . . 12 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 75 8.2. Informative References . . . . . . . . . . . . . . . . . 12 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 TCP option space is scarce resource as its max length is limited to 81 40 bytes. This limitation is a nominal issue especially for SYN 82 segment. This is because although a TCP endpoint can send only one 83 SYN segment to the peer, SYN segments need to contain all options 84 expected to be used for the connection. As a result, the current SYN 85 option space tends to be congested. Many TCP connections use MSS 86 [RFC0793], Timestamp and Window Scale [RFC7323], SACK Permitted 87 options [RFC2018] which already consume 19 bytes (10 + 4 + 3 + 2). 88 In addition to them, if a connection wants to use Multipath TCP 89 [RFC8684], it requires additional 4-12 bytes for MP_CAPABLE or 12-16 90 bytes for MP_JOIN option. Similarly, TCP Fast Open [RFC7413] and TCP 91 AO [RFC5925] require additional 6-18 bytes and 16 bytes respectively. 92 Moreover, Experimental Option Format defined in [RFC6994] consumes 93 more option space as it requires additional 16 bits or 32 bits EXID 94 field than the standard option format. Hence, if an endpoint is 95 willing to activate some of extra features in addition to common 96 options, 40 bytes space may not be sufficient. If SYN segment cannot 97 accommodate all required options, it means endpoints need to give up 98 using some features. This issue affects the extensibility of TCP. 100 There have been various proposals in order to extend option space in 101 SYN Segments [I-D.eddy-tcp-loo] [I-D.yourtchenko-tcp-loic] 102 [I-D.touch-tcpm-tcp-syn-ext-opt] [I-D.briscoe-tcpm-inner-space] 103 [I-D.allman-tcpx2-hack]. These proposals have adopted one or both of 104 the following two types of approach. 106 o Extending TCP header in SYN segment: This approach tries to 107 accommodate more options in a SYN segment by using payload. (E.g 108 override Data Offset field in TCP header) 110 o Using Multiple SYN or SYN-like segment: This approach tries to use 111 multiple SYN segment or additional segment that can be treated as 112 a SYN segment. (E.g sending another SYN with wrong checksum or 113 from different source port) 115 However, these approach tend to require a certain complexity and have 116 potential risks for middlebox interventions. In this document, in 117 order to reduce the risk for middlebox intervention we propose to 118 extend option space in SYN segments through the following approach 119 which utilizes "3rd segments". In this document, we define "3rd 120 segment" as the segments sent from initiator that contains 121 acknowledge for the SYN ACK segment from responder. 123 o Aggregated Option Format: we propose a new option format that can 124 aggregate multiple TCP options into a single option format so that 125 it can create more space than conventional option formats. 127 o Using 3rd segments for supplemental negotiation: we propose to use 128 3rd segment and its acknowledge for additional feature information 129 exchanges. 131 One important characteristic of this approach is that it does not 132 require any changes in SYN header format nor using multiple SYN or 133 SYN-like segments. In stead, it utilizes 3rd segments which should 134 looks legitimate segments from middleboxes' points of view. MPTCP 135 [RFC8684] specifications already requires the use of 3rd segment for 136 further information exchanges. Hence, in a sense, the proposal in 137 this document may look using the scheme in MPTCP for more generic 138 purposes. Given that the maturity and the deployment status of MPTCP 139 implementations, we believe that this approach has lower risks for 140 middlebox interventions without introducing lots of complexity in TCP 141 architecture. 143 2. Conventions and Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in [RFC2119]. 149 3. Basic Design 151 The proposed scheme in this document has the following two design 152 criteria. 154 1. All feature negotiations are archived during a single SYN 155 exchange. No extra SYN or SYN-like segments are utilized. 157 2. No change is required for TCP header format. Use current option 158 space in TCP header and not use payload for option space. 160 These requirements ensure that the scheme can have simple 161 architecture and can traverse middleboxes without problems. In order 162 to fulfill this requirements, For this purpose, we propose a new 163 option format and a scheme for additional information exchange as 164 follows. 166 3.1. Aggregated Option 168 This aggregated option can be used only to indicate that an endpoint 169 want to enable the specified features in the option. This option 170 uses one bit to express one TCP option. This is because this option 171 is used only to indicate that an endpoint wants to use specified 172 features. The receiver of the option can only specify whether it 173 agrees to use the requested features or not. The format of 174 aggregated option format is shown in Figure 1. The option can 175 contains 0-3 Aggregated Blocks which have 1 byte length. The length 176 of the option format is varied by the number of Aggregated blocks in 177 the option. 179 1 2 3 180 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 181 +--------------+---------------+ - - - - - - - +- - - - - - - - 182 | Kind = TBD | Length = 2-5 | Block #1 | Block #2 | 183 +--------------+---------------+ - - - - - - - +- - - - - - - - 184 | Block #3 | 185 - - - - - - - - 187 Figure 1: Aggregated Option format 189 Figure 2 shows the format of Aggregated block. Aggregated block has 190 1 byte length which consists of 2 bits "Group ID" (GID) field and 6 191 bits "Option Bits" field. The options supported by Aggregated Option 192 is split into 4 groups, such as an option defined in a standard RFC 193 belongs to group 1 or group 2, an option in an experimental RFC 194 belongs to group 3, etc. (Note: how to allocate option bits will be 195 discussed later) Group ID field is used to identify the group 196 identifier of the option bits in the Aggregated Option and each 197 single bit in Option Bits field represent a option in the group. 199 If all options that an endpoint wants to aggregate belong to one 200 group, the aggregated option will need to contain just one Aggregated 201 Block. However, if the option will need to contain multiple blocks 202 when an endpoint wants to use options in multiple groups. 204 0 1 2 3 4 5 6 7 205 +----------------------+ 206 | GID | Option Bits | 207 +----------------------+ 209 Figure 2: Aggregated Block format 211 GID field in Aggregated Block indicate the group ID that option bits 212 in the block belongs to. Aggregated Blocks are appeared in SYN and 213 SYN ACK segments, however, different mappings between GID value in 214 the option and Group ID are used for these two segments. This is 215 because some implementations may copy back unknown options in their 216 response segments. These mappings is used not to be confused by such 217 cases. Table Table 1 shows the mapping between GID value in the 218 option and Group ID. For example, GID value 1 in SYN represents 219 group 2, while GID value 1 in ACK segment for SYN ACK represents 220 group 1. 222 +------------------+----------------------+----------------------+ 223 | GID value in SYN | GID value in SYN ACK | Group ID Description | 224 +------------------+----------------------+----------------------+ 225 | 0 | 1 | group 1 | 226 | | | | 227 | 1 | 2 | group 2 | 228 | | | | 229 | 2 | 3 | group 3 | 230 | | | | 231 | 3 | 0 | Extensions | 232 +------------------+----------------------+----------------------+ 234 Table 1: Mapping between GID value and Group ID 236 The allocation of the bit in Option Bits field in each group will be 237 managed by the registry provided by IANA. Since an aggregated block 238 has 6 bits field to indicate options, one group can have 6 options at 239 most. As shown in Table 1, we currently propose to allocate 3 GID 240 for options and 1 GID is reserved for future extensions. 241 Consequently, the maximum number of options that can be aggregated 242 with Aggregated Option will be limited to 18. We believe this is 243 sufficient number for the time being based on the current usage of 244 option code points. In addition, Section Section 5.4 describes some 245 possibilities to overcome the limitation in case we need to support 246 more options to be supported. 248 Aggregated Option that contains Aggregated Blocks MUST be only used 249 in SYN segments. When an endpoint received SYN segments with 250 Aggregated Option, it checks Aggregated Blocks in the option. If the 251 option does not contain Aggregated Blocks, the segment MUST be 252 discarded. If it contains Aggregated Blocks, the options specified 253 in the blocks MUST be processed as well as options in original 254 formats. When a responder sends back SYN ACK to the initiator, it 255 uses original formats of the options or Aggregated options depends on 256 remaining options space or other criteria. 258 3.2. Additional Information Exchange Using 3rd ACK Segments 260 Aggregated Option is used to negotiate the use of features that an 261 endpoint would like to activate. However, it does not provide a way 262 to negotiate additional information. This suffices for options that 263 do not require additional parameters such as SACK-Permit option. 264 However, if options need additional parameter exchanges, these 265 parameters will need to be sent through 3rd segment. When options 266 are sent in the 3rd segments, original formats of the options are 267 used. In this case, in order to solicit acknowledgement for this 268 segments, an initiator MUST include 2 bytes length Aggregated Option 269 to 3rd segment with the format shown in Figure 3. 271 1 272 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 273 +--------------+---------------+ 274 | Kind = TBD | Length = 2 | 275 +--------------+---------------+ 277 Figure 3: 2-Byte Aggregated Option format 279 In addition, it MUST start retransmission timer even if it is a pure 280 ACK and MUST retransmit the same segment when the timer is expired. 281 Note that the 3rd segment does not have to be a pure ACK segment. If 282 an endpoint has data to be sent, it can send it with the segment. 284 When a responder receives 2 bytes length Aggregated Option in the 3rd 285 segment, it MUST send back Aggregated Option to acknowledge the 286 arrival of the option. If responder does not need to receive 287 acknowledgement from initiator, it MUST send back a segment with 288 Aggregated Option with the format shown in Figure 4 to indicate the 289 end of option exchanges. If responder need to send additional 290 options that requires acknowledgement, it MUST send 2-bytes 291 Aggregated Option shown in Figure 3 and MUST start retransmission 292 timer for retransmission. An endpoint that receives Fin Aggregated 293 Option MUST not use Aggregated Options in subseqent segments. 294 Similarly, an endpoint that sends Fin Aggregated Option MUST not use 295 Aggregated Options once the segment is acknowledged. 297 1 2 298 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 299 +--------------+---------------+----------------+ 300 | Kind = TBD | Length = 3 |1 1 0 0 0 0 0 0 | 301 +--------------+---------------+----------------- 303 Figure 4: Fin Aggregated Option format 305 When an endpoint sends a segment with 2 byte Aggregated Option, it 306 MUST retransmit the segment until it receives an ACK for the segment 307 with Aggregated Option (2 byte or Fin Aggregated Option). When it 308 receives an ACK for the segment without Aggregated Option, it MUST 309 ignore and discard the ACK. 311 3.3. Examples of Option Exchanges with Aggregated Options 313 We show 3 patterns of option negotiations with Aggregated Option in 314 the following examples: Figure Figure 5 , Figure Figure 6 and 315 Figure Figure 7. In these examples, we use hypothetical option A and 316 B. Option A is an option that does not require additional 317 information such as SACK Permit option. While Option B are an option 318 that needs to exchanges additional parameters. "Non-Agg options" in 319 the examples represent the options that are not aggregated, which are 320 sent with their original formats. 322 As shown in Figure 5, as option A does not require additional 323 information, exchanging SYN and SYN ACK segments with Aggregated 324 Options are enough for feature negotiation. In this case, initiator 325 sends back 3rd segment with Fin Aggregated Option only to indicate 326 the end of option negotiation. 328 Initiator Responder 330 SYN + Non-Agg Options + 331 Aggregated Option 332 (bit for option A is set) 333 ----------> 334 SYN ACK + Non-Agg Options + 335 Aggregated Option 336 (bit for option A is set) 337 <----------- 339 ACK + Fin Aggregated Option 340 ----------> 342 Figure 5: Example of Aggregated Option #1 344 Figure 6 is an example that uses option B which require additional 345 information exchange. In this case, After exchanging Aggregated 346 Options during SYN exchanges, initiator sends 3rd ACK segment with 347 2-Byte Aggregated Options in addition to the original form of option 348 B. Similarly, responder sends back the ACK for the segment with 349 2-Bytes Aggregated Options in addition to the original form of Option 350 B. After that, initiator sends an ACK with Fin Aggregated Option 351 only to indicate the end of option negotiation. 353 Initiator Responder 355 SYN + Non-Agg Options + 356 Aggregated Option 357 (bit for option B is set) 358 ----------> 359 SYN ACK + Non-Agg Options + 360 Aggregated Option 361 (bit for option B is set) 362 <---------- 364 ACK + Option B + 365 2-Byte Aggregated Option 366 ----------> 368 ACK + Option B + 369 2-Byte Aggregated Option 370 <---------- 372 ACK + Fin Aggregated Option 373 ----------> 375 Figure 6: Example of Aggregated Option #2 377 Figure 7 also uses option B as Figure 6, however, initiator only 378 sends two segments for option negotiations. In this case, when 379 responder sends SYN-ACK, it sends back the segment with original form 380 of Option B. In this case, when responder sends back the ACK for 3rd 381 segment, it sends the segment with Fin Aggregated Option to indicate 382 the end of option negotiation. In this case, while sender utilizes 383 extra option space with Aggregated Option in 3rd segment, responder 384 uses option space only in SYN ACK segment. This use case can be 385 useful when only option space in SYN segment needs to be extended. 387 Initiator Responder 389 SYN + Non-Agg Options + 390 Aggregated Option 391 (bit for option B is set) 392 ----------> 393 SYN ACK + Non-Agg Options + 394 option B 395 <---------- 397 ACK + Option B + 398 2-Byte Aggregated Option 399 ----------> 401 ACK + Option B + 402 Fin Aggregated Option 403 <---------- 405 Figure 7: Example of Aggregated Option #3 407 4. Option Bits Registration 409 As described in Section Section 3, Aggregated Option has 18 Option 410 bits space and each bit represents a single option ID. The 411 allocation of the Option Bits in Aggregated Option is maintained by 412 IANA [IANA]. If a new option can be aggregatable, one can request 413 Option Bit in addition to the current procedure, requesting TCP 414 Option Kind Number in [TCPParameters] . If a option already has 415 assigned TCP Option Kind Number, one can only request Option bit 416 which will represent the option kind. 418 5. Discussions 419 5.1. Incremental Deployments for Aggregated Option 421 An endpoint MAY send the original form of an option and Aggregated 422 Option for the option in SYN segments if option space is available. 423 This may look redundant, but it can be useful when an endpoint sends 424 a SYN segment to a new destination. In this case, if the peers 425 support the option and Aggregated Option, they can send back 426 Aggregated Option in addition to the response for normal option 427 format. The endpoint cache this information and when it opens 428 another connection to the the same destination with a short interval, 429 it can send only Aggregated Option this time. If an endpoint did not 430 receive SYN ACK when it sent Aggregated Option to a new destination, 431 the retransmitted SYN segment SHOULD NOT include Aggregated Option. 433 5.2. Middlebox Considerations 435 As Aggregated Option will be a new option, there is a potential risk 436 that the option will be removed from the segment or the segment that 437 carries the option will be discarded by the middleboxes. While we 438 believe the risk for this risk is low from the past studies 439 [HONDA11], if endpoints try to aggregate well-known TCP options such 440 as SACK-Permit, MSS, TimeStamp to new destinations, it is recommended 441 to follow incremental deployment approach described in the previous 442 section. On the other hand, the risk for the removal of Aggregated 443 Option and new options can be considered mostly in the same level. 444 In this case, endpoints MAY send only the aggregated option to new 445 destinations. 447 If a middlebox strips Aggregated options in SYN segments but keeps 448 other options unchanged, the proposed scheme can behave safely. When 449 Aggregated Option in SYN segment from initiator is removed on 450 outgoing path, both endpoint will not activate any features in the 451 Aggregated Option. When Aggregated Option is removed on return path, 452 there will be a situation where the responder enables the features in 453 Aggregated Option while initiator disables the features. However, 454 the responder still can aware that the Aggregated Option is removed 455 on the return path when it receives the 3rd segments without 456 Aggregate Option. In this case, the responder can decide whether it 457 can continue the connection or reset it based on the features in the 458 Aggregated Option. 460 5.3. Which Options are Aggregatable 462 While we think most of options can be aggregated by using Aggregated 463 Option, there will be some limitations. One example would be TCP AO 464 [RFC5925] as it has to carry security information in SYN segments. 465 If an option must carry additional information for the feature like 466 TCP AO, we cannot aggregate the option. TCP Fast Open [RFC7413] 467 would be another example as it needs to carry cached cookie 468 information in SYN segments. Sending cookie info in the 3rd segments 469 is not desirable from the objective of TCP Fast Open. However, when 470 initiator sends Fast Open Cookie Request, the request can be 471 aggregated as it does not carry additional information. Hence, we 472 still believe that it will be useful to aggregate TCP Fast Open 473 option in some cases. 475 5.4. Further Extensions 477 The proposed approach can aggregate 18 options with Aggregated 478 Options. We believe this is enough number for the time being based 479 on the current usages of TCP options. It is also possible to 480 accommodate more options by using Group id 4 which is currently 481 reserved for future extensions. 483 Aggregated Option can extend available space for TCP options in SYN 484 segments by utilizing 3rd segments and its acknowledgement. However, 485 there might be a situation where this is still not enough to 486 accommodate all TCP options that an endpoint would like to activate. 487 In this case, one possible approach is to utilize TCP Extended Data 488 Offset Option (EDO) [I-D.ietf-tcpm-tcp-edo]. As EDO supported Option 489 does not carry any information, it can be aggregated in Aggregated 490 Option. Once both endpoints agree to use the feature by SYN 491 exchange, an endpoint can start using EDO to extend option space in 492 the 3rd segments and its acknowledgement. This approach will create 493 more space for options in SYN segments although further discussions 494 will be required for more detailed design. 496 6. Security Considerations 498 We believe Aggregated Option maintains the same level of security as 499 other TCP options does, but further discussions will be required. 501 7. IANA Considerations 503 This document requests new TCP option codepoint. In addition, this 504 document requires new registry for the option. They are described in 505 the following subsections. 507 7.1. Aggregated Option 509 This document requests to add new option: Aggregated Option to the 510 TCP option space registry which points to this document as follows: 512 +------+--------+--------------------+----------------+ 513 | Kind | Length | Meaning | Reference | 514 +------+--------+--------------------+----------------+ 515 | TBD | N | Aggregated Option | This Document | 516 +------+--------+--------------------+----------------+ 518 Table 2: Aggregated Option Format 520 7.2. Option Bits Registry for Aggregated Option 522 This document also requests to create a "Aggregated Option 523 Identifiers" registry in IANA registries. The registry maintains 24 524 records which are mapped to the TCP Option Kind Number Records in 525 [TCPParameters] The 24 records are divided into 4 groups so that each 526 group contains 6 records. 528 8. References 530 8.1. Normative References 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, 534 DOI 10.17487/RFC2119, March 1997, 535 . 537 8.2. Informative References 539 [HONDA11] Honda, M., "Is it still possible to extend TCP?", IMC 540 2011 , November 2011. 542 [I-D.allman-tcpx2-hack] 543 Allman, M., "TCPx2: Don't Fence Me In", draft-allman- 544 tcpx2-hack-00 (work in progress), May 2006. 546 [I-D.briscoe-tcpm-inner-space] 547 Briscoe, B., "Inner Space for TCP Options", draft-briscoe- 548 tcpm-inner-space-01 (work in progress), October 2014. 550 [I-D.eddy-tcp-loo] 551 Eddy, W. and A. Langley, "Extending the Space Available 552 for TCP Options", draft-eddy-tcp-loo-04 (work in 553 progress), July 2008. 555 [I-D.ietf-tcpm-tcp-edo] 556 Touch, J. and W. Eddy, "TCP Extended Data Offset Option", 557 draft-ietf-tcpm-tcp-edo-10 (work in progress), July 2018. 559 [I-D.touch-tcpm-tcp-syn-ext-opt] 560 Touch, J. and T. Faber, "TCP SYN Extended Option Space 561 Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn- 562 ext-opt-09 (work in progress), July 2018. 564 [I-D.yourtchenko-tcp-loic] 565 Yourtchenko, A., "Introducing TCP Long Options by Invalid 566 Checksum", draft-yourtchenko-tcp-loic-00 (work in 567 progress), April 2011. 569 [IANA] "IANA Home Page", . 571 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 572 RFC 793, DOI 10.17487/RFC0793, September 1981, 573 . 575 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 576 Selective Acknowledgment Options", RFC 2018, 577 DOI 10.17487/RFC2018, October 1996, 578 . 580 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 581 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 582 June 2010, . 584 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 585 RFC 6994, DOI 10.17487/RFC6994, August 2013, 586 . 588 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. 589 Scheffenegger, Ed., "TCP Extensions for High Performance", 590 RFC 7323, DOI 10.17487/RFC7323, September 2014, 591 . 593 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 594 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 595 . 597 [RFC8684] Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 598 Paasch, "TCP Extensions for Multipath Operation with 599 Multiple Addresses", RFC 8684, DOI 10.17487/RFC8684, March 600 2020, . 602 [TCPParameters] 603 "Transmission Control Protocol (TCP) Parameters", 604 . 607 Author's Address 609 Yoshifumi Nishida 610 Amazon Web Services 611 410 Terry Avenue North 612 Seattle, WA 98109 613 USA 615 Email: nishida@wide.ad.jp