Network Working Group Network Working Group
Internet-Draft D. Borman
Intended Status: Informational Wind River Systems
File: draft-ietf-tcpm-tcpmss-02.txt July 13, 2009
TCP Options and MSS
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 13, 2010.
Copyright
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Abstract
This memo discusses what value to use with the TCP MSS option.
1. INTRODUCTION
There has been some confusion as to what value should be filled in
the TCP MSS option when using TCP options. RFC-879 [Postel83]
stated:
Network Working Group Expires January 13, 2010 [Page 1]
Internet-Draft TCP Options and MSS July 2009
The MSS counts only data octets in the segment, it does not
count the TCP header or the IP header.
which is unclear about what to do about TCP options. RFC-1122
[Braden89] attempted to clarify this in section 4.2.2.6, but there
still seems to be confusion. Clarification was first sent to the TCP
Large Windows mailing list [Borman93] in 1993.
2. TCP Options and MSS
The MSS value to be sent in an MSS option should be equal to the
effective MTU minus the fixed IP and TCP headers. By ignoring both
IP and TCP options when calculating the value for the MSS option, if
there are any IP or TCP options to be sent in a packet, then the
sender must decrease the size of the TCP data accordingly. The
reason for this can be seen in the following table:
+--------------------+--------------------+
| MSS is adjusted | MSS isn't adjusted |
| to include options | to include options |
+----------------+--------------------+--------------------+
| Sender adjusts | Packets are too | Packets are the |
| length for | short | correct length |
| options | | |
+----------------+--------------------+--------------------+
| Sender doesn't | Packets are the | Packets are too |
| adjust length | correct length | long. |
| for options | | |
+----------------+--------------------+--------------------+
Since the goal is to not send IP datagrams that have to be
fragmented, and packets sent with the constraints in the lower right
of this grid will cause IP fragmentation, the only way to guarantee
that this doesn't happen is for the data sender to decrease the TCP
data length by the size of the IP and TCP options. It follows then,
that since the sender will be adjusting the TCP data length when
sending IP and TCP options, there is no need to include the IP and
TCP option lengths in the MSS value.
3. Security Considerations
Packets that are too long will either be fragmented or dropped. If
packets are fragmented, intermediary firewalls or middle boxes may
drop the fragmented packets. In either case, when packets are
dropped the connection can fail; hence it is best to avoid generating
fragments.
4. IANA Considerations
This document has no actions for IANA.
Network Working Group Expires January 13, 2010 [Page 2]
Internet-Draft TCP Options and MSS July 2009
5. References
Informative References
[Braden89] Braden, R., editor, "Requirements for Internet Hosts --
Communication Layers", RFC-1122, October, 1989
[Postel83] Postel, J., "The TCP Maximum Segment Size and Related
Topics", RFC-879, ISI, November 1983.
[Borman93] Borman, D., "TCP MSS & Timestamps", Message to tcplw
mailing list, Jan 7, 1993.
Authors' Addresses
David Borman
Wind River Systems
Mendota Heights, MN 55120
Phone: (651) 454-3052
Email: david.borman@windriver.com
Full Copyright Statement
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Network Working Group Expires January 13, 2010 [Page 3]