draft-ietf-tcpm-tcpmss-04.txt   draft-ietf-tcpm-tcpmss-05.txt 
Network Working Group Network Working Group Network Working Group Network Working Group
Internet-Draft D. Borman Internet-Draft D. Borman
Updates: 879, 2385 Quantum Corporation Updates: 879, 2385 Quantum Corporation
Intended Status: Informational March 27, 2012 Intended Status: Informational June 7, 2012
File: draft-ietf-tcpm-tcpmss-04.txt File: draft-ietf-tcpm-tcpmss-05.txt
TCP Options and MSS TCP Options and MSS
Abstract Abstract
This memo discusses what value to use with the TCP MSS option, and This memo discusses what value to use with the TCP Maximum Segment
updates RFC 879 and RFC 2385. Size (MSS) option, and updates RFC 879 and RFC 2385.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on September 27, 2012. This Internet-Draft will expire on December 7, 2012.
Copyright Copyright
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
1. Introduction 1. Introduction
There has been some confusion as to what value should be filled in There has been some confusion as to what value should be filled in
the TCP MSS option when using IP and TCP options. RFC 879 [RFC879] the TCP MSS option when using IP and TCP options. RFC 879 [RFC879]
stated: stated:
The MSS counts only data octets in the segment, it does not The MSS counts only data octets in the segment, it does not
count the TCP header or the IP header. count the TCP header or the IP header.
which is unclear about what to do about IP and TCP options, since which is unclear about what to do about IP and TCP options, since
they are part of the headers. RFC 1122 [RFC1122] clarified the MSS they are part of the headers. RFC 1122 [RFC1122] clarified the MSS
option (see Appendix A), but there still seems to be some confusion. option, which is discussed in Appendix A, but there still seems to be
some confusion.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
document are to be interpreted as described in RFC 2119 [RFC2119]. in this document are to be interpreted as described in RFC 2119
[RFC2119].
2. The Short Statement 2. The Short Statement
When calculating the value to put in the TCP MSS option, the MTU 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 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 headers, and SHOULD NOT be decreased to account for any possible IP
or TCP options; conversely, the sender MUST reduce the TCP data 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 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 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 on that statement, and the goal is to avoid IP level fragmentation of
TCP packets. TCP packets.
The size of the fixed TCP header is 20 bytes [RFC793], the size 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 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 IPv6 header is 40 bytes [RFC2460]. The determination of what MTU
value should be used, especially in the case of multi-homed hosts, is value should be used, especially in the case of multi-homed hosts, is
beyond the scope of this document. beyond the scope of this document.
3. MSS in to other RFCs 3. MSS in other RFCs
3.1 RFC 879 3.1 RFC 879
RFC 879 [RFC879] discusses the MSS option and other topics. In RFC 879 [RFC879] discusses the MSS option and other topics. In
the introduction, it states: the introduction, it states:
"THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE "THE TCP MAXIMUM SEGMENT SIZE IS THE IP MAXIMUM DATAGRAM SIZE
MINUS FORTY." MINUS FORTY."
and in section 13, it states: and in section 13, it states:
skipping to change at page 3, line 44 skipping to change at page 3, line 48
the other side during connection negotiation. Specifically, the other side during connection negotiation. Specifically,
the size of the header to subtract from the MTU (whether it is the size of the header to subtract from the MTU (whether it is
the MTU of the outgoing interface or IP's minimal MTU of 576 the MTU of the outgoing interface or IP's minimal MTU of 576
bytes) is now at least 18 bytes larger." bytes) is now at least 18 bytes larger."
This is incorrect, the value for the MSS option is only adjusted This is incorrect, the value for the MSS option is only adjusted
by the fixed IP and TCP headers. by the fixed IP and TCP headers.
4. Clarification from the TCP Large Windows mailing list 4. Clarification from the TCP Large Windows mailing list
Additional clarification was sent to the TCP Large Windows mailing The initial clarification was sent to the TCP Large Windows mailing
list in 1993 [Borman93]. list in 1993 [Borman93]; this section is based on that message.
The MSS value to be sent in an MSS option should be equal to the 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 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 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 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 sender must decrease the size of the TCP data accordingly. The
reason for this can be seen in the following table: reason for this can be seen in the following table:
+--------------------+--------------------+ +--------------------+--------------------+
| MSS is adjusted | MSS isn't adjusted | | MSS is adjusted | MSS isn't adjusted |
| to include options | to include options | | to include options | to include options |
+--------------------+--------------------+--------------------+ +--------------------+--------------------+--------------------+
| Sender adjusts | Packets are too | Packets are the | | Sender adjusts | Packets are too | Packets are the |
| packet length | short | correct length | | packet length | short | correct length |
| for options | | | | for options | | |
+--------------------+--------------------+--------------------+ +--------------------+--------------------+--------------------+
| Sender doesn't | Packets are the | Packets are too | | Sender doesn't | Packets are the | Packets are too |
| adjust packet | correct length | long. | | adjust packet | correct length | long |
| length for options | | | | length for options | | |
+--------------------+--------------------+--------------------+ +--------------------+--------------------+--------------------+
The goal is to not send IP datagrams that have to be fragmented, and 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 packets sent with the constraints in the lower right of this grid
will cause IP fragmentation. Since the sender doesn't know if the will cause IP fragmentation. Since the sender doesn't know if the
received MSS option was adjusted to include options, the only way to received MSS option was adjusted to include options, the only way to
guarantee that the packets are not too long is for the data sender to guarantee that the packets are not too long is for the data sender to
decrease the TCP data length by the size of the IP and TCP options. 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 It follows then, that since the sender will be adjusting the TCP data
skipping to change at page 5, line 25 skipping to change at page 5, line 29
calculate the value to advertise in the MSS option. calculate the value to advertise in the MSS option.
5.3 IPv6 Jumbograms 5.3 IPv6 Jumbograms
In order to support TCP over IPv6 Jumbograms, implementations need In order to support TCP over IPv6 Jumbograms, implementations need
to be able to send TCP segments larger than 64K. RFC 2675 to be able to send TCP segments larger than 64K. RFC 2675
[RFC2675] defines that a value of 65,535 is to be treated as [RFC2675] defines that a value of 65,535 is to be treated as
infinity, and Path MTU Discovery [RFC1981] is used to determine infinity, and Path MTU Discovery [RFC1981] is used to determine
the actual MSS. the actual MSS.
5.4 Avoiding fragmentation
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.
6. Security Considerations 6. Security Considerations
Packets that are too long will either be fragmented or dropped. If This document clarifies how to determine what value should be used
packets are fragmented, intermediary firewalls or middle boxes may for the MSS option, and does not introduce any new security concerns.
drop the fragmented packets. In either case, when packets are
dropped the connection can fail; hence it is best to avoid generating
fragments.
7. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
8. References 8. References
Informative References Normative References
[Borman93] Borman, D., "TCP MSS & Timestamps", Message to the
tcplw mailing list, Jan 7, 1993.
[RFC791] Postel, J., "Internet Protocol," RFC 791, September 1981. [RFC791] Postel, J., "Internet Protocol," RFC 791, September 1981.
[RFC793] Postel, J., "Transmission Control Protocol," RFC 793, [RFC793] Postel, J., "Transmission Control Protocol," RFC 793,
September 1981. September 1981.
[RFC879] Postel, J., "The TCP Maximum Segment Size and Related [RFC879] Postel, J., "The TCP Maximum Segment Size and Related
Topics", RFC 879, ISI, November 1983. Topics", RFC 879, ISI, November 1983.
[RFC1122] Braden, R., editor, "Requirements for Internet Hosts -- [RFC1122] Braden, R., editor, "Requirements for Internet Hosts --
Communication Layers", RFC 1122, October, 1989. Communication Layers", RFC 1122, October, 1989.
[RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December, 1998.
[RFC2675] Borman, D., Deering, S., Hinden, R., "IPv6 Jumbograms",
RFC 2675, August, 1999.
Informative References
[Borman93] Borman, D., "TCP MSS & Timestamps", Message to the
tcplw mailing list, Jan 7, 1993.
[RFC1191] Mogul, J.C., Deering, S.E., "Path MTU discovery" RFC [RFC1191] Mogul, J.C., Deering, S.E., "Path MTU discovery" RFC
1191, November 1990. 1191, November 1990.
[RFC1981] McCann, J., Deering, S. and Mogul, J.,, "Path MTU [RFC1981] McCann, J., Deering, S. and Mogul, J.,, "Path MTU
Discovery for IP Version 6", RFC 1981, August 1986. Discovery for IP Version 6", RFC 1981, August 1986.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP
MD5 Signature Option", RFC 2385, August 1988. MD5 Signature Option", RFC 2385, August 1988.
[RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December, 1998.
[RFC2675] Borman, D., Deering, S., Hinden, R., "IPv6 Jumbograms",
RFC 2675, August, 1999.
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000. 2923, September 2000.
[RFC4821] Mathis, M., Heffner, J., "Packetization Layer Path MTU [RFC4821] Mathis, M., Heffner, J., "Packetization Layer Path MTU
Discovery", RFC 4821, March 2007. Discovery", RFC 4821, March 2007.
[RFC5795] Sandlund, K., Gelletier, G. and Jonsson, L-E., "The [RFC5795] Sandlund, K., Gelletier, G. and Jonsson, L-E., "The
RObust Header Compression (ROHC) Framework", RFC 5795, March 2010. RObust Header Compression (ROHC) Framework", RFC 5795, March 2010.
Appendix A: Details from RFC 793 and RFC 1122 Appendix A: Details from RFC 793 and RFC 1122
 End of changes. 14 change blocks. 
29 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/