Analysis of NAT64 Port Allocation Method
draft-chen-sunset4-cgn-port-allocation-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Gang Chen , Tina Tsou (Ting ZOU) , Chris Donley , Tom Taylor | ||
| Last updated | 2014-02-13 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-chen-sunset4-cgn-port-allocation-03
Network Working Group G. Chen
Internet-Draft China Mobile
Intended status: Informational T. Tsou
Expires: August 17, 2014 Huawei Technologies (USA)
C. Donley
CableLabs
T. Taylor
Huawei Technologies
February 13, 2014
Analysis of NAT64 Port Allocation Method
draft-chen-sunset4-cgn-port-allocation-03
Abstract
The document enumerated methods of port assignment in CGN contexts,
more focused on NAT64 environments. The analysis categorized the
different methods with several key features. The uses of existing
protocols are described corresponding to those features. The
document also shared the port-usage experiences, relevant findings,
evaluations and workarounds. It's expected the document could
provide a 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 August 17, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Chen, et al. Expires August 17, 2014 [Page 1]
Internet-Draft cgn-port February 2014
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
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 . . . . . . . . . . . . . . . . . . 4
3.1. NAT vs NAPT . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Dynamic vs Static . . . . . . . . . . . . . . . . . . . . 5
3.3. Centralized vs Distributed . . . . . . . . . . . . . . . 6
4. Port Allocation Solutions . . . . . . . . . . . . . . . . . . 6
4.1. Deterministic CGN . . . . . . . . . . . . . . . . . . . . 6
4.2. MAP-T and 4rd . . . . . . . . . . . . . . . . . . . . . . 7
4.3. PCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Dynamic Port Allocation . . . . . . . . . . . . . . . . . 8
5. Specific Considerations . . . . . . . . . . . . . . . . . . . 8
5.1. Log Volume Optimization . . . . . . . . . . . . . . . . . 9
5.2. Connectivity State Optimization . . . . . . . . . . . . . 10
5.3. Port Randomization . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
With the depletion of IPv4 address, CGN has been adopted by ISPs to
expand IPv4 spaces. Relying upon the mechanism of multiplexing
multiple 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.
[I-D.ietf-behave-lsn-requirements] defined the term of CGN. Several
proposals including DS-Lite[RFC6333], NAT64[RFC6145], [RFC6146],
NAT444 would likely fall into the scope. Focusing on the topic of
IPv6 migration, the memo elaborate the considerations in NAT64
environment, where there IPv6-only nodes are connected.
Chen, et al. Expires August 17, 2014 [Page 2]
Internet-Draft cgn-port February 2014
In regards to port allocations on NAT64, several aspects may have to
consider in order to deploy a suitable method. The below enumerates
the potential considerations.
o Specific features of port-usage 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
The document 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-only
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 connectivity 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 consumption 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 apparent the effects of 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
Chen, et al. Expires August 17, 2014 [Page 3]
Internet-Draft cgn-port February 2014
migration, NAT64 may relax the multiplexing ratio of shared IPv4
address by either a delivered message or a centralized control.
3. Port Allocation Category
This section lists several methods to allocate the port information
in NAT64 equipments. It also described exemplified cases for each
allocation model.
3.1. NAT vs NAPT
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 from two aspects.
o Stateful
The stateful NAT can be implemented either by static address
translation or dynamic address translation.
In the case of static address assignment, 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 environment where there is IPv6 servers pools to receive inbound
connections from IPv4 users externally[I-D.anderson-siit-dc]. The
uses in other cases may be controversial. First off, the static one-
to-one mapping may didn't address the issue of IPv4 depletion.
Secondly, it introduced the dependency of IPv4/IPv6. That would
create new limitations since the change of IPv4 address would cause
renumbering of IPv6 addresses.
Chen, et al. Expires August 17, 2014 [Page 4]
Internet-Draft cgn-port February 2014
3.2. Dynamic vs Static
When the cases come to port assignment, there are two methods on port
allocations.
o Dynamic assignment
NAT64 normally do the dynamic assignment, 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 assignment basically configured on NAT64 by
default for efficient port utilizations. However, a heavy log volume
may have to be recorded for lawful interception system. In order to
mitigate the concerns, NAT64 could dynamically allocate a port range
for each connected subscriber on-demand. It would significantly
reduce log volume. A proper port-range configuration may have to
consider two-folds.
a. The number of session initiations for each subscriber. A
subscriber normally uses multiple applications simultaneously,
e.g. map, online video or game. The number of concurrent
sessions are essential to determine the space of port range. It
has been learned from subscriber's behaviors that the average
session's number of a user's device is around 200~300 ports.
Several devices maybe appeared behind a CPE. Administors may
configure a range with 1000 ports to each CPE in fixed networks.
b. Impacts to NAT64 capacity. The preassigned port ranges occupy
the memory even there are unused ports. Therefore, it should be
cautious the impacts of port-range reservation to the capacity of
attempted concurrent sessions, especially in the case of NAT64
CGN served a centralized point to numerous subscribes.
o Static assignment
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 connectivity 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 assignment.
Chen, et al. Expires August 17, 2014 [Page 5]
Internet-Draft cgn-port February 2014
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, CE
connected with NAT64) .
o Centralized Assignment
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 performed A+P style for static port
assignment. NAT64 should hold the corresponding 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. Port Allocation Solutions
4.1. Deterministic CGN
The deterministic port allocation has been described in
[I-D.donley-behave-deterministic-cgn].This algorithm allows an
operator to identify a subscriber internal IP address when provided
the public side IP and port number without having to examine the CGN
translation logs. Specific port allocation is determined by the
algorithm configured on the CGN. The following variables are
required to be configured:
o Inside IPv4/IPv6 address range (I);
o Outside IPv4 address range (O);
o Compression ratio (e.g. inside IP addresses I/outside IP addresses
O) (C);
Chen, et al. Expires August 17, 2014 [Page 6]
Internet-Draft cgn-port February 2014
o Dynamic address pool factor (D), to be added to the compression
ratio in order to create an overflow address pool;
o Maximum ports per user (M);
o Address assignment algorithm (A);
o Reserved TCP/UDP port list (R).
The reserved ports (R) from the port candidate list (e.g., 0-1023 for
TCP and UDP) can't be allocated to users. Deterministic port
allocation uses the compression ratio (C) to tune the available port
number allocated to per user. It also provides a method to allocate
the ports in a dynamic approach. The CGN calculates the total
compression ratio (C+D), and allocates 1/(C+D) of the available ports
to each internal IP address. Specific port allocation is determined
by the algorithm (A) configured on the CGN. Any remaining ports are
allocated to the dynamic pool, which offers a possibility to allocate
the extra ports when port resource is overused. The log information
generated from the dynamic pool must be recorded.
Address assignment algorithms are configured to regulate the port
assignment method to each subscriber. Subscribers could be
restricted to ports from a single IPv4 address, or could be allocated
ports across all addresses in a pool. The assigned ports could be
sequential, staggered, or cryptographically random. The CGN is not
required to support all algorithms.
4.2. MAP-T and 4rd
The MAP-T and 4rd are designed to allow the coordination between CPEs
and Border Relays (BR) to delegate a port segment to a CPE. A
mapping rules are pre-configured both on the CPEs and BRs in order to
derive the available port numbers from the delegated IPv6 prefix.
The port number is adjusted by the length of IPv4 prefix and EA-bits
and identified by Port-Set Identifier (PSID). Depending on the
mechanism, customer sites can be assigned shared public IPv4
addresses with restricted port sets.
Since the port segment is computed from delegated IPv6 prefix and
IPv4 prefix, it introduces the dependency between the IPv4 and IPv6.
The network planning should consider this restriction for the network
deployment.
Chen, et al. Expires August 17, 2014 [Page 7]
Internet-Draft cgn-port February 2014
4.3. PCP
Port Control Protocol can be used to reserve a single port[RFC6887]
or a port set[I-D.ietf-pcp-port-set] for applications. It requires
NAT is capable of PCP server. A set of port is retrieved through PCP
signaling. The port resource is managed by the lifetime indicated in
PCP request message.
4.4. Dynamic Port Allocation
In order to share the limited supply of IPv4 addresses available in
the network, the dynamic port allocation is a default behavior for a
stateful NAT64[RFC6146]. It will achieve maximum port multiplexing.
[I-D.tsou-behave-natx4-log-reduction]proposes a solution that allows
dynamic sharing of port ranges between users while minimizing the
number of logs that have to be generated. Briefly, ports are
allocated to the user in blocks. Logs are generated only when blocks
are allocated or deallocated. This provides the necessary
traceability while reducing log generation by a factor equal to the
block size, as compared with fully dynamic port allocation.
When the user sends out the first packet, a port resource pool is
allocated for the user, e.g., assigning ports 2001~2300 of a public
IP address to the user's resource pool. Only one log should be
generated for this port block. When the NAT needs to set up a new
mapping entry for the user, it can use a port in the user's resource
pool and the corresponding public IP address. If the user needs more
port resources, the NAT can allocate another port block, e.g., ports
3501~3800, to the user's resource pool. Again, just one log needs to
be generated for this port block. It can also take this idea further
by allocating non- contiguous sets of ports using a pseudorandom
function. Scattering the allocated ports in this way provides a
modest barrier to port guessing attacks.
The CGN can also remove the port block from the resource pool
allocated to a given internal address when there is no port used, and
make it available for other users. The timer for port block
deallocation is suggested to conform with the recommendations for NAT
behaviour for the protocol concerned, then the additional time that
might be configured as a guard for the block as a whole need not be
more than a few minutes.
5. Specific Considerations
Chen, et al. Expires August 17, 2014 [Page 8]
Internet-Draft cgn-port February 2014
5.1. 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 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 low 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
efficiency could be even lower if the method of static port
allocation is used. The ports were pre-allocated to customers
regardless online or offline status. Inactive users may also impact
the efficiency. 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) | |
+-----------------+---------------- -+-----------------+-------------------+
|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. Administrator
may consider below factors to determine their own solution
Chen, et al. Expires August 17, 2014 [Page 9]
Internet-Draft cgn-port February 2014
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.2. Connectivity State Optimization
It's observed that port consumption would be significantly increased
once subscribers stick to a web page for VoD, 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 and avoid port depletion. 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. User's behavior normally correlates
with the system performance. It's rather common that users often
change video channels. It's investigated that 60% of video
watched for less than 20% of their duration. The user's access
patterns may leave a number of the TIME-WAIT states. Therefore,
acceleration of TIME-WAIT state transitions could increase the
efficiency of port utilization. RFC6191[RFC6191] define the
mechanism of reducing TIME-WAIT state by 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 that REQ-7, REQ-12
in[I-D.ietf-behave-lsn-requirements] may reduce the incent
Chen, et al. Expires August 17, 2014 [Page 10]
Internet-Draft cgn-port February 2014
5.3. Port Randomization
Port randomization is a feature to enhance the defense of hijack
flows. [RFC6056] specified that "A NAPT that does not implement port
preservation [RFC4787] ,[RFC5382] should obfuscate selection of the
ephemeral port of a packet when it is changed during translation of
that packet." A NAPT based on per-session normally follow the
recommendation. However, a simply algorithm on port assignment is
mostly desirable for a deterministic NAT even there is hijack
vulnerability.
6. Security Considerations
The non-contiguous port allocations could be considered to enhance
the security of port allocations. This document shares the
considerations in [RFC6056].
7. IANA Considerations
This document makes no request of IANA.
8. References
8.1. Normative References
[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 configuration of Softwire Address and Port Mapped
Clients", draft-ietf-softwire-map-dhcp-06 (work in
progress), November 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.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, January
2011.
Chen, et al. Expires August 17, 2014 [Page 11]
Internet-Draft cgn-port February 2014
[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.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
8.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-07 (work in progress), January
2014.
[I-D.ietf-behave-lsn-requirements]
Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
and H. Ashida, "Common requirements for Carrier Grade NATs
(CGNs)", draft-ietf-behave-lsn-requirements-10 (work in
progress), December 2012.
[I-D.ietf-pcp-port-set]
Qiong, 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-04 (work in progress), November 2013.
Chen, et al. Expires August 17, 2014 [Page 12]
Internet-Draft cgn-port February 2014
[I-D.ietf-pcp-port-set]
Qiong, 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-04 (work in progress), November 2013.
[I-D.ietf-softwire-4rd]
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-07 (work in
progress), October 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-05 (work
in progress), February 2014.
[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.
[I-D.tsou-behave-natx4-log-reduction]
Tsou, T., Li, W., Taylor, T., and J. Huang, "Port
Management To Reduce Logging In Large-Scale NATs", draft-
tsou-behave-natx4-log-reduction-04 (work in progress),
July 2013.
[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.
Chen, et al. Expires August 17, 2014 [Page 13]
Internet-Draft cgn-port February 2014
Authors' Addresses
Gang Chen
China Mobile
53A,Xibianmennei Ave.,
Xuanwu District,
Beijing 100053
China
Email: phdgang@gmail.com
Tina Tsou
Huawei Technologies (USA)
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1 408 330 4424
Email: tina.tsou.zouting@huawei.com
Chris Donley
CableLabs
858 Coal Creek Cir
Louisville, CO 80027
US
Email: c.donley@cablelabs.com
Tom Taylor
Huawei Technologies
Ottawa
Canada
Email: tom.taylor.stds@gmail.com
Chen, et al. Expires August 17, 2014 [Page 14]