Network Working Group G. Chen Internet-Draft China Mobile Intended status: Informational July 14, 2013 Expires: January 15, 2014 Analysis of NAT64 Port Allocation Method draft-chen-sunset4-cgn-port-allocation-02 Abstract The document enumerates methods of port assignment in CGN contexts, more focusing on a NAT64 environment. The analysis categorizes the different methods with several key features. The uses of existing protocols are further described corresponding to those features. This memo also states the port-usage experiences, relevant findings, evaluations and workarounds. It's expected the document could provide an informative base line to help operators choosing a proper method. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 15, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must Chen Expires January 15, 2014 [Page 1] Internet-Draft nat64-port-allocations July 2013 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Port Consumption on NAT64 . . . . . . . . . . . . . . . . . . 3 3. Port Allocation Category and Usages . . . . . . . . . . . . . 3 3.1. NAT vs NAPT . . . . . . . . . . . . . . . . . . . . . . . 3 3.2. Dynamic vs Static . . . . . . . . . . . . . . . . . . . . 4 3.3. Centralized vs Distributed . . . . . . . . . . . . . . . 5 4. Log Volume Optimization . . . . . . . . . . . . . . . . . . . 6 5. Connectivity State Optimization . . . . . . . . . . . . . . . 7 6. Port Randomization . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction With the depletion of IPv4 address, CGN(Carrier Grade NAT) has been adopted by operators to expand IPv4 spaces. Relying upon the mechanism of multiplexing subscribers' connections over a smaller number of shared IPv4 addresses, CGN mapped IP addresses from one address realm to another, providing transparent routing to end hosts. [RFC6888] defined the term of CGN. Several proposals including DS- Lite[RFC6333], NAT64[RFC6145], [RFC6146], NAT444 would likely fall into the scope. Focusing on the IPv6 migration, the memo elaborates the port allocation methods in a NAT64 environment, where there are IPv6-only nodes connected. There are several aspects may have to consider in order to deploy a suitable method. The below enumerates the potential aspects. o Specific features of port-usages in a NAT64 environment o The category of different port-allocations methods o The port allocation method to improve connectivity o The port allocation method to optimize log volume o The port allocation method to enhance security Chen Expires January 15, 2014 [Page 2] Internet-Draft nat64-port-allocations July 2013 The document is trying to detail the analysis and relevant experiences. 2. Port Consumption on NAT64 With the merits of simplicity and efficiency, NAT64 will be likely deployed. In those cases, NAT64 would enable internal IPv6 hosts to connect to external dual-stack networks. Compared with NAT44, fewer ports consumed on NAT64. The reason for the fewer port consumption is NAT64 are deployed to provide connectivities from one address family to another. Only flows between different address families require ports to be assigned. That is, a NAT44 might be deployed in an IPv4-only environment. Since all traffic will have to traverse the NAT, all flows will need ports. Conversely, NAT64 only requires a port when one end is IPv4-only. Therefore, the more hosts support IPv6, the fewer ports are needed on the NAT64. There was a testing on the comparison of port consumption on NAT64 and NAT44. Top100 websites (referring to Alexa statistics) were being assessed to evaluate status of port usage on NAT44 and NAT64 respectively. It's observed that the port consumptions on NAT64 is roughly only half on NAT44. 43 percent of top100 websites have AAAA records, therefore the NAT64 didn't have to assign ports to the traffic going to those websites. The results may be different if more services (e.g. game, web-mail, etc) are considered. Whereas, it's obvious that the port saving on NAT64 could be amplified by increasing native IPv6 supports. Apart from above, the port allocation can be tuned corresponding to the phase of IPv6 migration. The use of NAT64 would advance IPv6, because it provides everyone incentives to use IPv6 and eventually the result is an end-to-end IPv6-only networks with no needs for port allocations. As more content providers and service are available over IPv6, the utilization on NAT64 goes down since fewer destinations require translation progressing. In the trend of IPv6 migration, NAT64 may relax the multiplexing ratio of shared IPv4 address by either a distributed port delegation or a centralized control. 3. Port Allocation Category and Usages This section lists several methods to allocate the port information in NAT64 equipments. It also describes exemplified cases for each allocation model. 3.1. NAT vs NAPT Chen Expires January 15, 2014 [Page 3] Internet-Draft nat64-port-allocations July 2013 NAT64 may not do Network Address Port Translation (NAPT), but only Network Address Translation (NAT). In those cases, there is no concern about port assignment. Some existing practices are listed below. o Stateful The stateful NAT can be implemented either by static address translations or dynamic address translations. In the case of static address assignments, one-to-one address mapping for hosts between a IPv6 network address and an IPv4 network address would be pre-configured on the NAT operation. Those cases normally occurred when a server deployed in a IPv6 domain. The static configuration ensure the stable inbound connectivity. Dynamic address assignment would periodically free the binding so that the global address could be recycled for later uses. Addresses could be more efficiently used by a time-division manner. o Stateless The stateless NAT is performed in compliant with [RFC6145]. Public IPv4 address is required to be inserted in IPv6 address. Therefore, NAT64 could directly extract the address and no need to record mapping states. A promising usage of stateless could be appeared in IDC(Internet Data Center) environments where there are IPv6 servers farms to receive inbound connections from external IPv4 users [I-D.anderson-siit-dc]. The other uses may consider two issues. First off, the static one-to-one mapping may didn't resolve IPv4 depletions. Secondly, it introduced the dependency between IPv4 and IPv6. It causes new limitations since the changes of IPv4 address lead renumbering of IPv6 addresses. 3.2. Dynamic vs Static There are two methods on port allocations. o Dynamic assignments NAT64 normally do the dynamic assignments, since maximum port utilizations could be achieved. In respect to port allocations, it could be allocated with the granularity of per-session or per- customer. Per-session assignments are basically configured on NAT64 by default for efficient port utilizations. However, a heavy log volume may have to be recorded for lawful interception uses. In order to mitigate the concerns, bulk port allocation is enabled .When a subscriber creates the first session, a number of ports are pre- Chen Expires January 15, 2014 [Page 4] Internet-Draft nat64-port-allocations July 2013 allocated. It would significantly reduce log volumes. It's desirable to configure a proper port-range for each subscriber. Two aspects are listed below. a. The number of session initiations for each subscriber. A subscriber normally uses multiple applications simultaneously, e.g. map, online video or games. The number of concurrent sessions are essential to determine the size of port range. It has been learned from subscriber's behaviors that the average session number of a standalone device is around 200~300 ports. Several devices maybe appeared behind a CPE. Operators may configure a range with 1000 ports to each CPE(Customer Premises Equipment) in a residential network. b. Impacts to NAT64 capacity. The pre-assigned port ranges occupy the memory even there are unused ports. NAT64 CGN served a centralized point for numerous subscribes. Therefore, it should be cautious the impacts of port-range reservation to the capacity of attempted concurrent sessions. o Static assignments The static assignment makes a bulk of port reservations for each internal address before subscriber's connection. The bulk of ports could be either a contiguous or non-contiguous port range for the sake of attack defense. [I-D.donley-behave-deterministic-cgn]has described a deterministic NAT to assign a port range for internal IP address pool in a sequence. The difference of the static method with dynamic port-range is address/ports mappings have been established before subscriber's connection attempts. Log recording may not be necessary due to the stable mapping relations. The considerations of port-range allocation and capacity impacts could also be applied to the case of static assignments. 3.3. Centralized vs Distributed There are increasing needs to connect NAT64 with downstream NAT46-capable devices to support IPv4 users/applications on a IPv6-only path. Several solutions have been proposed in this area, e.g. 464xlat[RFC6877], MAP-T[I-D.ietf-softwire-map-t] and 4rd[I-D.ietf-softwire-4rd]. With the feature of double-translation, the port allocation can be categorized as a centralized assignment on NAT64 or a port delegation distributed to downstream devices (e.g, customer edges connected with NAT64) . o Centralized Assignment Chen Expires January 15, 2014 [Page 5] Internet-Draft nat64-port-allocations July 2013 A centralized method would make port assignments once IP flows come to NAT64. The allocation policy is enforced on a centralized point. Either a dynamic or static port assignment is made for received sessions. o Distributed Assignment NAT64 could also delegate the pre-allocated port range to customer edge devices. That can be achieved through additional out-band provisioning signals(e.g. ,[I-D.ietf-pcp-port-set][I-D.ietf-softwire-map-dhcp]). The distributed model normally performs A+P style for static port assignment. NAT64 should hold the consistent mapping in accordance with assigned ports. Those methods could shift NAT64 port computations/states into downstream devices. The detailed benefits was documented in [I-D.ietf-softwire-stateless-4v6-motivation]. 4. Log Volume Optimization [RFC6269] has provided a thoughtful analysis on the issues of IP sharing. It pointed out that IP sharing may bring the impacts to law enforcements since the information of source address would be lost during the translation. Network administrators have to log the mapping status for each connection in order to identify a specific user associated with an IP address in a particular time slot. The storage of log information may post a challenge to operators, since it requires additional transport, storage resources and data inspection process to indentify users. It's desirable to compact the logging information. Referring the categories of port allocation, the assignment could be managed on either per-session or per- customer. The bigger granularity would lead fewer log volume storage. A testing was made to record the log information from 200,000 subscribers for 60 days. The volume of recorded information reach up to 42.5 terabytes with per-session log. Conversely, it only occupy 40.6 gigabytes with per-customer log. There is even a method, which doesn't have to log any information. Whereas, high compression would cause lower efficiency of port utilization. A port allocation based on per-customer granularity have to retain vacant ports in order to avoid traffic overflow. The efficiency could be evaluated by port utilization rate. The below table is trying to make a composite analysis. +-----------------+----------------- +-----------------+-------------------+ |Type of log | Method of port | Log Volume(e.g. | Port utilization | |records | allocations | 200,000 users | ratio | | | | for 60 days) | | +-----------------+---------------- -+-----------------+-------------------+ Chen Expires January 15, 2014 [Page 6] Internet-Draft nat64-port-allocations July 2013 |per-session |Dynamic NAPT | 43.5 Terabytes | 100% | +-----------------+------------------+-----------------+-------------------| |per-customer |Dynamic port-range| 40.6 Gigabytes | 75%(e.g.400 ports)| +-----------------+------------------+-----------------+-------------------+ |None Log |Deterministic NAT,| | 60% *75%= | | |MAP,4rd | 0 | 45% | +-----------------+------------------+-----------------+-------------------+ Note:75% is evaluated for port utilization ratio. 60% is evaluated for the ratio of active subscribers. The data shared in the table may roughly demonstrates the tradeoff between port utilization and log volume compression. The efficiency could be even lower if static bulk-port allocation is used since the ports were pre-allocated to customers regardless online or offline status. Administrator may consider below factors to determine their own solution o Average connectivity per customer per day o Peak connectivity per day o The amount of public IPv4 address in NAT64 o Application demands for specific ports o The processing capabilities of NAT64 o The tolerance of log volume 5. Connectivity State Optimization It's observed that port consumption would be significantly increased when subscribers stick to a web page for VoD (Video On Demand), online games or map services. In those cases, multiple TCP connections may be initiated to optimize the performance of data transmissions for video download and message exchange. With the trends of the video traffic growth, it likely presents a challenge for network operators that need to optimize connectivity states so as to avoid port depletions. Those optimizations may even be significant to the method of port-range allocation, because a subscriber is only allowed to use a pre-configured port resource. The optimization could be considered from two aspects. o Reducing the TIME-WAIT state. Acceleration of TIME-WAIT state transitions could increase the efficiency of port utilization. [RFC6191] defines the mechanism of reducing TIME-WAIT state by Chen Expires January 15, 2014 [Page 7] Internet-Draft nat64-port-allocations July 2013 proposing TCP timestamps and sequence numbers. [I-D.penno-behave-rfc4787-5382-5508-bis] recommended applying [RFC6191] and PAWS (Protect Against Wrapped Sequence numbers described in [RFC1323]) to NAT. It might a way to improve port utilizations. o Another consideration is using Address-Dependent Mapping or Address and Port-Dependent Mapping[RFC4787] to increase the port utilization. This feature has already been implemented as vendor- specific features. Whereas, it should be noted this use didn't recommended by [RFC6888] (e.g. REQ-7) that may reduce the incentives. 6. Port Randomization Port randomization is a feature to enhance the defense of hijack flows. [RFC6056] specified that NAPTs should consider obfuscating the selection of ephemeral ports. A NAPT based on per-session may be less difficult to implement by allocating non-contiguous port to each connection. The methods of port-range allocation have to correlate the algorithm configuration and input parameters between NAT64 and log system to identify the subscribers. In general, a simply algorithm on port assignment is mostly desirable to simplify the log process. It could be considerable to enlarge the size of port range to alleviate security issues, if the port resource is allowed. 7. Security Considerations The non-contiguous port allocations could be considered to enhance the security of port allocations. This document shares the considerations in [RFC6056]. 8. IANA Considerations This document makes no request of IANA. 9. Acknowledgements The author would like to thank Lee Howard and Simon Perreault for their helpful comments. Many thanks to Wesley George and Marc Blanchet encourage the author to continue this work. 10. References 10.1. Normative References Chen Expires January 15, 2014 [Page 8] Internet-Draft nat64-port-allocations July 2013 [I-D.ietf-softwire-map-dhcp] Mrugalski, T., Troan, O., Dec, W., Bao, C., leaf.yeh.sdo@gmail.com, l., and X. Deng, "DHCPv6 Options for Mapping of Address and Port", draft-ietf-softwire-map- dhcp-03 (work in progress), February 2013. [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP Timestamps", BCP 159, RFC 6191, April 2011. [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011. 10.2. Informative References [I-D.anderson-siit-dc] Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data Centre Environments", draft-anderson-siit-dc-00 (work in progress), November 2012. [I-D.donley-behave-deterministic-cgn] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", draft-donley- behave-deterministic-cgn-06 (work in progress), July 2013. [I-D.ietf-pcp-port-set] Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., and S. Perreault, "Port Control Protocol (PCP) Extension for Port Set Allocation", draft-ietf-pcp-port-set-01 (work in progress), May 2013. [I-D.ietf-softwire-4rd] Chen Expires January 15, 2014 [Page 9] Internet-Draft nat64-port-allocations July 2013 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", draft-ietf-softwire-4rd-06 (work in progress), July 2013. [I-D.ietf-softwire-map-t] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", draft-ietf-softwire-map-t-03 (work in progress), July 2013. [I-D.ietf-softwire-stateless-4v6-motivation] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- softwire-stateless-4v6-motivation-05 (work in progress), November 2012. [I-D.penno-behave-rfc4787-5382-5508-bis] Penno, R., Perreault, S., Kamiset, S., Boucadair, M., and K. Naito, "Network Address Translation (NAT) Behavioral Requirements Updates", draft-penno-behave- rfc4787-5382-5508-bis-04 (work in progress), January 2013. [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, January 2011. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013. [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013. Author's Address Chen Expires January 15, 2014 [Page 10] Internet-Draft nat64-port-allocations July 2013 Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: phdgang@gmail.com Chen Expires January 15, 2014 [Page 11]