Skip to main content

TCP Options and Maximum Segment Size (MSS)

Approval announcement
Draft of message to be sent after approval:


From: The IESG <>
To: IETF-Announce <>
Cc: RFC Editor <>,
    tcpm mailing list <>,
    tcpm chair <>
Subject: Document Action: 'TCP Options and MSS' to Informational RFC (draft-ietf-tcpm-tcpmss-05.txt)

The IESG has approved the following document:
- 'TCP Options and MSS'
  (draft-ietf-tcpm-tcpmss-05.txt) as Informational RFC

This document is the product of the TCP Maintenance and Minor Extensions
Working Group.

The IESG contact persons are Wesley Eddy and Martin Stiemerling.

A URL of this Internet Draft is:

Ballot Text

Technical Summary

This memo discusses what value to use with the TCP MSS option, and
updates RFC 879 and RFC 2385. There has been some confusion as to what
value should be filled in the TCP MSS option when using IP and TCP
options. 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.

Working Group Summary

This document was written to clarify statements in the TCP standards,
given that implementors asked for better guidance of what is already
known for many years. The document represents the consensus of the
TCPM working group and addresses all feedback in the working group
and during/after the last call.

Document Quality

This is a short document that can be summarized by a single sentence
(in section 2). The rest of this document just explains the
rationale of what is implied by the TCP standard documents. The MSS
option is implemented in all known TCP stacks. It has been reported
in the past that some implementations handled the MSS option
differently. Due to the resulting risk of packet fragmentation it
can be assumed that all modern TCP stacks comply to what the document


The Document Shepherd is Michael Scharf <>.
The Responsible Area Director is Wesley Eddy <>.

RFC Editor Note