idnits 2.17.1 draft-chen-sunset4-cgn-port-allocation-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 (February 18, 2013) is 4084 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.donley-behave-deterministic-cgn' is defined on line 266, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-01 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-05 == Outdated reference: A later version (-10) exists of draft-tsou-pcp-natcoord-09 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Chen 3 Internet-Draft China Mobile 4 Intended status: Informational February 18, 2013 5 Expires: August 22, 2013 7 Analysis of CGN Port Allocation Method 8 draft-chen-sunset4-cgn-port-allocation-00 10 Abstract 12 The document enumerated methods of port assignment in CGN contexts. 13 The analysis categorized the different methods with several key 14 features. Corresponding to those features, the uses of existing 15 protocols are also described. The potential concerns and workaround 16 have been discussed. It's expected the document could provide a 17 informative base line to help operators choosing a proper method. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on August 22, 2013. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Port Allocation Management . . . . . . . . . . . . . . . . . . 3 55 2.1. NAT vs NAPT . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Dynamic vs Static . . . . . . . . . . . . . . . . . . . . . 4 57 2.3. Centralized vs Distributed . . . . . . . . . . . . . . . . 5 58 3. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 63 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 With the depletion of IPv4 address, CGN has been adopted by ISPs to 69 expand IPv4 spaces. Relying upon the mechanism of multiplexing 70 multiple subscribers' connections over a smaller number of shared 71 IPv4 addresses, CGN mapped IP addresses from one address realm to 72 another, providing transparent routing to end hosts. 73 [I-D.ietf-behave-lsn-requirements] defined the term of CGN. Several 74 proposals including DS-Lite, NAT64, NAT444 would likely fall into the 75 scope. [RFC6269] has provided a thoughtful analysis on the issues of 76 IP sharing. It was point out that those IP sharing bring the impacts 77 to law enforcement since the information of source address would be 78 lost during the translation. Network administrators have to log the 79 mapping status for each connection in order to identify a specific 80 user associated with an IP address. It would post a challenge to 81 operators, since it requires additional storage resource and data 82 inspection process for indentifying the real users. It's desirable 83 to compact the logging information by a rational port allocation. 84 Those allocation policies should consider the tradeoff between port 85 utilization and log storage compression. The document is trying to 86 enumerate the several dimensions for assigning the port information. 87 It's expected administrator could use those factors to determine 88 their own properties. 90 2. Port Allocation Management 92 This section lists several factors to allocate the port information 93 for CGN equipments. It likely that each allocation model would have 94 an exemplified case. The relevant issues and potential workarounds 95 have also been described for each aspect. 97 2.1. NAT vs NAPT 99 CGN may not do Network Address Port Translation (NAPT), but only 100 Network Address Translation (NAT). In those cases, there is no 101 concern about port assignment. Those translation methods would 102 relieve the demands of log information storage, since NAT does not 103 have to administer address management with session flows. 104 Furthermore, there is no requirement to maintain log when CGN 105 performing stateless translations. Some existing practices are 106 listed below from two aspects. 108 o Stateful NAT 110 The stateful NAT can be implemented either by static address 111 translation or dynamic address translation. 113 In the case of static address assignment, one-to-one address mapping 114 for hosts between a private network address and an external network 115 address would be pre-configured on the NAT operation. Those cases 116 normally occurred when a server deployed in a internal domain. The 117 static configuration ensure the stable inbound connectivity. The 118 static method is also easier for Lawful interception system to derive 119 the mapped address, since the mapping didn't change with time. 121 Dynamic address assignment would periodically free the binding so 122 that the global address could be recycled for later uses. Addresses 123 could be more efficiently used by time-division manner. It only 124 requires systems maintaining mappings for per-customer, other than 125 per-session flow. This method is usually adopted to reduce the log 126 burden in some protocols. 128 o Stateless NAT 130 The stateless NAT is performed in compliant with [RFC6145]. Public 131 IPv4 address is required to be inserted in IPv6 address. Therefore, 132 CGN could directly extract the address and no need to record mapping 133 states. The lawful interception could likely indentify the IPv4 134 address through received IPv6 address. It's a protocol to eliminate 135 the log information storage. There are two potential concerns for 136 those technologies. First off, the static one-to-one mapping may 137 didn't address the issue of IPv4 depletion. Secondly, it introduced 138 the dependency of IPv4/IPv6. That would create new limitations since 139 the change of IPv4 address would cause renumbering of IPv6 addresses. 140 Whereas, that is useful for the IDC migration where there is IPv6 141 servers pools to receive inbound connections from IPv4 users 142 externally[I-D.anderson-siit-dc]. 144 2.2. Dynamic vs Static 146 When the case comes to port assignment, there are two methods for 147 port allocations. 149 o Dynamic assignment 151 CGN normally do the dynamic assignment. In respect to the received 152 connections, ports can be allocated to each sessions. NAT64, DS-Lite 153 and NAT444 would do the dynamic approach by default, since it 154 achieves maximum port utilization. One downside for this approach is 155 CGN has to record log information for each session. That would 156 potential increase the log volume. There is a statistic from field 157 trials that the average number of connections per customer per day at 158 approximately 10,000 connections. If log system is required to store 159 information for 180 days, the testing shown that the amount of data 160 records would achieve 20T. 162 o Static assignment 164 The static assignment make a bulk of port reservation for a specific 165 address. The bulk of port could be either a contiguous or non- 166 contiguous port range for sake of attacks defense. 167 [I-D.donley-behave-deterministic-cgn]has described a deterministic 168 NAT to reserve a port range for each specific IP address. That is a 169 significant improvement for lightening log volume. However, a trade- 170 off should be made when administor has to consider the port 171 utilization. For the administor who prioritize the port utilization, 172 dynamic assignment maybe a suitable solution for them. Another 173 consideration is using Address-Dependent Mapping or Address and Port- 174 Dependent Mapping[RFC4787] to increase the port utilization. This 175 feature has already been implemented as vendor-specific features. 176 Whereas, it should be noted that REQ-7, REQ-12 177 in[I-D.ietf-behave-lsn-requirements] may reduce the needs. 179 2.3. Centralized vs Distributed 181 The port allocation can be managed as a centralized way on CGN or 182 distributed to downstream devices(e.g, CPE connected with CGN) . 184 o Centralized Assignment 186 A centralized method would make port assignment when traffic come to 187 CGN box. The allocation policy is enforced on CGN. CGN make either 188 a dynamic or static port assignment to the received session. 190 o Distributed Assignment 192 CGN could also delegate the pre-allocated port range to customer edge 193 devices. That can be achieved through additional out-band 194 provisioning signals(e.g.[I-D.ietf-pcp-base] 195 ,[I-D.tsou-pcp-natcoord][I-D.ietf-softwire-map-dhcp]). The 196 distributed model normally performed A+P for static port assignment. 197 CGN should hold the corresponding mapping in accordance with assigned 198 ports. Those methods would shift CGN port computation into 199 downstream devices. The detailed benefits to CGN was documented in 200 [I-D.ietf-softwire-stateless-4v6-motivation]. 202 3. Discussions 204 With demands of reducing log volume, there are several approaches of 205 port assignment described in the aforementioned section. It could be 206 found that a trade-off between maximum port utilization and log 207 volume always exist regarding justifications of different solutions. 208 In respect to difference of port assignment, the granularity of log 209 could be ranked as per-session, per-port-bulk, per-customer and None. 210 With the reduction of log volume, port utilization is likely 211 decreased. Therefore, the decision should be made if there is a 212 quantitative statistic to evaluate what is gain from reducing log 213 volume and loss from decreasing port utilization. Those data 214 analysis is planned to be added after further lab testing. Operators 215 could choose the proper method considering following: 217 o Average connectivities per customer per day 219 o Peak connectivities per day 221 o The amount of public IPv4 address in CGN 223 o Application demands for specific ports 225 o The parallel processing capabilities of CGN 227 o The tolerance of Log volume 229 4. Security Considerations 231 TBD 233 5. IANA Considerations 235 This document makes no request of IANA. 237 6. References 239 6.1. Normative References 241 [I-D.ietf-pcp-base] 242 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 243 Selkirk, "Port Control Protocol (PCP)", 244 draft-ietf-pcp-base-29 (work in progress), November 2012. 246 [I-D.ietf-softwire-map-dhcp] 247 Mrugalski, T., Troan, O., Bao, C., Dec, W., and L. Yeh, 248 "DHCPv6 Options for Mapping of Address and Port", 249 draft-ietf-softwire-map-dhcp-01 (work in progress), 250 August 2012. 252 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 253 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 254 RFC 4787, January 2007. 256 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 257 Algorithm", RFC 6145, April 2011. 259 6.2. Informative References 261 [I-D.anderson-siit-dc] 262 Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data 263 Centre Environments", draft-anderson-siit-dc-00 (work in 264 progress), November 2012. 266 [I-D.donley-behave-deterministic-cgn] 267 Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 268 and O. Vautrin, "Deterministic Address Mapping to Reduce 269 Logging in Carrier Grade NAT Deployments", 270 draft-donley-behave-deterministic-cgn-05 (work in 271 progress), January 2013. 273 [I-D.ietf-behave-lsn-requirements] 274 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 275 and H. Ashida, "Common requirements for Carrier Grade NATs 276 (CGNs)", draft-ietf-behave-lsn-requirements-10 (work in 277 progress), December 2012. 279 [I-D.ietf-softwire-stateless-4v6-motivation] 280 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 281 Borges, I., and G. Chen, "Motivations for Carrier-side 282 Stateless IPv4 over IPv6 Migration Solutions", 283 draft-ietf-softwire-stateless-4v6-motivation-05 (work in 284 progress), November 2012. 286 [I-D.tsou-pcp-natcoord] 287 Sun, Q., Boucadair, M., Deng, X., Zhou, C., Tsou, T., and 288 S. Perreault, "Using PCP To Coordinate Between the CGN and 289 Home Gateway", draft-tsou-pcp-natcoord-09 (work in 290 progress), November 2012. 292 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 293 Roberts, "Issues with IP Address Sharing", RFC 6269, 294 June 2011. 296 Author's Address 298 Gang Chen 299 China Mobile 300 53A,Xibianmennei Ave., 301 Xuanwu District, 302 Beijing 100053 303 China 305 Email: phdgang@gmail.com