[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 01 02 03 04 05

Network Working Group                                            G. Chen
Internet-Draft                                              China Mobile
Intended status: Informational                                   T. Tsou
Expires: August 17, 2014                       Huawei Technologies (USA)
                                                               C. Donley
                                                               T. Taylor
                                                     Huawei Technologies
                                                       February 13, 2014

                Analysis of NAT64 Port Allocation Method


   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

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

   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

   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

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

   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

+-----------------+----------------- +-----------------+-------------------+
|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

   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

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

              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

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

8.2.  Informative References

              Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data
              Centre Environments", draft-anderson-siit-dc-00 (work in
              progress), November 2012.

              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

              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.

              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

              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.

              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.

              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.

              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.

              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.

              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

   [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

   Email: phdgang@gmail.com

   Tina Tsou
   Huawei Technologies (USA)
   2330 Central Expressway
   Santa Clara, CA  95050

   Phone: +1 408 330 4424
   Email: tina.tsou.zouting@huawei.com

   Chris Donley
   858 Coal Creek Cir
   Louisville, CO  80027

   Email: c.donley@cablelabs.com

   Tom Taylor
   Huawei Technologies

   Email: tom.taylor.stds@gmail.com

Chen, et al.             Expires August 17, 2014               [Page 14]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/