Internet Engineering Task Force (IETF) D. Borman
Request for Comments: 6691 Quantum Corporation
Updates: 879, 2385 July 2012
TCP Options and Maximum Segment Size (MSS)
This memo discusses what value to use with the TCP Maximum Segment
Size (MSS) option, and updates RFC 879 and RFC 2385.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Borman Informational [Page 1]RFC 6691 TCP Options and MSS July 20121. Introduction
There has been some confusion as to what value to use with the TCP
MSS option when using IP and TCP options. RFC 879 [RFC879] states:
The MSS counts only data octets in the segment, it does not count
the TCP header or the IP header.
This statement is unclear about what to do about IP and TCP options,
since they are part of the headers. RFC 1122 [RFC1122] clarified the
MSS option, which is discussed in Appendix A, but there still seems
to be some confusion.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. The Short Statement
When calculating the value to put in the TCP MSS option, the MTU
value SHOULD be decreased by only the size of the fixed IP and TCP
headers and SHOULD NOT be decreased to account for any possible IP or
TCP options; conversely, the sender MUST reduce the TCP data length
to account for any IP or TCP options that it is including in the
packets that it sends. The rest of this document just expounds on
that statement, and the goal is to avoid IP-level fragmentation of
The size of the fixed TCP header is 20 bytes [RFC793], the size of
the fixed IPv4 header is 20 bytes [RFC791], and the size of the fixed
IPv6 header is 40 bytes [RFC2460]. The determination of what MTU
value should be used, especially in the case of multi-homed hosts, is
beyond the scope of this document.
3. MSS in Other RFCs3.1. RFC 879
RFC 879 [RFC879] discusses the MSS option and other topics. In the
Introduction, it states:
THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE MINUS
Borman Informational [Page 2]RFC 6691 TCP Options and MSS July 2012
In Section 13, it states:
The definition of the MSS option can be stated:
The maximum number of data octets that may be received by the
sender of this TCP option in TCP segments with no TCP header
options transmitted in IP datagrams with no IP header options.
These are both correct. However, in the next paragraph -- in
Section 14 -- it then confuses this by stating that the consequence
When TCP is used in a situation when either the IP or TCP headers
are not minimum and yet the maximum IP datagram that can be
received remains 576 octets then the TCP Maximum Segment Size