TCP Options and Maximum Segment Size (MSS)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, tcpm mailing list <email@example.com>, tcpm chair <firstname.lastname@example.org> 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: http://datatracker.ietf.org/doc/draft-ietf-tcpm-tcpmss/
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 clarifies. Personnel The Document Shepherd is Michael Scharf <email@example.com>. The Responsible Area Director is Wesley Eddy <firstname.lastname@example.org>.