idnits 2.17.1 draft-ietf-tcpm-tcpmss-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 13, 2009) is 5394 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 879 (ref. 'Postel83') (Obsoleted by RFC 7805, RFC 9293) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Network Working Group 3 Internet-Draft D. Borman 4 Intended Status: Informational Wind River Systems 5 File: draft-ietf-tcpm-tcpmss-02.txt July 13, 2009 7 TCP Options and MSS 9 Status of This Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on January 13, 2010. 32 Copyright 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 Abstract 39 This memo discusses what value to use with the TCP MSS option. 41 1. INTRODUCTION 43 There has been some confusion as to what value should be filled in 44 the TCP MSS option when using TCP options. RFC-879 [Postel83] 45 stated: 47 The MSS counts only data octets in the segment, it does not 48 count the TCP header or the IP header. 50 which is unclear about what to do about TCP options. RFC-1122 51 [Braden89] attempted to clarify this in section 4.2.2.6, but there 52 still seems to be confusion. Clarification was first sent to the TCP 53 Large Windows mailing list [Borman93] in 1993. 55 2. TCP Options and MSS 57 The MSS value to be sent in an MSS option should be equal to the 58 effective MTU minus the fixed IP and TCP headers. By ignoring both 59 IP and TCP options when calculating the value for the MSS option, if 60 there are any IP or TCP options to be sent in a packet, then the 61 sender must decrease the size of the TCP data accordingly. The 62 reason for this can be seen in the following table: 64 +--------------------+--------------------+ 65 | MSS is adjusted | MSS isn't adjusted | 66 | to include options | to include options | 67 +----------------+--------------------+--------------------+ 68 | Sender adjusts | Packets are too | Packets are the | 69 | length for | short | correct length | 70 | options | | | 71 +----------------+--------------------+--------------------+ 72 | Sender doesn't | Packets are the | Packets are too | 73 | adjust length | correct length | long. | 74 | for options | | | 75 +----------------+--------------------+--------------------+ 77 Since the goal is to not send IP datagrams that have to be 78 fragmented, and packets sent with the constraints in the lower right 79 of this grid will cause IP fragmentation, the only way to guarantee 80 that this doesn't happen is for the data sender to decrease the TCP 81 data length by the size of the IP and TCP options. It follows then, 82 that since the sender will be adjusting the TCP data length when 83 sending IP and TCP options, there is no need to include the IP and 84 TCP option lengths in the MSS value. 86 3. Security Considerations 88 Packets that are too long will either be fragmented or dropped. If 89 packets are fragmented, intermediary firewalls or middle boxes may 90 drop the fragmented packets. In either case, when packets are 91 dropped the connection can fail; hence it is best to avoid generating 92 fragments. 94 4. IANA Considerations 96 This document has no actions for IANA. 98 5. References 100 Informative References 102 [Braden89] Braden, R., editor, "Requirements for Internet Hosts -- 103 Communication Layers", RFC-1122, October, 1989 105 [Postel83] Postel, J., "The TCP Maximum Segment Size and Related 106 Topics", RFC-879, ISI, November 1983. 108 [Borman93] Borman, D., "TCP MSS & Timestamps", Message to tcplw 109 mailing list, Jan 7, 1993. 111 Authors' Addresses 113 David Borman 114 Wind River Systems 115 Mendota Heights, MN 55120 117 Phone: (651) 454-3052 118 Email: david.borman@windriver.com 120 Full Copyright Statement 122 Copyright (c) 2009 IETF Trust and the persons identified as the 123 document authors. All rights reserved. 125 This document is subject to BCP 78 and the IETF Trust's Legal 126 Provisions Relating to IETF Documents in effect on the date of 127 publication of this document (http://trustee.ietf.org/license-info). 128 Please review these documents carefully, as they describe your rights 129 and restrictions with respect to this document.