[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                             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]


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