idnits 2.17.1 draft-chen-sunset4-cgn-port-allocation-02.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 : ---------------------------------------------------------------------------- ** There are 12 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 14, 2013) is 3939 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 414, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-softwire-map-dhcp-03 ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-06 == Outdated reference: A later version (-13) exists of draft-ietf-pcp-port-set-01 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-06 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-03 Summary: 3 errors (**), 0 flaws (~~), 7 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 July 14, 2013 5 Expires: January 15, 2014 7 Analysis of NAT64 Port Allocation Method 8 draft-chen-sunset4-cgn-port-allocation-02 10 Abstract 12 The document enumerates methods of port assignment in CGN contexts, 13 more focusing on a NAT64 environment. The analysis categorizes the 14 different methods with several key features. The uses of existing 15 protocols are further described corresponding to those features. 16 This memo also states the port-usage experiences, relevant findings, 17 evaluations and workarounds. It's expected the document could 18 provide an informative base line to help operators choosing a proper 19 method. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 15, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Port Consumption on NAT64 . . . . . . . . . . . . . . . . . . 3 57 3. Port Allocation Category and Usages . . . . . . . . . . . . . 3 58 3.1. NAT vs NAPT . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.2. Dynamic vs Static . . . . . . . . . . . . . . . . . . . . 4 60 3.3. Centralized vs Distributed . . . . . . . . . . . . . . . 5 61 4. Log Volume Optimization . . . . . . . . . . . . . . . . . . . 6 62 5. Connectivity State Optimization . . . . . . . . . . . . . . . 7 63 6. Port Randomization . . . . . . . . . . . . . . . . . . . . . 8 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 69 10.2. Informative References . . . . . . . . . . . . . . . . . 9 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 72 1. Introduction 74 With the depletion of IPv4 address, CGN(Carrier Grade NAT) has been 75 adopted by operators to expand IPv4 spaces. Relying upon the 76 mechanism of multiplexing subscribers' connections over a smaller 77 number of shared IPv4 addresses, CGN mapped IP addresses from one 78 address realm to another, providing transparent routing to end hosts. 79 [RFC6888] defined the term of CGN. Several proposals including DS- 80 Lite[RFC6333], NAT64[RFC6145], [RFC6146], NAT444 would likely fall 81 into the scope. Focusing on the IPv6 migration, the memo elaborates 82 the port allocation methods in a NAT64 environment, where there are 83 IPv6-only nodes connected. 85 There are several aspects may have to consider in order to deploy a 86 suitable method. The below enumerates the potential aspects. 88 o Specific features of port-usages in a NAT64 environment 90 o The category of different port-allocations methods 92 o The port allocation method to improve connectivity 94 o The port allocation method to optimize log volume 96 o The port allocation method to enhance security 97 The document is trying to detail the analysis and relevant 98 experiences. 100 2. Port Consumption on NAT64 102 With the merits of simplicity and efficiency, NAT64 will be likely 103 deployed. In those cases, NAT64 would enable internal IPv6 hosts to 104 connect to external dual-stack networks. Compared with NAT44, fewer 105 ports consumed on NAT64. The reason for the fewer port consumption 106 is NAT64 are deployed to provide connectivities from one address 107 family to another. Only flows between different address families 108 require ports to be assigned. That is, a NAT44 might be deployed in 109 an IPv4-only environment. Since all traffic will have to traverse 110 the NAT, all flows will need ports. Conversely, NAT64 only requires 111 a port when one end is IPv4-only. Therefore, the more hosts support 112 IPv6, the fewer ports are needed on the NAT64. 114 There was a testing on the comparison of port consumption on NAT64 115 and NAT44. Top100 websites (referring to Alexa statistics) were 116 being assessed to evaluate status of port usage on NAT44 and NAT64 117 respectively. It's observed that the port consumptions on NAT64 is 118 roughly only half on NAT44. 43 percent of top100 websites have AAAA 119 records, therefore the NAT64 didn't have to assign ports to the 120 traffic going to those websites. The results may be different if 121 more services (e.g. game, web-mail, etc) are considered. Whereas, 122 it's obvious that the port saving on NAT64 could be amplified by 123 increasing native IPv6 supports. 125 Apart from above, the port allocation can be tuned corresponding to 126 the phase of IPv6 migration. The use of NAT64 would advance IPv6, 127 because it provides everyone incentives to use IPv6 and eventually 128 the result is an end-to-end IPv6-only networks with no needs for port 129 allocations. As more content providers and service are available 130 over IPv6, the utilization on NAT64 goes down since fewer 131 destinations require translation progressing. In the trend of IPv6 132 migration, NAT64 may relax the multiplexing ratio of shared IPv4 133 address by either a distributed port delegation or a centralized 134 control. 136 3. Port Allocation Category and Usages 138 This section lists several methods to allocate the port information 139 in NAT64 equipments. It also describes exemplified cases for each 140 allocation model. 142 3.1. NAT vs NAPT 143 NAT64 may not do Network Address Port Translation (NAPT), but only 144 Network Address Translation (NAT). In those cases, there is no 145 concern about port assignment. Some existing practices are listed 146 below. 148 o Stateful 150 The stateful NAT can be implemented either by static address 151 translations or dynamic address translations. 153 In the case of static address assignments, one-to-one address mapping 154 for hosts between a IPv6 network address and an IPv4 network address 155 would be pre-configured on the NAT operation. Those cases normally 156 occurred when a server deployed in a IPv6 domain. The static 157 configuration ensure the stable inbound connectivity. 159 Dynamic address assignment would periodically free the binding so 160 that the global address could be recycled for later uses. Addresses 161 could be more efficiently used by a time-division manner. 163 o Stateless 165 The stateless NAT is performed in compliant with [RFC6145]. Public 166 IPv4 address is required to be inserted in IPv6 address. Therefore, 167 NAT64 could directly extract the address and no need to record 168 mapping states. A promising usage of stateless could be appeared in 169 IDC(Internet Data Center) environments where there are IPv6 servers 170 farms to receive inbound connections from external IPv4 users 171 [I-D.anderson-siit-dc]. The other uses may consider two issues. 172 First off, the static one-to-one mapping may didn't resolve IPv4 173 depletions. Secondly, it introduced the dependency between IPv4 and 174 IPv6. It causes new limitations since the changes of IPv4 address 175 lead renumbering of IPv6 addresses. 177 3.2. Dynamic vs Static 179 There are two methods on port allocations. 181 o Dynamic assignments 183 NAT64 normally do the dynamic assignments, since maximum port 184 utilizations could be achieved. In respect to port allocations, it 185 could be allocated with the granularity of per-session or per- 186 customer. Per-session assignments are basically configured on NAT64 187 by default for efficient port utilizations. However, a heavy log 188 volume may have to be recorded for lawful interception uses. In 189 order to mitigate the concerns, bulk port allocation is enabled .When 190 a subscriber creates the first session, a number of ports are pre- 191 allocated. It would significantly reduce log volumes. It's 192 desirable to configure a proper port-range for each subscriber. Two 193 aspects are listed below. 195 a. The number of session initiations for each subscriber. A 196 subscriber normally uses multiple applications simultaneously, 197 e.g. map, online video or games. The number of concurrent 198 sessions are essential to determine the size of port range. It 199 has been learned from subscriber's behaviors that the average 200 session number of a standalone device is around 200~300 ports. 201 Several devices maybe appeared behind a CPE. Operators may 202 configure a range with 1000 ports to each CPE(Customer Premises 203 Equipment) in a residential network. 205 b. Impacts to NAT64 capacity. The pre-assigned port ranges occupy 206 the memory even there are unused ports. NAT64 CGN served a 207 centralized point for numerous subscribes. Therefore, it should 208 be cautious the impacts of port-range reservation to the capacity 209 of attempted concurrent sessions. 211 o Static assignments 213 The static assignment makes a bulk of port reservations for each 214 internal address before subscriber's connection. The bulk of ports 215 could be either a contiguous or non-contiguous port range for the 216 sake of attack defense. [I-D.donley-behave-deterministic-cgn]has 217 described a deterministic NAT to assign a port range for internal IP 218 address pool in a sequence. The difference of the static method with 219 dynamic port-range is address/ports mappings have been established 220 before subscriber's connection attempts. Log recording may not be 221 necessary due to the stable mapping relations. The considerations of 222 port-range allocation and capacity impacts could also be applied to 223 the case of static assignments. 225 3.3. Centralized vs Distributed 227 There are increasing needs to connect NAT64 with downstream 228 NAT46-capable devices to support IPv4 users/applications on a 229 IPv6-only path. Several solutions have been proposed in this area, 230 e.g. 464xlat[RFC6877], MAP-T[I-D.ietf-softwire-map-t] and 231 4rd[I-D.ietf-softwire-4rd]. With the feature of double-translation, 232 the port allocation can be categorized as a centralized assignment on 233 NAT64 or a port delegation distributed to downstream devices (e.g, 234 customer edges connected with NAT64) . 236 o Centralized Assignment 237 A centralized method would make port assignments once IP flows come 238 to NAT64. The allocation policy is enforced on a centralized point. 239 Either a dynamic or static port assignment is made for received 240 sessions. 242 o Distributed Assignment 244 NAT64 could also delegate the pre-allocated port range to customer 245 edge devices. That can be achieved through additional out-band 246 provisioning signals(e.g. 247 ,[I-D.ietf-pcp-port-set][I-D.ietf-softwire-map-dhcp]). The 248 distributed model normally performs A+P style for static port 249 assignment. NAT64 should hold the consistent mapping in accordance 250 with assigned ports. Those methods could shift NAT64 port 251 computations/states into downstream devices. The detailed benefits 252 was documented in [I-D.ietf-softwire-stateless-4v6-motivation]. 254 4. Log Volume Optimization 256 [RFC6269] has provided a thoughtful analysis on the issues of IP 257 sharing. It pointed out that IP sharing may bring the impacts to law 258 enforcements since the information of source address would be lost 259 during the translation. Network administrators have to log the 260 mapping status for each connection in order to identify a specific 261 user associated with an IP address in a particular time slot. The 262 storage of log information may post a challenge to operators, since 263 it requires additional transport, storage resources and data 264 inspection process to indentify users. It's desirable to compact the 265 logging information. Referring the categories of port allocation, 266 the assignment could be managed on either per-session or per- 267 customer. The bigger granularity would lead fewer log volume 268 storage. A testing was made to record the log information from 269 200,000 subscribers for 60 days. The volume of recorded information 270 reach up to 42.5 terabytes with per-session log. Conversely, it only 271 occupy 40.6 gigabytes with per-customer log. There is even a method, 272 which doesn't have to log any information. 274 Whereas, high compression would cause lower efficiency of port 275 utilization. A port allocation based on per-customer granularity 276 have to retain vacant ports in order to avoid traffic overflow. The 277 efficiency could be evaluated by port utilization rate. The below 278 table is trying to make a composite analysis. 280 +-----------------+----------------- +-----------------+-------------------+ 281 |Type of log | Method of port | Log Volume(e.g. | Port utilization | 282 |records | allocations | 200,000 users | ratio | 283 | | | for 60 days) | | 284 +-----------------+---------------- -+-----------------+-------------------+ 285 |per-session |Dynamic NAPT | 43.5 Terabytes | 100% | 286 +-----------------+------------------+-----------------+-------------------| 287 |per-customer |Dynamic port-range| 40.6 Gigabytes | 75%(e.g.400 ports)| 288 +-----------------+------------------+-----------------+-------------------+ 289 |None Log |Deterministic NAT,| | 60% *75%= | 290 | |MAP,4rd | 0 | 45% | 291 +-----------------+------------------+-----------------+-------------------+ 292 Note:75% is evaluated for port utilization ratio. 293 60% is evaluated for the ratio of active subscribers. 295 The data shared in the table may roughly demonstrates the tradeoff 296 between port utilization and log volume compression. The efficiency 297 could be even lower if static bulk-port allocation is used since the 298 ports were pre-allocated to customers regardless online or offline 299 status. Administrator may consider below factors to determine their 300 own solution 302 o Average connectivity per customer per day 304 o Peak connectivity per day 306 o The amount of public IPv4 address in NAT64 308 o Application demands for specific ports 310 o The processing capabilities of NAT64 312 o The tolerance of log volume 314 5. Connectivity State Optimization 316 It's observed that port consumption would be significantly increased 317 when subscribers stick to a web page for VoD (Video On Demand), 318 online games or map services. In those cases, multiple TCP 319 connections may be initiated to optimize the performance of data 320 transmissions for video download and message exchange. With the 321 trends of the video traffic growth, it likely presents a challenge 322 for network operators that need to optimize connectivity states so as 323 to avoid port depletions. Those optimizations may even be 324 significant to the method of port-range allocation, because a 325 subscriber is only allowed to use a pre-configured port resource. 327 The optimization could be considered from two aspects. 329 o Reducing the TIME-WAIT state. Acceleration of TIME-WAIT state 330 transitions could increase the efficiency of port utilization. 331 [RFC6191] defines the mechanism of reducing TIME-WAIT state by 332 proposing TCP timestamps and sequence numbers. 333 [I-D.penno-behave-rfc4787-5382-5508-bis] recommended applying 334 [RFC6191] and PAWS (Protect Against Wrapped Sequence numbers 335 described in [RFC1323]) to NAT. It might a way to improve port 336 utilizations. 338 o Another consideration is using Address-Dependent Mapping or 339 Address and Port-Dependent Mapping[RFC4787] to increase the port 340 utilization. This feature has already been implemented as vendor- 341 specific features. Whereas, it should be noted this use didn't 342 recommended by [RFC6888] (e.g. REQ-7) that may reduce the 343 incentives. 345 6. Port Randomization 347 Port randomization is a feature to enhance the defense of hijack 348 flows. [RFC6056] specified that NAPTs should consider obfuscating 349 the selection of ephemeral ports. A NAPT based on per-session may be 350 less difficult to implement by allocating non-contiguous port to each 351 connection. The methods of port-range allocation have to correlate 352 the algorithm configuration and input parameters between NAT64 and 353 log system to identify the subscribers. In general, a simply 354 algorithm on port assignment is mostly desirable to simplify the log 355 process. It could be considerable to enlarge the size of port range 356 to alleviate security issues, if the port resource is allowed. 358 7. Security Considerations 360 The non-contiguous port allocations could be considered to enhance 361 the security of port allocations. This document shares the 362 considerations in [RFC6056]. 364 8. IANA Considerations 366 This document makes no request of IANA. 368 9. Acknowledgements 370 The author would like to thank Lee Howard and Simon Perreault for 371 their helpful comments. 373 Many thanks to Wesley George and Marc Blanchet encourage the author 374 to continue this work. 376 10. References 378 10.1. Normative References 380 [I-D.ietf-softwire-map-dhcp] 381 Mrugalski, T., Troan, O., Dec, W., Bao, C., 382 leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options 383 for Mapping of Address and Port", draft-ietf-softwire-map- 384 dhcp-03 (work in progress), February 2013. 386 [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions 387 for High Performance", RFC 1323, May 1992. 389 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 390 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 391 RFC 4787, January 2007. 393 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 394 Algorithm", RFC 6145, April 2011. 396 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 397 NAT64: Network Address and Protocol Translation from IPv6 398 Clients to IPv4 Servers", RFC 6146, April 2011. 400 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 401 Timestamps", BCP 159, RFC 6191, April 2011. 403 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 404 Stack Lite Broadband Deployments Following IPv4 405 Exhaustion", RFC 6333, August 2011. 407 10.2. Informative References 409 [I-D.anderson-siit-dc] 410 Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data 411 Centre Environments", draft-anderson-siit-dc-00 (work in 412 progress), November 2012. 414 [I-D.donley-behave-deterministic-cgn] 415 Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 416 and O. Vautrin, "Deterministic Address Mapping to Reduce 417 Logging in Carrier Grade NAT Deployments", draft-donley- 418 behave-deterministic-cgn-06 (work in progress), July 2013. 420 [I-D.ietf-pcp-port-set] 421 Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., 422 and S. Perreault, "Port Control Protocol (PCP) Extension 423 for Port Set Allocation", draft-ietf-pcp-port-set-01 (work 424 in progress), May 2013. 426 [I-D.ietf-softwire-4rd] 427 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 428 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 429 Solution (4rd)", draft-ietf-softwire-4rd-06 (work in 430 progress), July 2013. 432 [I-D.ietf-softwire-map-t] 433 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 434 T. Murakami, "Mapping of Address and Port using 435 Translation (MAP-T)", draft-ietf-softwire-map-t-03 (work 436 in progress), July 2013. 438 [I-D.ietf-softwire-stateless-4v6-motivation] 439 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 440 Borges, I., and G. Chen, "Motivations for Carrier-side 441 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- 442 softwire-stateless-4v6-motivation-05 (work in progress), 443 November 2012. 445 [I-D.penno-behave-rfc4787-5382-5508-bis] 446 Penno, R., Perreault, S., Kamiset, S., Boucadair, M., and 447 K. Naito, "Network Address Translation (NAT) Behavioral 448 Requirements Updates", draft-penno-behave- 449 rfc4787-5382-5508-bis-04 (work in progress), January 2013. 451 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 452 Protocol Port Randomization", BCP 156, RFC 6056, January 453 2011. 455 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 456 Roberts, "Issues with IP Address Sharing", RFC 6269, June 457 2011. 459 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 460 Combination of Stateful and Stateless Translation", RFC 461 6877, April 2013. 463 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 464 and H. Ashida, "Common Requirements for Carrier-Grade NATs 465 (CGNs)", BCP 127, RFC 6888, April 2013. 467 Author's Address 468 Gang Chen 469 China Mobile 470 53A,Xibianmennei Ave., 471 Xuanwu District, 472 Beijing 100053 473 China 475 Email: phdgang@gmail.com