idnits 2.17.1 draft-naito-nat-port-overlapping-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.) ** 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 100: '...cal clients, NAT MAY assign the same e...' 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 (July 9, 2012) is 4280 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC0793' is defined on line 126, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 3 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: January 10, 2013 July 9, 2012 7 NAT Port Overlapping 8 draft-naito-nat-port-overlapping-00 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 enables simultaneous use of a 20 NAT external port for different transport sessions. 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 January 10, 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 In a lot of NAT implementations, a port that is available in NAT 89 is allocated for a transport session.That is, a NAT does not use a 90 port for multiple sessions simultaneously. 92 We propose mechanisms to change the above behavior that make it 93 possible to save addresses and ports resources. 95 2. NAT resource optimizing extension proposal 97 2.1. Apply Port Overlapping mechanism 99 If destination addresses and ports are different at the outgoing 100 sessions started by local clients, NAT MAY assign the same external 101 port as the source ports at the sessions. Port overlapping mechanism 102 manages mappings between external packets and internal packets by 103 looking at and storing the 5-tuple (protocol, source address, source 104 port, destination address, destination port) of them. Thus, enables 105 concurrent use of single port for multiple transport sessions, which 106 enables NAT to work correctly in IP address resource limited network. 108 Discussions: 110 RFC4787 [RFC4787] and RFC5382 [RFC5382] requires "endpoint- 111 independent mapping" at NAT, and port overlapping NAT cannot meet 112 therequirement. This mechanism can degrade the transparency of NAT 113 in that its mapping mechanism is endpoint-dependent and makes NAT 114 traversal harder. However, if a NAT adopts endpoint-independent 115 mapping together with endpoint-dependent filtering, then the actual 116 behavior of the NAT will be the same as port overlapping NAT. It 117 should also be noted that a lot of existing NAT devices adopted this 118 port overlapping mechanism. 120 3. Security Considerations 122 Security issues are not discussed in this memo. 124 4. Normative References 126 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 127 RFC 793, September 1981. 129 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 130 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 131 RFC 4787, January 2007. 133 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 134 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 135 RFC 5382, October 2008. 137 Authors' Addresses 139 Kengo Naito 140 NTT NT Lab 141 3-9-11 Midori-Cho 142 Musashino-shi, Tokyo 180-8585 143 Japan 145 Phone: +81 422 59 4949 146 Email: naito.kengo@lab.ntt.co.jp 148 Arifumi Matsumoto 149 NTT NT Lab 150 3-9-11 Midori-Cho 151 Musashino-shi, Tokyo 180-8585 152 Japan 154 Phone: +81 422 59 3334 155 Email: arifumi@nttv6.net