idnits 2.17.1 draft-naito-nat-resource-optimizing-extension-00.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 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 127: '.... In such case, this mechanism SHOULD...' RFC 2119 keyword, line 128: '...n RFC5382. i.e. REQ-1:A NAT MUST have...' RFC 2119 keyword, line 142: '...lue of timestamp SHOULD be successive....' RFC 2119 keyword, line 143: '... (timestamps MAY be overwritten in N...' 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 (March 2012) is 4417 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 154, but no explicit reference was found in the text == Unused Reference: 'RFC1323' is defined on line 157, but no explicit reference was found in the text == Unused Reference: 'RFC5382' is defined on line 160, but no explicit reference was found in the text == Unused Reference: 'RFC6191' is defined on line 164, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 K. Naito 3 Internet-Draft A. Matsumoto 4 Intended status: Informational NTT 5 Expires: September 4, 2012 March 2012 7 NAT resource optimizing extension 8 draft-naito-nat-resource-optimizing-extension-00 10 Abstract 12 When NAT is used in address resource restricted environment, or when 13 a lot of users are located under a NAT device, IP address and port 14 resources may be eaten up, and it brings severe bad effects on user 15 experiences. This situation can be greatly mitigated by tweaking 16 mapping behavior and session timer handling at NAT function. This 17 document proposes to NAT IP address and port resource optimizing 18 extension for address resource restricted environment. One extension 19 is to enable simultaneous use of a port for different transport 20 sessions, and the other is to make use of TCP timestamp for TIME_WAIT 21 Assassination. 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 August 4, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 1. Introduction 69 The internet has run out of IPv4 addresses, and after that IPv4 70 addresses that can be allocated to a user will be much more 71 restricted. NAT is a tool that is widely used for this problem of 72 IPv4 address shortage. However, there will be more and more demands 73 for resources to provide the Internet access to the users and 74 devices. IPv6 is a fundamental solution for this problem, but the 75 deployment of IPv6 takes time. 77 In some cases, e.g. browsing a dynamic web page for a map service, a 78 lot of sessions are used by the browser, and a number of ports are 79 eaten up in short time. What is worse is that when a NAT is in 80 between, the NAT keeps track of each session for long time, typically 81 for four minutes, even if the session is terminated by both ends 82 within a few seconds. 84 This problem is caused or worsened by the following behaviors of NAT. 86 1. In a lot of NAT implementation, a port that is available at NAT 87 is allocated or a transport session. i.e. a NAT does not use a port 88 for multiple sessions simultaneously. 90 2.TCP TIME_WAIT state requires 2*MSL wait before a session is closed, 91 So at a NAT device many session states are kept, even if both ends of 92 a session have closed and deleted the state for the session. 94 We propose two mechanisms to change the above behaviors of NAT that 95 enables to save addresses and ports resources. 97 1.1. TCP TIME_WAIT 99 TCP TIME_WAIT mechanism is written in RFC793. TCP TIME_WAIT status 100 requires 2*MSL to wait before connection to be CLOSED, in case: 102 1.Packet in previous session be transfered later 103 2.Retransmission of ACK packet(which is respond to FIN) is needed. 105 In case 1, the old packet should be discarded, not to harm new session. 106 In case 2, retransmission should be done to close destination port. 107 If TIME_WAIT mechanism do not work, TCP transmission problem may happen. 109 1.2. TIME_WAIT Assassination 111 The server may accept the TCP SYN from the client change the state of 112 the port from TCP TIME-WAIT to TCP Established. This is known as 113 TIME-WAIT assassination. 115 1.3. PAWS(Protect Against Wrapped Sequence numbers) 117 PAWS(Protect Against Wrapped Sequence numbers) is written in RFC1323. 118 PAWS is used to prevent packet in previous session be transfered to 119 the new session. 121 2. Proposal 123 2.1. Adopt Intended Port over-use mechanism 125 To use single port for several connections, over-use port. For 126 example, if destination address differ in two connections, use single 127 port for NAT port assignment. In such case, this mechanism SHOULD 128 meet the requirement written in RFC5382. i.e. REQ-1:A NAT MUST have 129 an "Endpoint-Independent Mapping" behavior for TCP. 130 (There may be some other violations to adopt this, which I'll consider 131 and write by IETF83 Paris) 133 2.2. Adopt RFC6191 to NAT 135 To make connection re-usable for TCP transmission(e.g. http 136 transmission) in address resource restricted network, force port 137 state to be CLOSED, as soon as a session have finished(i.e. port is 138 in TCP TIME_WAIT state), if there are any SYN-WAIT state for new 139 session, waiting for port to be released. 140 This mechanism is written in RFC6191. 141 To make this mechanism work in network that several PCs connected to 142 the NAT equipment, value of timestamp SHOULD be successive. 143 (timestamps MAY be overwritten in NAT equipment, so that timestamp 144 in each packet that go through NAT equipment be successive.) 145 Also, consideration of some transmission pattern and effect is 146 needed. 147 (I'll consider patterns, and write by IETF83 Paris) 149 3. Security Considerations 150 (I'll write some by IETF83, Paris.) 152 4. Normative References 154 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 155 RFC 793, September 1981. 157 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 158 for High Performance", RFC 1323, May 1992. 160 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 161 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 162 RFC 5382, October 2008. 164 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 165 Timestamps", BCP 159, RFC 6191, April 2011. 167 Authors' Addresses 169 Kengo Naito 170 NTT SI Lab 171 3-9-11 Midori-Cho 172 Musashino-shi, Tokyo 180-8585 173 Japan 175 Phone: +81 422 59 4949 176 Email: naito.kengo@lab.ntt.co.jp 178 Arifumi Matsumoto 179 NTT SI Lab 180 3-9-11 Midori-Cho 181 Musashino-shi, Tokyo 180-8585 182 Japan 184 Phone: +81 422 59 3334 185 Email: arifumi@nttv6.net