idnits 2.17.1 draft-andrews-tcp-and-ipv6-use-minmtu-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (October 18, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 879 (Obsoleted by RFC 7805, RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Andrews 3 Internet-Draft ISC 4 Intended status: Informational October 18, 2015 5 Expires: April 20, 2016 7 TCP Fails To Respect IPV6_USE_MIN_MTU 8 draft-andrews-tcp-and-ipv6-use-minmtu-04 10 Abstract 12 The IPV6_USE_MIN_MTU socket option directs the IP layer to limit the 13 IPv6 packet size to the minimum required supported MTU from the base 14 IPv6 specification, i.e. 1280 bytes. Many implementations of TCP 15 running over IPv6 neglect to check the IPV6_USE_MIN_MTU value when 16 performing MSS negotiation and when constructing a TCP segment 17 despite MSS being defined to be the MTU less the IP and TCP header 18 sizes (60 bytes for IPv6). This leads to oversized IPv6 packets 19 being sent resulting in unintended Path Maximum Transport Unit 20 Discovery (PMTUD) being performed and to fragmented IPv6 packets 21 being sent. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 20, 2016. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Reserved Words . . . . . . . . . . . . . . . . . . . . . 2 59 2. MSS Negotiation . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Segment Size Calculation . . . . . . . . . . . . . . . . . . 3 61 4. Current Usage . . . . . . . . . . . . . . . . . . . . . . . . 3 62 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 3 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 65 8. Normative References . . . . . . . . . . . . . . . . . . . . 4 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1. Introduction 70 The IPV6_USE_MIN_MTU [RFC3542], Section 11.1, socket option directs 71 the IP layer to limit the IPv6 packet size to the minimum required 72 supported MTU from the base IPv6 specification [RFC2460], i.e. 1280 73 bytes. Many implementations of TCP running over IPv6 neglect to 74 check the IPV6_USE_MIN_MTU value when performing MSS negotiation and 75 when constructing a TCP segment despite MSS being defined to be the 76 MTU less the IP and TCP header sizes [RFC0879] (60 bytes for IPv6). 77 This leads to oversized IPv6 packets being sent resulting in 78 unintended Path Maximum Transport Unit Discovery (PMTUD) [RFC1191] 79 being performed and to fragmented IPv6 packets being sent. 81 TCP, when running over IPv6, SHOULD check the value of 82 IPV6_USE_MIN_MTU when performing MSS negotiation. TCP 83 implementations already use learnt PMTU and interface MTU when 84 performing MSS negotiation. This is yet another constraint on the 85 MTU which SHOULD be considered. 87 TCP, when running over IPv6, SHOULD check the value of 88 IPV6_USE_MIN_MTU when calculating the segment size to send. TCP 89 implementations already use learnt PMTU and interface MTU when 90 calculating the segment size to send. 92 1.1. Reserved Words 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 2. MSS Negotiation 100 TCP, when running over IPv6, SHOULD check the value of 101 IPV6_USE_MIN_MTU when performing MSS negotiation. If the value of 102 IPV6_USE_MIN_MTU is one (1) then the application has requested that 103 PMTUD not be performed on the socket and that IPv6 packets be sent at 104 a size no greater then the network minimum MTU of 1280 bytes. This 105 means that the TCP MSS negotiation size SHOULD be no bigger than 1220 106 (1280 - 40 - 20) to account for the IPv6 header and the TCP header 107 and MAY be smaller. 109 If this negotiation is properly performed then PMTUD of reply traffic 110 should not normally occur. 112 3. Segment Size Calculation 114 TCP, when running over IPv6, SHOULD check the value of 115 IPV6_USE_MIN_MTU when calculation the next segment to send. If the 116 value of IPV6_USE_MIN_MTU is one (1) them the maximum segment size 117 SHOULD be 1220. 119 If the TCP layer neglects to check the value of IPV6_USE_MIN_MTU and 120 it is one (1), the packet, when passed to the IPv6 layer, will be 121 fragmented if the resulting packet is bigger that 1280 octets. This 122 can result in communications failures due to intermediate nodes not 123 passing fragmented packets. 125 4. Current Usage 127 A example of current usage of IPV6_USE_MIN_MTU=1 and TCP is in DNS 128 nameservers. This is done as the TCP message streams are normally no 129 more than a couple of IPv6 packets so there is little benefit in 130 using maximum sized packet, and no real negative effects from using 131 smaller packets. There are lots of servers / clients that these 132 servers talk to and maintaining PMTU knowledge is not effective for 133 long enough resulting in PMTUD being repeated performed. There are 134 external time constraints where recovery from lost ICMPv6 PTB will 135 result in a elapsed transaction time that falls outside of the time 136 constraint window. 138 5. Acknowledgements 140 I would like to thank Havard Eidnes, Sander Steffann, John Leslie, 141 and Brian E Carpenter for their feedback. 143 6. Security Considerations 145 The document makes no changes that could impact on the security of a 146 IPv6 stack. 148 7. IANA Considerations 150 There are no actions for IANA. 152 8. Normative References 154 [RFC0879] Postel, J., "The TCP Maximum Segment Size and Related 155 Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, 156 . 158 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 159 DOI 10.17487/RFC1191, November 1990, 160 . 162 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 163 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 164 RFC2119, March 1997, 165 . 167 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 168 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 169 December 1998, . 171 [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, 172 "Advanced Sockets Application Program Interface (API) for 173 IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, 174 . 176 Author's Address 178 M. Andrews 179 Internet Systems Consortium 180 950 Charter Street 181 Redwood City, CA 94063 182 US 184 Email: marka@isc.org