idnits 2.17.1 draft-naito-nat-time-wait-reduction-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 112: '... A TCP server MAY accept a TCP SYN f...' RFC 2119 keyword, line 157: '...n clients. This MAY be done by distri...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 3, 2012) is 4243 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Naito 3 Internet-Draft A. Matsumoto 4 Intended status: Informational NTT 5 Expires: March 7, 2013 September 3, 2012 7 NAT TIME_WAIT reduction 8 draft-naito-nat-time-wait-reduction-02 10 Abstract 12 When network address translation (NAT) is used in an address resource 13 restricted environment, or when a lot of users are located under a 14 NAT device, IP addresses and port resources may be eaten up, and this 15 affects user experiences very negatively. This situation can be 16 greatly mitigated by tweaking mapping behavior and session timer 17 handling in NAT functions. This document proposes extension for 18 optimizing NAT IP address and port resources in address resource 19 restricted environments. The extension makes use of TCP timestamps 20 and sequence numbers for TIME_WAIT assassination. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on March 7, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 1. Introduction 68 After IPv4 addresses run out, IPv4 address resources will be further 69 restricted site-by-site. If global IPv4 address are shared between 70 several clients, assignable port resources at each client will be 71 limited. 73 NAT is a tool that is widely used to deal with this IPv4 address 74 shortage problem. However, the demand for resources to provide 75 Internet access to users and devices will continue to increase. IPv6 76 is a fundamental solution to this problem, but the deployment of IPv6 77 will take time. 79 In some cases, e.g. browsing a dynamic web page for a map service, a 80 lot of sessions are used by the browser, and a number of ports are 81 eaten up in a short time. What is worse is that when a NAT is 82 between a PC and a server, TIME_WAIT state of each TCP connection is 83 kept for certain period, typically for four minutes, which consumes 84 port resources. Therefore, new connections cannot be established. 86 This problem is caused or worsened by the following behavior. 88 TIME_WAIT state assigned for a TCP connection remains active for 89 2MSL after the last ACK to the last FIN is transferred. 91 We propose mechanisms to change the above behavior that make it 92 possible to save addresses and ports resources. 94 1.1. TCP TIME_WAIT 96 The TCP TIME_WAIT state is described in RFC793 [RFC0793]. The TCP 97 TIME_WAIT state needs to be kept for 2MSL before a connection is 98 CLOSED, for the reasons below. 100 1: In the event that packets from a session are delayed in the in- 101 between network, and delivered to the end relatively later, we 102 should prevent the packets from being transferred and interpreted 103 as a packet that belongs to a new session. 104 2: If the remote TCP has not received the acknowledgment of its 105 connection termination request, it will re-send the FIN packet 106 several times. 108 These points are important for the TCP to work without problems. 110 1.2. TIME_WAIT Assassination 112 A TCP server MAY accept a TCP SYN for the 5-tuple session that is 113 just finished and marked as TIME_WAIT state,as far as the TCP 114 sequence number is increased. This is known as TIME-WAIT 115 assassination. It should also be noted that some assassination 116 hazards are described in RFC1337 [RFC1337]. 118 1.3. Protect Against Wrapped Sequence numbers (PAWS) 120 The TCP sequence number wraps frequently especially in a high 121 bandwidth session. PAWS is used to prevent old duplicate packets 122 that occurred in a previous session from being transferred to the new 123 session whose valid TCP sequence numbers happen to overlap with the 124 old duplicate packets. This is implemented by introducing TCP 125 timestamp option, and checking the timestamp option value of each 126 packet. PAWS is described in RFC1323 [RFC1323]. 128 2. NAT resource optimizing extension proposal 130 2.1. Apply RFC6191 to NAT 132 RFC 6191 [RFC6191] defines a mechanism for reducing the TIME_WAIT 133 state using TCP timestamps and sequence numbers. This document 134 proposes to apply this RFC6191 [RFC6191] mechanism at NAT. By 135 tracing timestamp and sequence number values in NAT that manages 136 states of traversing TCP sessions, a TIME_WAIT remaining wait-time 137 can be reduced to zero, when a TCP-SYN packet carrying a larger 138 timestamp or sequence number value arrives. In this case, PAWS works 139 to discard old duplicate packets at NAT. A packet can be discarded 140 as an old duplicate if it is received with a timestamp or sequence 141 number value less than a value recently received on the connection. 142 When there are several clients with nonsuccessive timestamp or 143 sequence number values are connected to a NAT device (i.e. not 144 monotonically increasing among clients), it prevents some clients 145 from getting a port to start a connection for a long time because 146 other clients with larger timestamp or sequence number values are 147 preferred. Two workarounds for this issue are described below. 149 2.1.1. Rewrite timestamp and sequence number values at NAT 151 Rewrite timestamp and sequence number values of outgoings packets at 152 NAT to be monotonically increasing. 154 2.1.2. Split an assignable number of port space to each client 156 Set some rules among clients connecting to NAT, e.g., split 157 assignable ports between clients. This MAY be done by distributing 158 rules to clients via NAT. 160 2.2. Resend the last ACK to the resended FIN 162 In case the remote TCP could not receive the acknowledgment of its 163 connection termination request, NAT, on behalf of clients. resends 164 the last ACK packet when it recieves an FIN packet of the previous 165 connection, and when the state of the previous connection is deleted 166 from the NAT. This mechanism should be used when clients starts 167 closing process, and the remote host could not receive the last ACK. 169 2.3. Remote host behavior of several implementations 171 To solve the port shortage problem on the client side, the behavior 172 of remote host should be compliant to RFC 6191 [RFC6191] or the 173 mechanism written in 4.2.2.13 of RFC1122 [RFC1122], since NAT may 174 reuse the same 5 tuple for a new connection.We have investigated 175 behaviors of OSes (e.g., Linux, FreeBSD, Windows, MacOS), and found 176 that they implemented the server side behavior of the above two. 178 3. Security Considerations 180 Security issues are not discussed in this memo. 182 4. Normative References 184 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 185 RFC 793, September 1981. 187 [RFC1122] Braden, R., "Requirements for Internet Hosts - 188 Communication Layers", STD 3, RFC 1122, October 1989. 190 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 191 for High Performance", RFC 1323, May 1992. 193 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 194 RFC 1337, May 1992. 196 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 197 Timestamps", BCP 159, RFC 6191, April 2011. 199 Appendix A. Revision History 201 02: Changed intended status to "informational". 203 01: 'draft-naito-nat-resource-optimizing-extension-01' was divided 204 into two drafts after IETF83 meeting. 205 'draft-naito-nat-resource-optimizing-extension-01' containes two 206 mechanisms. One mechanism, TIME_WAIT reduction is written in this 207 draft, and the other is written in 208 'draft-naito-nat-port-overlapping'. 210 Authors' Addresses 212 Kengo Naito 213 NTT NT Lab 214 3-9-11 Midori-Cho 215 Musashino-shi, Tokyo 180-8585 216 Japan 218 Phone: +81 422 59 4949 219 Email: naito.kengo@lab.ntt.co.jp 221 Arifumi Matsumoto 222 NTT NT Lab 223 3-9-11 Midori-Cho 224 Musashino-shi, Tokyo 180-8585 225 Japan 227 Phone: +81 422 59 3334 228 Email: arifumi@nttv6.net