idnits 2.17.1 draft-naito-nat-time-wait-reduction-03.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...' 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 24, 2012) is 4232 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 28, 2013 September 24, 2012 7 NAT TIME_WAIT reduction 8 draft-naito-nat-time-wait-reduction-03 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 28, 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. In case 135 there are several clients with nonsuccessive timestamp or sequence 136 number values are connected to a NAT device (i.e. not monotonically 137 increasing among clients), two mechanisms for applying RFC6191 to NAT 138 are described below. Also, PAWS works to discard old duplicate 139 packets at NAT. A packet can be discarded as an old duplicate if it 140 is received with a timestamp or sequence number value less than a 141 value recently received on the connection. 143 2.2. Rewrite timestamp and sequence number values at NAT 145 Rewrite timestamp and sequence number values of outgoings packets at 146 NAT to be monotonically increasing. This can be done by adopting 147 following mechanisms at NAT. 149 A: Store the newest rewritten value of timestamp and sequence number 150 as the 'max value at the time' 151 B: NAT rewrite timestamp and sequence number values of incoming 152 packets to be monotonically increasing. 154 When packets come back as replies from remote hosts, NAT rewrite 155 again the packets' timestamp and sequence number values to be the 156 original values. This can be done by adopting following mechanisms 157 at NAT. 159 C: Store the values of original timestamp and sequence number of 160 packets, and rewritten values of those. 162 2.3. Split an assignable number of port space to each client 164 Adopt following mechanisms at NAT. 166 A: Choose clients that can be assigned ports. 167 B: Split assignable port numbers between clients. 169 Packets from other clients which are not chosen by these mechanisms 170 are rejected at NAT, unless there is unassigned port left. 172 2.4. Resend the last ACK to the resended FIN 174 In case the remote TCP could not receive the acknowledgment of its 175 connection termination request, NAT, on behalf of clients. resends 176 the last ACK packet when it recieves an FIN packet of the previous 177 connection, and when the state of the previous connection is deleted 178 from the NAT. This mechanism should be used when clients starts 179 closing process, and the remote host could not receive the last ACK. 181 2.5. Remote host behavior of several implementations 183 To solve the port shortage problem on the client side, the behavior 184 of remote host should be compliant to RFC 6191 [RFC6191] or the 185 mechanism written in 4.2.2.13 of RFC1122 [RFC1122], since NAT may 186 reuse the same 5 tuple for a new connection.We have investigated 187 behaviors of OSes (e.g., Linux, FreeBSD, Windows, MacOS), and found 188 that they implemented the server side behavior of the above two. 190 3. Security Considerations 192 Security issues are not discussed in this memo. 194 4. Normative References 196 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 197 RFC 793, September 1981. 199 [RFC1122] Braden, R., "Requirements for Internet Hosts - 200 Communication Layers", STD 3, RFC 1122, October 1989. 202 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 203 for High Performance", RFC 1323, May 1992. 205 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 206 RFC 1337, May 1992. 208 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 209 Timestamps", BCP 159, RFC 6191, April 2011. 211 Appendix A. Revision History 213 02: Changed intended status to "informational". 215 01: 'draft-naito-nat-resource-optimizing-extension-01' was divided 216 into two drafts after IETF83 meeting. 217 'draft-naito-nat-resource-optimizing-extension-01' containes two 218 mechanisms. One mechanism, TIME_WAIT reduction is written in this 219 draft, and the other is written in 220 'draft-naito-nat-port-overlapping'. 222 Authors' Addresses 224 Kengo Naito 225 NTT NT Lab 226 3-9-11 Midori-Cho 227 Musashino-shi, Tokyo 180-8585 228 Japan 230 Phone: +81 422 59 4949 231 Email: naito.kengo@lab.ntt.co.jp 233 Arifumi Matsumoto 234 NTT NT Lab 235 3-9-11 Midori-Cho 236 Musashino-shi, Tokyo 180-8585 237 Japan 239 Phone: +81 422 59 3334 240 Email: arifumi@nttv6.net