draft-ietf-sunset4-nat64-port-allocation-00.txt   draft-ietf-sunset4-nat64-port-allocation-01.txt 
Network Working Group G. Chen Network Working Group G. Chen
Internet-Draft China Mobile Internet-Draft China Mobile
Intended status: Informational W. Li Intended status: Informational W. Li
Expires: November 19, 2015 China Telecom Expires: January 23, 2016 China Telecom
T. Tsou T. Tsou
J. Huang J. Huang
Huawei Technologies Huawei Technologies
T. Taylor T. Taylor
PT Taylor Consulting PT Taylor Consulting
May 18, 2015 JF. Tremblay
Viagenie
July 22, 2015
Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses
draft-ietf-sunset4-nat64-port-allocation-00 draft-ietf-sunset4-nat64-port-allocation-01
Abstract Abstract
This document enumerates methods of port assignment in Carrier Grade This document enumerates methods of port assignment in Carrier Grade
NATs (CGNs), focused particularly on NAT64 environments. A NATs (CGNs), focused particularly on NAT64 environments. Different
theoretical framework of different NAT port allocation methods is NAT port allocation methods have been categorized and described. A
described. The memo is intended to clarify and focus the port series of port allocation design principles has been proposed to
allocation discussion and propose an integrated view of the facilitate the implementations and deployment.
considerations for selection of the port allocation mechanism in a
given deployment.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 19, 2015. This Internet-Draft will expire on January 23, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Considerations for the Choice of Port Allocation Methods . . 3 2. Description of Port Allocation Methods . . . . . . . . . . . 3
2.1. Port Consumption on NAT64 . . . . . . . . . . . . . . . . 3 2.1. Specific Feature of NAT64 Port Consumption . . . . . . . 3
2.2. Classification of Port Allocation Models . . . . . . . . 4 2.2. Classification of Port Allocation Models . . . . . . . . 3
2.2.1. Stateful vs. Stateless . . . . . . . . . . . . . . . 4 2.2.1. Stateful vs. Stateless . . . . . . . . . . . . . . . 3
2.2.2. Dynamic vs. Static . . . . . . . . . . . . . . . . . 5 2.2.2. Dynamic vs. Static . . . . . . . . . . . . . . . . . 4
2.2.3. Centralized vs. Distributed . . . . . . . . . . . . . 6 2.2.3. Centralized vs. Distributed . . . . . . . . . . . . . 5
2.3. Port Allocation Solutions . . . . . . . . . . . . . . . . 6 2.3. Port Allocation Solutions . . . . . . . . . . . . . . . . 6
2.3.1. Other Transition Technologies . . . . . . . . . . . . 6 2.3.1. Stateful Technologies . . . . . . . . . . . . . . . . 6
2.3.2. Stateless Transition Technologies . . . . . . . . . . 7 2.3.2. Stateless Technologies . . . . . . . . . . . . . . . 6
2.3.3. Port Control Protocol (PCP) . . . . . . . . . . . . . 8 2.3.3. Port Control Protocol (PCP) . . . . . . . . . . . . . 7
2.4. Specific Considerations . . . . . . . . . . . . . . . . . 8 3. Port Allocation Design Principles . . . . . . . . . . . . . . 7
2.4.1. Log Volume Optimization . . . . . . . . . . . . . . . 8 3.1. Log Volume Optimization . . . . . . . . . . . . . . . . . 7
2.4.2. Connectivity State Optimization . . . . . . . . . . . 9 3.2. Connectivity State Optimization . . . . . . . . . . . . . 9
2.4.3. Port Randomization . . . . . . . . . . . . . . . . . 10 3.3. Port Randomization . . . . . . . . . . . . . . . . . . . 9
3. Considerations for the Dynamic Assignment of Port-Ranges . . 10 3.4. Port-range Implementation Recommendation . . . . . . . . 10
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. Port Randomization and Port-Range Deallocation . . . 10
3.2. Implementation Issues -- Port Randomization and Port- 3.4.2. Issues Of Traceability . . . . . . . . . . . . . . . 11
Range Deallocation . . . . . . . . . . . . . . . . . . . 11 3.4.3. Other Considerations . . . . . . . . . . . . . . . . 12
3.3. Issues Of Traceability . . . . . . . . . . . . . . . . . 13 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
3.4. Other Considerations . . . . . . . . . . . . . . . . . . 13 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
As a result of the depletion of public IPv4 addresses, Carrier Grade As a result of the depletion of public IPv4 addresses, Carrier Grade
NAT (CGN) has been adopted by ISPs to share the available IPv4 NAT (CGN) has been adopted by ISPs to share the available IPv4
resources. Overall, a CGN function maps IP addresses from one resources. Overall, a CGN function maps IP addresses from one
address realm to another, relying upon a mechanism of multiplexing address realm to another, relying upon a mechanism of multiplexing
multiple subscribers' connections over a number of shared IPv4 multiple subscribers' connections over a number of shared IPv4
addresses to provide connectivity services to end hosts. A network- addresses to provide connectivity services to end hosts. A network-
based NAT is implied by several approaches to IPv4 service continuity based NAT is implied by several approaches to IPv4 service continuity
over an IPv6 network including DS-Lite [RFC6333], NAT64 ([RFC6145] over an IPv6 network including DS-Lite [RFC6333], NAT64 ([RFC6145]
and [RFC6146]), etc. and [RFC6146]), etc.
Section 2) focusses on the topic of IPv6 migration. When NAPT is In this memo, Section 2 has described the category of port allocation
involved, Section 2 elaborates on the considerations for address mechnism and relevant solutions. Section 3 looks more closely at
sharing and particularly port assignment in the NAT64 environment. different port allocation design principles, including log volume
consideration, connectivity state optimization, Port-range
Section 3 looks more closely at dynamic bulk assignment of ports to implementation and port randomization. The proposals made in this
individual subscriber sites, particularly as a means to reduce the section are applicable to the CGN environment in general,
volume of log files. The proposals made in this section are independently of the particular flavor of translation being used.
applicable to the CGN environment in general, independently of the
particular flavor of translation being used.
2. Considerations for the Choice of Port Allocation Methods
For port allocations on NAT64, several aspects may have to be
considered when selecting a suitable method. Here is a list of the
potential considerations, which are covered in more detail below.
o specific features of port usage in a NAT64 environment;
o classification of different port allocation methods;
o port allocation to improve connectivity;
o port allocation to optimize log volume;
o port allocation to enhance security.
Both analysis and relevant experimental results are presented in the 2. Description of Port Allocation Methods
sub-sections that follow.
2.1. Port Consumption on NAT64 2.1. Specific Feature of NAT64 Port Consumption
China Mobile did a test comparison of port consumption on NAT64 and There was a test comparison of port consumption [RFC7269] on NAT64
NAT44. Top100 websites (referring to Alexa statistics) were assessed and NAT44. Top100 websites (referring to Alexa statistics) were
to evaluate status of port usage on NAT44 and NAT64 respectively. assessed to evaluate status of port usage on NAT44 and NAT64
China Mobile observed that the port consumption per session on NAT64 respectively. It has been observed that the port consumption per
is roughly only half that on NAT44. 43 percent of top100 websites session on NAT64 is roughly only half that on NAT44. 43 percent of
have AAAA records, therefore the NAT64 didn't have to assign ports to top100 websites have AAAA records, therefore the NAT64 didn't have to
the traffic going to those websites. The results may be different if assign ports to the traffic going to those websites. The results may
more services (e.g. game, web-mail, etc) are considered. But it is be different if more services (e.g. game, web-mail, etc) are
apparent that the effects of port saving on NAT64 will be amplified considered. But it is apparent that the effects of port saving on
by increasing native IPv6 support. NAT64 will be amplified by increasing native IPv6 support.
Apart from the above observation, port allocation can be tuned Apart from the above observation, port allocation can be tuned
according to the phase of IPv6 migration. As more content providers according to the phase of IPv6 migration. As more content providers
and services become available over IPv6, the utilization of NAT64 and services become available over IPv6, the utilization of NAT64
goes down since fewer destinations require translation progressing. goes down since fewer destinations require translation progressing.
Thus as IPv6 migration proceeds, it will be possible to relax the Thus as IPv6 migration proceeds, it will be possible to relax the
multiplexing ratio of IPv4 address sharing (see Appendix B of multiplexing ratio of IPv4 address sharing (see Appendix B of
[RFC6269]). [RFC6269]).
2.2. Classification of Port Allocation Models 2.2. Classification of Port Allocation Models
This section lists several models to allocate the port information in This section lists several categories to allocate the port
NAT64. It also describes example cases for each allocation model. information in NAT64. It also describes example cases for each
allocation model.
2.2.1. Stateful vs. Stateless 2.2.1. Stateful vs. Stateless
o Stateful o Stateful
The stateful NAT can be implemented either by static address The stateful NAT can be implemented either by static address
translation or dynamic address translation. translation or dynamic address translation.
In the case of static address assignment, a one-to-one address In the case of static address assignment, a one-to-one address
mapping for hosts between a IPv6 network address and an IPv4 mapping for hosts between a IPv6 network address and an IPv4
skipping to change at page 5, line 23 skipping to change at page 4, line 49
utilization. Port allocations can be made with per-session or utilization. Port allocations can be made with per-session or
per-customer granularity. Per-session assignment is configured on per-customer granularity. Per-session assignment is configured on
the NAT64 by default since it maximizes port utilization. the NAT64 by default since it maximizes port utilization.
However, if only individual port numbers are assigned, this can However, if only individual port numbers are assigned, this can
result in a heavy log volume that may have to be recorded for result in a heavy log volume that may have to be recorded for
legal data retention systems. To mitigate that concern, the NAT64 legal data retention systems. To mitigate that concern, the NAT64
may dynamically allocate a port range for each connected may dynamically allocate a port range for each connected
subscriber or upon receipt of a first outgoing packet from an IPv6 subscriber or upon receipt of a first outgoing packet from an IPv6
host. This will significantly reduce log volume. host. This will significantly reduce log volume.
A proper port-range configuration may have to take into account A proper port-range configuration should take user experiences
two considerations: into the considerations. A subscriber normally uses multiple
applications simultaneously, e.g. maps applications, online video
A. The number of session initiations for each subscriber. A or game. The number of concurrent sessions is essential to
subscriber normally uses multiple applications simultaneously, determine the number of ports the subscriber needs. A study from
e.g. maps applications, online video or game. The number of China Mobile has revealed that the average number of sessions
concurrent sessions is essential to determine the number of consumed by one user's device was around 200 to 300 ports.
ports the subscriber needs. The China Mobile study mentioned Several devices may appear behind a CPE. Based on this
earlier observed that the average number of sessions consumed observation, 1000 ports per subscriber household will provide
by one user's device was around 200 to 300 ports. Several enough room for multiple active users. Administrators should
devices may appear behind a CPE. Based on this observation, monitor usage to adjust this number if users are being limited by
1000 ports per subscriber household will provide enough room this number, or if usage is so low that fewer ports would be
for multiple active users. Administrators should monitor sufficient.
usage to adjust this number if users are being limited by this
number, or if usage is so low that fewer ports would be
sufficient.
B. Impacts on NAT64 capacity. Preassigned port ranges occupy
memory even when there are unused ports. Therefore, the
operator should be cautious about the impact of port-range
reservation on the capacity for attempted concurrent sessions,
especially in the case of a centralized NAT64 serving numerous
subscribers.
o Static assignment o Static assignment
Static assignment makes port reservations in bulk for each Static assignment makes port reservations in bulk for each
internal address before subscriber connection. The assigned ports internal address before subscriber connection. The assigned ports
can be in either a contiguous port range or a non-contiguous port can be in either a contiguous port range or a non-contiguous port
range for the sake of defense against port-guessing attacks (see range for the sake of defense against port-guessing attacks (see
Section 3.2). Log recording for each port assignment may not be Section 3.4.1). Log recording for each port assignment may not be
necessary due to the stable mapping relations. Considerations of necessary due to the stable mapping relations. Considerations of
the interaction between port-range allocation and capacity impact the interaction between port-range allocation and capacity impact
are also applicable in the case of static assignment. [RFC7422] are also applicable in the case of static assignment. [RFC7422]
describes a deterministic algorithm to assign a port range for an describes a deterministic algorithm to assign a port range for an
internal IP address pool in a sequence. internal IP address pool in a sequence.
2.2.3. Centralized vs. Distributed 2.2.3. Centralized vs. Distributed
There is an increasing need to connect NAT64 with downstream There is an increasing need to connect NAT64 with downstream
NAT46-capable devices to support IPv4 users/applications on an NAT46-capable devices to support IPv4 users/applications on an
skipping to change at page 6, line 44 skipping to change at page 6, line 12
performed A+P style [RFC6346] for static port assignment. The performed A+P style [RFC6346] for static port assignment. The
NAT64 should also hold the corresponding mapping in order to NAT64 should also hold the corresponding mapping in order to
validate port usage in the outgoing direction and route inbound validate port usage in the outgoing direction and route inbound
packets. Delegated port ranges shift NAT64 port computations/ packets. Delegated port ranges shift NAT64 port computations/
states into downstream devices. The detailed benefits of this states into downstream devices. The detailed benefits of this
approach are documented in approach are documented in
[I-D.ietf-softwire-stateless-4v6-motivation]. [I-D.ietf-softwire-stateless-4v6-motivation].
2.3. Port Allocation Solutions 2.3. Port Allocation Solutions
2.3.1. Other Transition Technologies 2.3.1. Stateful Technologies
[RFC6146] describes a process where the dynamic binding is created by [RFC6146] describes a process where the dynamic binding is created by
an outgoing packet, but it may also be created by other means such as an outgoing packet, but it may also be created by other means such as
a Port Control Protocol request (see Section 2.3.3). Lookin beyond a Port Control Protocol request (see Section 2.3.3). Looking beyond
NAT64 for the moment, DS-Lite [RFC6333] refers to the cautions in NAT64 for the moment, DS-Lite [RFC6333] refers to the cautions in
[RFC6269] but does not specify any port allocation method. Both [RFC6269] but does not specify any port allocation method. Both
techniques DS-Lite and NAT64 assume a centralized model. techniques DS-Lite and NAT64 assume a centralized model.
The specifications for both transition methods thus allow The specifications for both transition methods thus allow
implementations to use the proposals made in Section 3 (and implementations to use the proposals made in individual port
[RFC7422]). allocation and port range allocation
2.3.2. Stateless Transition Technologies 2.3.2. Stateless Technologies
The port allocation solutions that are being specified at the time of The port allocation solutions that are being specified at the time of
writing of this document are all variations on the static distributed writing of this document are all variations on the static distributed
model, to minimize the amount of state that has to be held in the model, to minimize the amount of state that has to be held in the
network. The proposals made in Section 3 do not apply to the current network. That work includes:
work in progress because that work has gone in another direction.
That work includes:
o Light-weight 4over6 (LW4o6 [I_D.ietf-softwire-lw4over6]), which o Light-weight 4over6 (LW4o6 [I_D.ietf-softwire-lw4over6]), which
requires the CPE to be configured explicitly with the shared IPv4 requires the CPE to be configured explicitly with the shared IPv4
address and port set it will use on the WAN side of its NAT44 address and port set it will use on the WAN side of its NAT44
function. The border router is configured with the same function. The border router is configured with the same
information, reducing the state it must hold from per-session to information, reducing the state it must hold from per-session to
per-subscriber amounts. per-subscriber amounts.
o Mapping of Address and Port with Encapsulation (MAP-E o Mapping of Address and Port with Encapsulation (MAP-E
[I-D.ietf-softwire-map]) and the experimental specifications [I-D.ietf-softwire-map]) and the experimental specifications
skipping to change at page 8, line 14 skipping to change at page 7, line 27
2.3.3. Port Control Protocol (PCP) 2.3.3. Port Control Protocol (PCP)
The Port Control Protocol (PCP, [RFC6887]) can be used to reserve a The Port Control Protocol (PCP, [RFC6887]) can be used to reserve a
single port or a port set [I-D.ietf-pcp-port-set] for applications. single port or a port set [I-D.ietf-pcp-port-set] for applications.
It requires that the NAT be controlled by a PCP server function. PCP It requires that the NAT be controlled by a PCP server function. PCP
provides an out-of-band signalling mechanism for coordinating dynamic provides an out-of-band signalling mechanism for coordinating dynamic
allocation of ports between hosts and the border router, removes the allocation of ports between hosts and the border router, removes the
need for ALGs, allows for successful incoming connections, etc. need for ALGs, allows for successful incoming connections, etc.
2.4. Specific Considerations 3. Port Allocation Design Principles
2.4.1. Log Volume Optimization 3.1. Log Volume Optimization
[RFC6269] provides a thoughtful analysis on the issues of IP address [RFC6269] provides a thoughtful analysis on the issues of IP address
sharing. It points out that IP address sharing may impact law sharing. It points out that IP address sharing may impact law
enforcement since source address information will be lost during the enforcement since source address information will be lost during the
translation. Network administrators have to log the mapping status translation.In order to identify a specific user associated with an
for each connection in order to identify a specific user associated IP address in a particular time slot, network administrators have to
with an IP address in a particular time slot. The storage of log log the mapping status for each connection in a dedicated logging
information may pose a challenge to operators, since it requires server. The storage of log information may pose a challenge to
additional resources and data inspection processes to identify users. operators, since it requires additional resources and data inspection
For concrete details of what should be logged, see Section 3.1 of processes to identify users. For concrete details of what should be
[I-D.ietf-behave-syslog-nat-logging]. The actual logging may use logged, see Section 3.1 of [I-D.ietf-behave-syslog-nat-logging]. The
either IPFIX [RFC7011] or Syslog [RFC5424] depending on the actual logging may use either IPFIX [RFC7011] or Syslog [RFC5424]
operator's requirements. depending on the operator's requirements.
It is desirable to reduce the volume of the logged information. It is desirable to reduce the volume of the logged information.
Referring to the classification of port allocation methods given Referring to the classification of port allocation methods given
above, dynamic assignments can be managed on either a per-session or above, dynamic assignments can be managed on either a per-session or
per-customer granularity. The coarser granularity will lead to lower per-customer granularity. The coarser granularity will lead to lower
log volume storage. A test was made by recording the log information log volume storage. A test was made by recording the log information
from 200,000 subscribers in the Chinese network for 60 days. The from 200,000 subscribers in the Chinese network for 60 days. The
volume of recorded information reached up to 42.5 terabytes with per- volume of recorded information reached up to 42.5 terabytes with per-
session logging in the raw format. The volume could be reduced to session logging in the raw format. The volume could be reduced to
10.6 terabytes with gzip format. Compared with that, it only 10.6 terabytes with gzip format. Compared with that, it only
occupied 40.6 gigabytes, three orders of magnitude smaller volume, occupied 40.6 gigabytes, three orders of magnitude smaller volume,
with per-customer logging in the raw format. With static allocation, with per-customer logging in the raw format (A port range sized by
of course, no logs for port assignment are required, but a record of 1000 ports have been used). With static allocation, of course, no
the configuration change is still required. logs for port assignment are required, but a record of the
configuration change is still required.
On the other hand, the lower logging volumes are associated with On the other hand, the lower logging volumes are associated with
lower efficiency of port utilization. A port allocation based on lower efficiency of port utilization. A port allocation based on
per-customer granularity has to retain vacant ports in order to avoid per-customer granularity has to retain vacant ports in order to avoid
traffic overflow. The efficiency can be evaluated by port traffic overflow. The efficiency can be evaluated by port
utilization rate, and will be even lower if the static port utilization rate, and will be even lower if the static port
allocation method is used. Inactive users may also impact the allocation method is used. Inactive users may also impact the
efficiency. efficiency.
Table 1 summarizes the test results using Syslog. The ports were Table 1 summarizes the test results using Syslog. The ports were
skipping to change at page 9, line 38 skipping to change at page 9, line 4
o average connectivity per customer per day; o average connectivity per customer per day;
o peak connectivity per day; o peak connectivity per day;
o the number of public IPv4 addresses available to the NAT64; o the number of public IPv4 addresses available to the NAT64;
o application demands for specific ports; o application demands for specific ports;
o processing capabilities of the NAT64; o processing capabilities of the NAT64;
o tolerable log volume. o tolerable log volume.
2.4.2. Connectivity State Optimization 3.2. Connectivity State Optimization
It has been observed that port consumption is significantly increased It has been observed that port consumption is significantly increased
once subscribers land on a web page for video on demand, an online once subscribers land on a web page for video on demand, an online
game, or map services. In those cases, multiple TCP connections may game, or map services. In those cases, multiple TCP connections may
be initiated to optimize the performance of data transmissions for be initiated to optimize the performance of data transmissions for
video download and message exchange. Given the video traffic growth video download and message exchange. Given the video traffic growth
trend, this likely presents a challenge for network operators who trend, this likely presents a challenge for network operators who
need to optimize connectivity states and avoid port depletion. Those need to optimize connectivity states and avoid port depletion. Those
optimizations may even affect the method of port-range allocation, optimizations may even affect the method of port-range allocation,
because a subscriber is only allowed to use a pre-configured port because a subscriber is only allowed to use a pre-configured port
resource. resource.
Two optimizations may be considered: Two optimizations may be considered:
o Reducing the TIME-WAIT state. The user's behavior normally o Reducing the TIME-WAIT state. It is rather common that users
correlates with system performance. It is rather common that change video channels often. Investigations have shown that 60%
users change video channels often. Investigations have shown that of videos are watched for less than 20% of their duration. The
60% of videos are watched for less than 20% of their duration. user's access patterns may leave a number of the TIME-WAIT states.
The user's access patterns may leave a number of the TIME-WAIT Therefore, acceleration of TIME-WAIT state transitions could
states. Therefore, acceleration of TIME-WAIT state transitions increase the efficiency of port utilization. [RFC6191] defines a
could increase the efficiency of port utilization. [RFC6191] mechanism for reducing TIME-WAIT state by proposing TCP timestamps
defines a mechanism for reducing TIME-WAIT state by proposing TCP and sequence numbers.
timestamps and sequence numbers.
[I-D.penno-behave-rfc4787-5382-5508-bis] recommended applying [I-D.penno-behave-rfc4787-5382-5508-bis] recommended applying
[RFC6191] and PAWS (Protect Against Wrapped Sequence numbers, [RFC6191] and PAWS (Protect Against Wrapped Sequence numbers,
described in [RFC1323]) to NAT. This may also be a way to improve described in [RFC1323]) to NAT. This may also be a way to improve
port utilization. port utilization.
o Another possibility is to use Address-Dependent Mapping or Address o Another possibility is to use Address-Dependent Mapping or Address
and Port-Dependent Mapping [RFC4787] to increase port utilization. and Port-Dependent Mapping [RFC4787] to increase port utilization.
This feature has already been implemented on a vendor-specific This feature has already been implemented on a vendor-specific
basis. However, it should be noted that REQ-7 and REQ-12 in basis. However, it should be noted that REQ-7 and REQ-12 in
[RFC6888] may reduce the incentive to use anything but the [RFC6888] may reduce the incentive to use anything but the
Address-Independent Mapping behaviour recommended by [RFC4787]. Address-Independent Mapping behaviour recommended by [RFC4787].
2.4.3. Port Randomization 3.3. Port Randomization
Port randomization is a feature to enhance the defense against Port randomization is a feature to enhance the defense against
hijacking of flows. [RFC6056] specifies that: hijacking of flows. [RFC6056] specifies that:
"A NAPT that does not implement port preservation ([RFC4787], "A NAPT that does not implement port preservation ([RFC4787],
[RFC5382]) should obfuscate selection of the ephemeral port of a [RFC5382]) should obfuscate selection of the ephemeral port of a
packet when it is changed during translation of that packet." packet when it is changed during translation of that packet."
A NAPT based on per-session allocation normally follows this A NAPT based on per-session allocation normally follows this
recommendation. recommendation.
See Section 4 for a fuller discussion of port randomization. See Section 4 for a fuller discussion of port randomization.
3. Considerations for the Dynamic Assignment of Port-Ranges 3.4. Port-range Implementation Recommendation
3.1. Motivation
During the IPv6 transition period, large-scale NAT devices may be
introduced, e.g. DS-Lite AFTR, NAT64. When a NAT device needs to
set up a new connection for a given internal address behind the NAT,
it needs to create a new mapping entry for the new connection, which
will contain source IP address, source port or ICMP identifier,
converted source IP address, converted source port, protocol (TCP/
UDP), etc.
For various reasons it is necessary to log these mappings. Some high
performance NAT devices may need to create a large amount of new
sessions per second. As discussed in Section 2.4.1, if the logs are
generated for each mapping entry, the log traffic could reach tens of
megabytes per second or more, which would be a problem for log
generation, transmission and storage. (The per-session volumes in
Table 1 amount to 42 bytes per served subscriber per second. The
volumes reported in the introduction to [RFC7422] for U.S. users are
even higher, around 58 bytes per second per subscriber served.)
[RFC6888], REQ-13, REQ-14, and REQ-15 deal explicitly with port
allocation schemes and logging. However, it is recognized that these
are conflicting requirements, requiring a tradeoff between the
efficiency with which ports are used and the rate of generation of
log records.
Allocating a range of N ports at once reduces the log volume by a Allocating a range of N ports at once reduces the log volume by a
factor of N, while also reducing port utilization by a factor which factor of N, while also reducing port utilization by a factor which
varies with the address sharing ratio and other configuration varies with the address sharing ratio and other configuration
parameters. This provides a clear motivation to use dynamic parameters. This provides a clear motivation to use dynamic
allocation of port-ranges rather than individual ports when it is allocation of port-ranges rather than individual ports when it is
possible to do so while maintaining a satisfactory level of port possible to do so while maintaining a satisfactory level of port
utilization (and by implication, shared global IPv4 address utilization (and by implication, shared global IPv4 address
utilization). utilization). Dynamic allocation of port ranges may be used either
as the sole strategy for port allocation on the NAPT, or as a
Dynamic allocation of port ranges may be used either as the sole supplement to an initial static allocation. This section will
strategy for port allocation on the NAPT, or as a supplement to an provide specific consideration to the implementation.
initial static allocation.
3.2. Implementation Issues -- Port Randomization and Port-Range 3.4.1. Port Randomization and Port-Range Deallocation
Deallocation
When the user sends out the first packet, a port resource pool is 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 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 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 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 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 pool and the corresponding public IP address. If the user needs more
port resources, the NAT can allocate another port block, e.g., ports 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 3501~3800, to the user's resource pool. Again, just one log needs to
be generated for this port block. be generated for this port block.
skipping to change at page 12, line 32 skipping to change at page 11, line 18
(sessions) within the block, and these conform to the recommendations (sessions) within the block, and these conform to the recommendations
for NAT behaviour for the protocol concerned, then the additional for NAT behaviour for the protocol concerned, then the additional
time that might be configured as a guard for the block as a whole time that might be configured as a guard for the block as a whole
need not be more than a few minutes. The block timer in this case need not be more than a few minutes. The block timer in this case
serves only as a slightly more conservative extension of the serves only as a slightly more conservative extension of the
individual session idle timers. If, instead, a single idle timer is individual session idle timers. If, instead, a single idle timer is
used for the whole block, it must itself conform to the used for the whole block, it must itself conform to the
recommendations for the protocol with which that block of ports is recommendations for the protocol with which that block of ports is
associated. For example, REQ-5 of [RFC5382] requires an idle timer associated. For example, REQ-5 of [RFC5382] requires an idle timer
expiry duration of at least 2 hours and 4 minutes for TCP. The expiry duration of at least 2 hours and 4 minutes for TCP. The
suggestions made in Section 2.4.2 may be considered for reducing this suggestions made in Section 3.2 may be considered for reducing this
time. time.
The next issue with port block deallocation is the conflict between The next issue with port block deallocation is the conflict between
the desire to randomize port allocation and the desire to make unused the desire to randomize port allocation and the desire to make unused
resources available to other internal addresses. As mentioned above, resources available to other internal addresses. As mentioned above,
ideally port selection will take place over the entire set of blocks ideally port selection will take place over the entire set of blocks
allocated to the internal address. However, taken to its fullest allocated to the internal address. However, taken to its fullest
extent, such a policy will minimize the probability that all ports in extent, such a policy will minimize the probability that all ports in
any given block are idle long enough for it to be released. any given block are idle long enough for it to be released.
skipping to change at page 13, line 7 skipping to change at page 11, line 41
block that has been idle the longest, unless no ports are available block that has been idle the longest, unless no ports are available
in any of the other blocks. The expression "block that has been idle in any of the other blocks. The expression "block that has been idle
the longest" designates the block in which the time since the last the longest" designates the block in which the time since the last
packet was observed in any of its sessions, in either direction, is packet was observed in any of its sessions, in either direction, is
earlier than the corresponding time in any of the other blocks earlier than the corresponding time in any of the other blocks
assigned to that internal address. As [RFC6269] points out, port assigned to that internal address. As [RFC6269] points out, port
randomization is just one security measure of several, and the loss randomization is just one security measure of several, and the loss
of randomness incurred by the suggested procedure is justified by the of randomness incurred by the suggested procedure is justified by the
increased utilization of port resources it allows. increased utilization of port resources it allows.
3.3. Issues Of Traceability 3.4.2. Issues Of Traceability
Section 12 of [RFC6269] provides a good discussion of the Section 12 of [RFC6269] provides a good discussion of the
traceability issue. Complete traceability given the NAT logging traceability issue. Complete traceability given the NAT logging
practices proposed in this draft requires that the remote destination practices proposed in this draft requires that the remote destination
record the source port of a request along with the source address record the source port of a request along with the source address
(and presumably protocol, if not implicit) [RFC6302]. In addition, (and presumably protocol, if not implicit) [RFC6302]. In addition,
the logs at each end must be timestamped, and the clocks must be the logs at each end must be timestamped, and the clocks must be
synchronized within a certain degree of accuracy. Here is one reason synchronized within a certain degree of accuracy. Here is one reason
for the guard timing on block release, to increase the tolerable for the guard timing on block release, to increase the tolerable
level of clock skew between the two ends. level of clock skew between the two ends.
skipping to change at page 13, line 42 skipping to change at page 12, line 28
The final possibility to consider is where the NAT does not do per- The final possibility to consider is where the NAT does not do per-
session logging even given the possibility that the remote end is session logging even given the possibility that the remote end is
failing to capture source ports. In that case, the port allocation failing to capture source ports. In that case, the port allocation
strategy proposed in this section can be used. The impact on strategy proposed in this section can be used. The impact on
traceability is that analysis of the logs would yield only the list traceability is that analysis of the logs would yield only the list
of all internal addresses mapped to a given public address during the of all internal addresses mapped to a given public address during the
period of time concerned. This has an impact on privacy as well as period of time concerned. This has an impact on privacy as well as
traceability, depending on the follow-up actions taken. traceability, depending on the follow-up actions taken.
3.4. Other Considerations 3.4.3. Other Considerations
[RFC6269] notes several issues introduced by the use of dynamic as [RFC6269] notes several issues introduced by the use of dynamic as
opposed to static port assignment. For example, Section 12.2 of that opposed to static port assignment. For example, Section 12.2 of that
document notes the effect on authentication procedures. These issues document notes the effect on authentication procedures. These issues
must be resolved, but are not specific to the dynamic port-range must be resolved, but are not specific to the dynamic port-range
allocation strategy. allocation strategy.
4. Security Considerations 4. Security Considerations
The discussion which follows addresses an issue that is particularly The discussion which follows addresses an issue that is particularly
skipping to change at page 15, line 50 skipping to change at page 14, line 37
encouragement to publication after a hiatus of two years. encouragement to publication after a hiatus of two years.
The present version of the document benefited from further comments The present version of the document benefited from further comments
by Lee Howard and Mohamed Boucadair. by Lee Howard and Mohamed Boucadair.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, January Protocol Port Randomization", BCP 156, RFC 6056,
2011. DOI 10.17487/RFC6056, January 2011,
<http://www.rfc-editor.org/info/rfc6056>.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011,
<http://www.rfc-editor.org/info/rfc6145>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, April 2011. Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
Roberts, "Issues with IP Address Sharing", RFC 6269, June P. Roberts, "Issues with IP Address Sharing", RFC 6269,
2011. DOI 10.17487/RFC6269, June 2011,
<http://www.rfc-editor.org/info/rfc6269>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-behave-syslog-nat-logging] [I-D.ietf-behave-syslog-nat-logging]
Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog Chen, Z., Zhou, C., Tsou, T., and T. Taylor, "Syslog
Format for NAT Logging (Work in Progress)", January 2014. Format for NAT Logging (Work in Progress)", January 2014.
[I-D.ietf-pcp-port-set] [I-D.ietf-pcp-port-set]
Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T., Sun, Q., Boucadair, M., Sivakumar, S., Zhou, C., Tsou, T.,
and S. Perrault, "Port Control Protocol (PCP) Extension and S. Perrault, "Port Control Protocol (PCP) Extension
skipping to change at page 17, line 27 skipping to change at page 16, line 16
Penno, R., Perrault, S., Kamiset, S., Boucadair, M., and Penno, R., Perrault, S., Kamiset, S., Boucadair, M., and
K. Naito, "Network Address Translation (NAT) Behavioral K. Naito, "Network Address Translation (NAT) Behavioral
Requirements Updates (expired Work in Progress)", January Requirements Updates (expired Work in Progress)", January
2013. 2013.
[I_D.ietf-softwire-lw4over6] [I_D.ietf-softwire-lw4over6]
Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the DS-Lite Farrer, "Lightweight 4over6: An Extension to the DS-Lite
Architecture (Work in Progress)", November 2014. Architecture (Work in Progress)", November 2014.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
1992, <http://www.rfc-editor.org/info/rfc1323>.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, Translation (NAT) Behavioral Requirements for Unicast
RFC 4787, January 2007. UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <http://www.rfc-editor.org/info/rfc4787>.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, DOI 10.17487/RFC5382, October 2008,
<http://www.rfc-editor.org/info/rfc5382>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424,
DOI 10.17487/RFC5424, March 2009,
<http://www.rfc-editor.org/info/rfc5424>.
[RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP
Timestamps", BCP 159, RFC 6191, April 2011. Timestamps", BCP 159, RFC 6191, DOI 10.17487/RFC6191,
April 2011, <http://www.rfc-editor.org/info/rfc6191>.
[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, [RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard,
"Logging Recommendations for Internet-Facing Servers", BCP "Logging Recommendations for Internet-Facing Servers",
162, RFC 6302, June 2011. BCP 162, RFC 6302, DOI 10.17487/RFC6302, June 2011,
<http://www.rfc-editor.org/info/rfc6302>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, August 2011. Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the [RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to
IPv4 Address Shortage", RFC 6346, August 2011. the IPv4 Address Shortage", RFC 6346,
DOI 10.17487/RFC6346, August 2011,
<http://www.rfc-editor.org/info/rfc6346>.
[RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and [RFC6431] Boucadair, M., Levis, P., Bajko, G., Savolainen, T., and
T. Tsou, "Huawei Port Range Configuration Options for PPP T. Tsou, "Huawei Port Range Configuration Options for PPP
IP Control Protocol (IPCP)", RFC 6431, November 2011. IP Control Protocol (IPCP)", RFC 6431,
DOI 10.17487/RFC6431, November 2011,
<http://www.rfc-editor.org/info/rfc6431>.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC Combination of Stateful and Stateless Translation",
6877, April 2013. RFC 6877, DOI 10.17487/RFC6877, April 2013,
<http://www.rfc-editor.org/info/rfc6877>.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. [RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
2013. DOI 10.17487/RFC6887, April 2013,
<http://www.rfc-editor.org/info/rfc6887>.
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
and H. Ashida, "Common Requirements for Carrier-Grade NATs A., and H. Ashida, "Common Requirements for Carrier-Grade
(CGNs)", BCP 127, RFC 6888, April 2013. NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC7011] Claise, B., Trammell, B., and P. Aitken, "Specification of [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
the IP Flow Information Export (IPFIX) Protocol for the "Specification of the IP Flow Information Export (IPFIX)
Exchange of Flow Information", STD 77, RFC 7011, September Protocol for the Exchange of Flow Information", STD 77,
2013. RFC 7011, DOI 10.17487/RFC7011, September 2013,
<http://www.rfc-editor.org/info/rfc7011>.
[RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
Deployment Options and Experience", RFC 7269,
DOI 10.17487/RFC7269, June 2014,
<http://www.rfc-editor.org/info/rfc7269>.
[RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., [RFC7422] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
and O. Vautrin, "Deterministic Address Mapping to Reduce and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier-Grade NAT Deployments", RFC 7422, Logging in Carrier-Grade NAT Deployments", RFC 7422,
December 2014. DOI 10.17487/RFC7422, December 2014,
<http://www.rfc-editor.org/info/rfc7422>.
Authors' Addresses Authors' Addresses
Gang Chen Gang Chen
China Mobile China Mobile
53A,Xibianmennei Ave., 53A,Xibianmennei Ave.,
Xuanwu District, Xuanwu District,
Beijing 100053 Beijing 100053
P.R. China P.R. China
skipping to change at line 873 skipping to change at page 18, line 34
P.R. China P.R. China
Email: James.huang@huawei.com Email: James.huang@huawei.com
Tom Taylor Tom Taylor
PT Taylor Consulting PT Taylor Consulting
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: tom.taylor.stds@gmail.com Email: tom.taylor.stds@gmail.com
Jean-Francois Tremblay
Viagenie
246 Aberdeen
Quebec, QC G1R 2E1
Canada
Phone: +1 418 656 9254
Email: jean-francois.tremblay@viagenie.ca
URI: http://viagenie.ca
 End of changes. 53 change blocks. 
206 lines changed or deleted 171 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/