idnits 2.17.1 draft-tsou-behave-natx4-log-reduction-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 : ---------------------------------------------------------------------------- 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 (August 24, 2010) is 4966 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-softwire-dual-stack-lite - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou 3 Internet-Draft T. Taylor 4 Intended status: Informational Huawei Technologies 5 Expires: February 25, 2011 August 24, 2010 7 Port Management To Reduce Logging In Large-Scale NATs 8 draft-tsou-behave-natx4-log-reduction-00 10 Abstract 12 Various V6 transition strategies require the introduction of large- 13 scale NATs (NAT444, NAT64) to share the limited supply of IPv4 14 addresses available in the network until transition is complete. 15 There has recently been debate over how to manage the sharing of 16 ports between different subscribers assigned the same IPv4 address. 17 One factor in the discussion is the operational requirement to log 18 the assignment of transport addresses to subscribers. It has been 19 argued that dynamic sharing of ports between subscribers requires the 20 generation of an excessive volume of logs. This document suggests a 21 way to achieve dynamic port sharing while keeping log volumes low. 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 February 25, 2011. 40 Copyright Notice 42 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 59 2. A Suggested Solution . . . . . . . . . . . . . . . . . . . . . 3 60 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 61 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 62 5. Informative References . . . . . . . . . . . . . . . . . . . . 4 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 During the IPv6 transition period, some large-scale NAT devices may 68 be introduced, e.g. NAT444 (CGN - Carrier Grade NAT), NAT64, etc. 69 When a NAT device needs to set up a new connection for the user 70 behind the NAT, it needs to create a new mapping entry for the new 71 connection, which will contain source IP address, source port, 72 converted source IP address, converted source port, protocol(TCP/UDP/ 73 ICMP), etc. 75 For the purpose of troubleshooting, and also required by regulations, 76 operators must keep logs of network NAT mapping entries for a period 77 of time, e.g. 6 months, so the NAT device needs to generate logs for 78 mapping entries. A traditional method is to generate a log for each 79 mapping entry. When a connection expires, the mapping entry will be 80 deleted, and the corresponding log will be sent to a log storage 81 server. 83 Some high performance CGN devices may need to create a million or 84 more new sessions per second. If logs are generated for each mapping 85 entry, the log traffic could reach fifty megabytes per second or 86 more, which would be a problem for log generation, transmission and 87 storage. 89 To reduce the cost of log storage, [I-D.nishitani-cgn] proposes to 90 fix the port range for each user/CPE, and only one log will be 91 generated for each user. But this would significantly reduce the 92 number of subscribers that could share a public IP address, as 93 discussed in [I-D.softwire-dual-stack-lite]. 95 1.1. Requirements Language 97 This draft includes no requirements language. 99 2. A Suggested Solution 101 We propose a solution that allows dynamic sharing of port ranges 102 between users while minimizing the number of logs that have to be 103 generated. Briefly, ports are allocated to the user in blocks. Logs 104 are generated only when blocks are allocated or deallocated. This 105 provides the necessary traceability while reducing log generation by 106 a factor equal to the block size, as compared with fully dynamic port 107 allocation. 109 Here is how the proposal would work in greater detail. When the user 110 sends out the first packet, a port resource pool is allocated for the 111 user, e.g. assign ports 2000~2300 of a public IP address to the 112 user's resource pool. Only one log should be generated for this port 113 segment. When the CGN needs to set up a new mapping entry for the 114 user, it can use a port in the user's resource pool and the 115 corresponding public IP address. If the user needs more port 116 resources, the CGN can allocate another port segment, ports 117 3000~3050, to the user's resource pool. Again , just one log needs 118 to be generated for this port segment. 120 If some port segment is not used for some configurable time, e.g., 121 one minute, after initial allocation or after the mapping timer has 122 expired for every port in the segment, the CGN can remove the port 123 segment from the user's resource pool, and make it available for 124 other users. The deallocation is logged when it occurs. 126 This solution can reduce the number of logs significantly and also 127 make good use of the public IP address resource. 129 3. IANA Considerations 131 This memo includes no request to IANA. 133 4. Security Considerations 135 The security considerations applicable to NAT operation for various 136 protocols as documented in, for example, [RFC4787] and [RFC5382] also 137 apply to this proposal. 139 5. Informative References 141 [I-D.nishitani-cgn] 142 Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, 143 "Common requirements for IP address sharing schemes (Work 144 in progress)", July 2010. 146 [I-D.softwire-dual-stack-lite] 147 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 148 Stack Lite Broadband Deployments Following IPv4 Exhaustion 149 (Work in progress)", August 2010. 151 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 152 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 153 RFC 4787, January 2007. 155 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 156 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 157 RFC 5382, October 2008. 159 Authors' Addresses 161 Tina Tsou 162 Huawei Technologies 163 Bantian, Longgang District 164 Shenzhen 518129 165 P.R. China 167 Phone: 168 Email: tena@huawei.com 170 Tom Taylor 171 Huawei Technologies 172 1852 Lorraine Ave. 173 Ottawa K1H 6Z8 174 Canada 176 Phone: 177 Email: tom111.taylor@bell.net