idnits 2.17.1 draft-ietf-tcpm-tcpmss-05.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC879, updated by this document, for RFC5378 checks: 1983-11-01) -- 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 (June 7, 2012) is 4339 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 879 (Obsoleted by RFC 7805, RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Network Working Group 3 Internet-Draft D. Borman 4 Updates: 879, 2385 Quantum Corporation 5 Intended Status: Informational June 7, 2012 6 File: draft-ietf-tcpm-tcpmss-05.txt 8 TCP Options and MSS 10 Abstract 12 This memo discusses what value to use with the TCP Maximum Segment 13 Size (MSS) option, and updates RFC 879 and RFC 2385. 15 Status of This Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on December 7, 2012. 39 Copyright 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 1. Introduction 46 There has been some confusion as to what value should be filled in 47 the TCP MSS option when using IP and TCP options. RFC 879 [RFC879] 48 stated: 50 The MSS counts only data octets in the segment, it does not 51 count the TCP header or the IP header. 53 which is unclear about what to do about IP and TCP options, since 54 they are part of the headers. RFC 1122 [RFC1122] clarified the MSS 55 option, which is discussed in Appendix A, but there still seems to be 56 some confusion. 58 1.1 Terminology 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 61 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 62 in this document are to be interpreted as described in RFC 2119 63 [RFC2119]. 65 2. The Short Statement 67 When calculating the value to put in the TCP MSS option, the MTU 68 value SHOULD be decreased by only the size of the fixed IP and TCP 69 headers, and SHOULD NOT be decreased to account for any possible IP 70 or TCP options; conversely, the sender MUST reduce the TCP data 71 length to account for any IP or TCP options that it is including in 72 the packets that it sends. The rest of this document just expounds 73 on that statement, and the goal is to avoid IP level fragmentation of 74 TCP packets. 76 The size of the fixed TCP header is 20 bytes [RFC793], the size of 77 the fixed IPv4 header is 20 bytes [RFC791], and the size of the fixed 78 IPv6 header is 40 bytes [RFC2460]. The determination of what MTU 79 value should be used, especially in the case of multi-homed hosts, is 80 beyond the scope of this document. 82 3. MSS in other RFCs 84 3.1 RFC 879 86 RFC 879 [RFC879] discusses the MSS option and other topics. In 87 the introduction, it states: 89 "THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE 90 MINUS FORTY." 92 and in section 13, it states: 94 "The definition of the MSS option can be stated: 96 The maximum number of data octets that may be received by 97 the sender of this TCP option in TCP segments with no TCP 98 header options transmitted in IP datagrams with no IP header 99 options." 101 These are both correct. However, in the next paragraph in section 102 14, it then confuses this by stating that the consequence is: 104 "When TCP is used in a situation when either the IP or TCP 105 headers are not minimum and yet the maximum IP datagram that 106 can be received remains 576 octets then the TCP Maximum Segment 107 Size option must be used to reduce the limit on data octets 108 allowed in a TCP segment." 110 For example, if the IP Security option (11 octets) were in 111 use and the IP maximum datagram size remained at 576 octets, 112 then the TCP should send the MSS with a value of 525 113 (536-11)." 115 That is incorrect. The simpler and more correct statement would 116 be: 118 When TCP is used in a situation where either the IP or TCP 119 headers are not minimum, the sender must reduce the amount of 120 TCP data in any given packet by number of octets used by the IP 121 and TCP options. 123 3.2 RFC 2385 125 RFC 2385 [RFC2385] incorrectly states in section 4.3: 127 "As with other options that are added to every segment, the 128 size of the MD5 option must be factored into the MSS offered to 129 the other side during connection negotiation. Specifically, 130 the size of the header to subtract from the MTU (whether it is 131 the MTU of the outgoing interface or IP's minimal MTU of 576 132 bytes) is now at least 18 bytes larger." 134 This is incorrect, the value for the MSS option is only adjusted 135 by the fixed IP and TCP headers. 137 4. Clarification from the TCP Large Windows mailing list 139 The initial clarification was sent to the TCP Large Windows mailing 140 list in 1993 [Borman93]; this section is based on that message. 142 The MSS value to be sent in an MSS option should be equal to the 143 effective MTU minus the fixed IP and TCP headers. By ignoring both 144 IP and TCP options when calculating the value for the MSS option, if 145 there are any IP or TCP options to be sent in a packet, then the 146 sender must decrease the size of the TCP data accordingly. The 147 reason for this can be seen in the following table: 149 +--------------------+--------------------+ 150 | MSS is adjusted | MSS isn't adjusted | 151 | to include options | to include options | 152 +--------------------+--------------------+--------------------+ 153 | Sender adjusts | Packets are too | Packets are the | 154 | packet length | short | correct length | 155 | for options | | | 156 +--------------------+--------------------+--------------------+ 157 | Sender doesn't | Packets are the | Packets are too | 158 | adjust packet | correct length | long | 159 | length for options | | | 160 +--------------------+--------------------+--------------------+ 162 The goal is to not send IP datagrams that have to be fragmented, and 163 packets sent with the constraints in the lower right of this grid 164 will cause IP fragmentation. Since the sender doesn't know if the 165 received MSS option was adjusted to include options, the only way to 166 guarantee that the packets are not too long is for the data sender to 167 decrease the TCP data length by the size of the IP and TCP options. 168 It follows then, that since the sender will be adjusting the TCP data 169 length when sending IP and TCP options, there is no need to include 170 the IP and TCP option lengths in the MSS value. 172 Another argument against including IP or TCP options in the 173 determination of the MSS value is that the MSS is a fixed value, and 174 by their very nature the length of IP and TCP options are variable, 175 so the MSS value can never accurately reflect all possible IP and TCP 176 option combinations, the only one that knows for sure how many IP and 177 TCP options are in any given packet is the sender, hence the sender 178 should be doing the adjustment to the TCP data length to account for 179 any IP and TCP options. 181 5. Additional considerations 183 5.1 Path MTU Discovery 185 The TCP MSS option specifies an upper bound for the size of 186 packets that can be received. Hence setting the value in the MSS 187 option too small can impact the ability for Path MTU discovery to 188 find a larger Path MTU. For more information on Path MTU 189 Discovery, see: 191 RFC 1191 "Path MTU Discovery" [RFC1191] 192 RFC 2923 "TCP Problems with Path MTU Discovery" [RFC2923] 193 RFC 4821 "Packetization Layer Path MTU Discovery" [RFC4821] 195 5.2 Interfaces with Variable MSS values 197 The effective MTU can sometimes vary, as when used with variable 198 compression, e.g., ROHC [RFC5795]. It is tempting for TCP to want 199 to advertise the largest possible MSS, to support the most 200 efficient use of compressed payloads. Unfortunately, some 201 compression schemes occasionally need to transmit full headers 202 (and thus smaller payloads) to resynchronize state at their 203 endpoint compressor/decompressors. If the largest MTU is used to 204 calculate the value to advertise in the MSS option, TCP 205 retransmission may interfere with compressor resynchronization. 207 As a result, when the effective MTU of an interface varies, TCP 208 SHOULD use the smallest effective MTU of the interface to 209 calculate the value to advertise in the MSS option. 211 5.3 IPv6 Jumbograms 213 In order to support TCP over IPv6 Jumbograms, implementations need 214 to be able to send TCP segments larger than 64K. RFC 2675 215 [RFC2675] defines that a value of 65,535 is to be treated as 216 infinity, and Path MTU Discovery [RFC1981] is used to determine 217 the actual MSS. 219 5.4 Avoiding fragmentation 221 Packets that are too long will either be fragmented or dropped. 222 If packets are fragmented, intermediary firewalls or middle boxes 223 may drop the fragmented packets. In either case, when packets are 224 dropped the connection can fail; hence it is best to avoid 225 generating fragments. 227 6. Security Considerations 229 This document clarifies how to determine what value should be used 230 for the MSS option, and does not introduce any new security concerns. 232 7. IANA Considerations 234 This document has no actions for IANA. 236 8. References 238 Normative References 240 [RFC791] Postel, J., "Internet Protocol," RFC 791, September 1981. 242 [RFC793] Postel, J., "Transmission Control Protocol," RFC 793, 243 September 1981. 245 [RFC879] Postel, J., "The TCP Maximum Segment Size and Related 246 Topics", RFC 879, ISI, November 1983. 248 [RFC1122] Braden, R., editor, "Requirements for Internet Hosts -- 249 Communication Layers", RFC 1122, October, 1989. 251 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 252 (IPv6) Specification", RFC 2460, December, 1998. 254 [RFC2675] Borman, D., Deering, S., Hinden, R., "IPv6 Jumbograms", 255 RFC 2675, August, 1999. 257 Informative References 259 [Borman93] Borman, D., "TCP MSS & Timestamps", Message to the 260 tcplw mailing list, Jan 7, 1993. 262 [RFC1191] Mogul, J.C., Deering, S.E., "Path MTU discovery" RFC 263 1191, November 1990. 265 [RFC1981] McCann, J., Deering, S. and Mogul, J.,, "Path MTU 266 Discovery for IP Version 6", RFC 1981, August 1986. 268 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 269 Requirement Levels", RFC 2119, March 1997. 271 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP 272 MD5 Signature Option", RFC 2385, August 1988. 274 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 275 2923, September 2000. 277 [RFC4821] Mathis, M., Heffner, J., "Packetization Layer Path MTU 278 Discovery", RFC 4821, March 2007. 280 [RFC5795] Sandlund, K., Gelletier, G. and Jonsson, L-E., "The 281 RObust Header Compression (ROHC) Framework", RFC 5795, March 2010. 283 Appendix A: Details from RFC 793 and RFC 1122 285 RFC 793 [RFC793] defines the MSS option: 287 Maximum Segment Size Option Data: 16 bits 288 If this option is present, then it communicates the maximum 289 receive segment size at the TCP which sends this segment. 290 This field must only be sent in the initial connection request 291 (i.e., in segments with the SYN control bit set). If this 292 option is not used, any segment size is allowed. 294 RFC 1122 [RFC1122] provides additional clarification in section 295 4.2.2.6, pages 85-86. First, it changes the default behavior when 296 the MSS option is not present: 298 If an MSS option is not received at connection setup, TCP 299 MUST assume a default send MSS of 536 (576-40) [TCP:4]. 301 Then it clarifies how to determine the value to use in the MSS 302 option: 304 The MSS value to be sent in an MSS option must be less than 305 or equal to: 307 MMS_R - 20 309 where MMS_R is the maximum size for a transport-layer 310 message that can be received (and reassembled). TCP obtains 311 MMS_R and MMS_S from the IP layer; see the generic call 312 GET_MAXSIZES in Section 3.4. 314 What is implied, but not explicitly stated, is that the 20 is the 315 size of the fixed TCP header. The definition of MMS_R is found in 316 section 3.3.2 on page 57: 318 MMS_R is given by: 320 MMS_R = EMTU_R - 20 322 since 20 is the minimum size of an IP header. 324 and on page 56, also section 3.3.2: 326 We designate the largest datagram size that can be reassembled 327 by EMTU_R ("Effective MTU to receive"); this is sometimes 328 called the "reassembly buffer size". EMTU_R MUST be greater 329 than or equal to 576, SHOULD be either configurable or 330 indefinite, and SHOULD be greater than or equal to the MTU of 331 the connected network(s). 333 What should be noted here is that EMTU_R is the largest datagram size 334 that can be reassembled, not the largest datagram size that can be 335 received without fragmentation. Taking this literally, since most 336 modern TCP/IP implementations can reassemble a full 64K IP packet, 337 implementations should be using 65535 - 20 - 20, or 65495 for the MSS 338 option. But there is more to it than that, in RFC 1122 on page 86 it 339 also states: 341 The choice of TCP segment size has a strong effect on 342 performance. Larger segments increase throughput by 343 amortizing header size and per-datagram processing 344 overhead over more data bytes; however, if the packet 345 is so large that it causes IP fragmentation, efficiency 346 drops sharply if any fragments are lost [IP:9]. 348 Since it is guaranteed that any IP datagram that is larger than the 349 MTU of the connected network will have to be fragmented to be 350 received, implementations ignore the "greater than or" part of 351 "SHOULD be greater than or equal to the MTU of the connected 352 network(s)". Thus, the MSS value to be sent in an MSS option must be 353 less than or equal to: 355 EMTU_R - FixedIPhdrsize - FixedTCPhdrsize 357 where FixedTCPhdrsize is 20, and FixedIPhdrsize is 20 for IPv4 and 40 358 for IPv6. 360 Authors' Addresses 362 David Borman 363 Quantum Corporation 364 Mendota Heights, MN 55120 366 Email: david.borman@quantum.com 368 Full Copyright Statement 370 Copyright (c) 2012 IETF Trust and the persons identified as the 371 document authors. All rights reserved. 373 This document is subject to BCP 78 and the IETF Trust's Legal 374 Provisions Relating to IETF Documents 375 (http://trustee.ietf.org/license-info) in effect on the date of 376 publication of this document. Please review these documents 377 carefully, as they describe your rights and restrictions with respect 378 to this document. Code Components extracted from this document must 379 include Simplified BSD License text as described in Section 4.e of 380 the Trust Legal Provisions and are provided without warranty as 381 described in the Simplified BSD License.