idnits 2.17.1 draft-tsou-behave-natx4-log-reduction-01.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 27, 2010) is 4988 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- No information found for draft-bajko-pripaddrassign - is the name correct? -- No information found for draft-softwire-dual-stack-lite - is the name correct? Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Behavior Engineering for Hindrance T. Tsou, Ed. 3 Avoidance T. Taylor 4 Internet-Draft Huawei Technologies 5 Intended status: Informational August 27, 2010 6 Expires: February 28, 2011 8 Port Management To Reduce Logging In Large-Scale NATs 9 draft-tsou-behave-natx4-log-reduction-01 11 Abstract 13 Various IPv6 transition strategies require the introduction of large 14 -scale NATs (e.g. AFTR, NAT64) to share the limited supply of IPv4 15 addresses available in the network until transition is complete. 16 There has recently been debate over how to manage the sharing of 17 ports between different subscribers sharing the same IPv4 address. 18 One factor in the discussion is the operational requirement to log 19 the assignment of transport addresses to subscribers. It has been 20 argued that dynamic assignment of individual ports between 21 subscribers requires the generation of an excessive volume of logs. 22 This document suggests a way to achieve dynamic port sharing while 23 keeping log volumes low. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 28, 2011. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 61 2. A Suggested Solution . . . . . . . . . . . . . . . . . . . . . 3 62 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 65 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5 67 6.2. Informative References . . . . . . . . . . . . . . . . . . 5 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 70 1. Introduction 72 During the IPv6 transition period, some large-scale NAT devices may 73 be introduced, e.g. DS-Lite AFTR, NAT64. When a NAT device needs to 74 set up a new connection for the user behind the NAT, it needs to 75 create a new mapping entry for the new connection, which will contain 76 source IP address, source port, converted source IP address, 77 converted source port, protocol(TCP/UDP), etc. If the connection is 78 ICMP, a mapping entry may include source IP address, couverted source 79 IP address, source identifier, converted source identifier, etc 81 For the purpose of troubleshooting, and also required by regulations, 82 operators must keep logs of network NAT mapping entries for a period 83 of time, e.g. 6 months or one year 84 [I-D.ietf-intarea-shared-addressing-issues], so the NAT device needs 85 to generate logs for mapping entries in addition to other 86 information. A traditional method is to generate a log for each 87 mapping entry. When a connection expires, the mapping entry will be 88 deleted, and the corresponding log is stored locally or sent to a log 89 storage server. 91 Some high performance NAT devices may need to create a large amount 92 of new sessions per second. If logs are generated for each mapping 93 entry, the log traffic could reach tens of megabytes per second or 94 more, which would be a problem for log generation, transmission and 95 storage. 97 To reduce the cost of log storage, [I-D.nishitani-cgn] proposes to 98 fix the port range for each user/CPE, and only one log will be 99 generated for each user. But this would significantly reduce the 100 number of subscribers that could share a public IP address, as 101 discussed in [I-D.softwire-dual-stack-lite]. 103 1.1. Requirements Language 105 This draft includes no requirements language. 107 2. A Suggested Solution 109 We propose a solution that allows dynamic sharing of port ranges 110 between users while minimizing the number of logs that have to be 111 generated. Briefly, ports are allocated to the user in blocks. Logs 112 are generated only when blocks are allocated or deallocated. This 113 provides the necessary traceability while reducing log generation by 114 a factor equal to the block size, as compared with fully dynamic port 115 allocation. 117 Here is how the proposal would work in greater detail. When the user 118 sends out the first packet, a port resource pool is allocated for the 119 user, e.g. assign ports 2000~2300 of a public IP address to the 120 user's resource pool. Only one log should be generated for this port 121 block. When the NAT needs to set up a new mapping entry for the 122 user, it can use a port in the user's resource pool and the 123 corresponding public IP address. If the user needs more port 124 resources, the NAT can allocate another port block, ports 3000~3050, 125 to the user's resource pool. Again , just one log needs to be 126 generated for this port block. A log may contain the following 127 information: source IP address, converted source IP address, port 128 range, start time, end time, and some other necessary information. 130 There is an alternative way of allocating port blocks 131 [I-D.bajko-pripaddrassign]. The ports in a block do not have to be 132 continuous, due to security concerns; the port numbers could be 133 worked out using some random algorithm along with some initial 134 parameters. When generating a log message, these parameters instead 135 of the port range would be included in the log. 137 If some port block is not used for some configurable time, e.g. TBD 138 minutes, after initial allocation or after the mapping timer has 139 expired for every port in the block, the NAT can remove the port 140 block from the user's resource pool, and make it available for other 141 users. The deallocation is logged when it occurs. 143 This solution can reduce the number of logs significantly and also 144 make good use of the public IP address resource. 146 In some case [I-D.ietf-intarea-shared-addressing-issues], a server 147 may not record the source port of a connection, and NAT device needs 148 to record the destination IP address of a connection. In such a 149 case, the suggested solution is not applicable. But a reasonable 150 solution is still for the server to record the source port. 152 3. IANA Considerations 154 This memo includes no request to IANA. 156 4. Security Considerations 158 The security considerations applicable to NAT operation for various 159 protocols as documented in, for example, [RFC4787] and [RFC5382] also 160 apply to this proposal. 162 5. Acknowledgements 164 Mohamed Boucadair reviewed the document and provided useful comments 165 to improve it. 167 6. References 169 6.1. Normative References 171 [I-D.bajko-pripaddrassign] 172 Bajko, G., Savolainen, T., Boucadair, M., and P. Levis, 173 "Port Restricted IP Address Assignment (Work in 174 progress)", October 2009. 176 [I-D.ietf-intarea-shared-addressing-issues] 177 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 178 Roberts, "Issues with IP Address Sharing (Work in 179 progress)", June 2010. 181 6.2. Informative References 183 [I-D.nishitani-cgn] 184 Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, 185 "Common requirements for IP address sharing schemes (Work 186 in progress)", July 2010. 188 [I-D.softwire-dual-stack-lite] 189 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 190 Stack Lite Broadband Deployments Following IPv4 Exhaustion 191 (Work in progress)", July 2010. 193 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 194 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 195 RFC 4787, January 2007. 197 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 198 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 199 RFC 5382, October 2008. 201 Authors' Addresses 203 Tina Tsou (editor) 204 Huawei Technologies 205 Bantian, Longgang District 206 Shenzhen 518129 207 P.R. China 209 Phone: 210 Email: tena@huawei.com 212 Tom Taylor 213 Huawei Technologies 214 1852 Lorraine Ave. 215 Ottawa K1H 6Z8 216 Canada 218 Phone: 219 Email: tom111.taylor@bell.net