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]