draft-ietf-v6ops-nat64-experience-00.txt   draft-ietf-v6ops-nat64-experience-01.txt 
Internet Engineering Task Force G. Chen v6ops G. Chen
Internet-Draft Z. Cao Internet-Draft Z. Cao
Intended status: Informational China Mobile Intended status: Informational China Mobile
Expires: February 8, 2013 C. Byrne Expires: August 4, 2013 C. Byrne
T-Mobile USA T-Mobile USA
C. Xie C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom France Telecom
August 07, 2012 January 31, 2013
NAT64 Operational Experiences NAT64 Deployment Considerations
draft-ietf-v6ops-nat64-experience-00 draft-ietf-v6ops-nat64-experience-01
Abstract Abstract
This document summarizes stateful NAT64 deployment scenarios and This document summarizes NAT64 deployment scenarios and operational
operational experience with NAT64-CGN(NAT64 Carrier Grade NATs) and experience with stateful NAT64-CGN(NAT64 Carrier Grade NATs) and
NAT64-CE (NAT64 Customer Edges). NAT64-FE (NAT64 server Front End).
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 February 8, 2013. This Internet-Draft will expire on August 4, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. NAT64-CGN Deployment Experiences . . . . . . . . . . . . . . . 6 3. NAT64-CGN Deployment Experiences . . . . . . . . . . . . . . . 5
3.1. NAT64-CGN Networking . . . . . . . . . . . . . . . . . . . 6 3.1. NAT64-CGN Networking . . . . . . . . . . . . . . . . . . . 5
3.2. High Availability Considerations . . . . . . . . . . . . . 7 3.2. High Availability Considerations . . . . . . . . . . . . . 6
3.3. Traceability . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Traceability . . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Quality of Experience . . . . . . . . . . . . . . . . . . 8 3.4. Quality of Experience . . . . . . . . . . . . . . . . . . 7
3.5. Load Balancer . . . . . . . . . . . . . . . . . . . . . . 9 3.5. NAT64-CGN Load Balancer . . . . . . . . . . . . . . . . . 8
3.6. MTU Consideration . . . . . . . . . . . . . . . . . . . . 9 3.6. MTU Consideration . . . . . . . . . . . . . . . . . . . . 8
4. NAT64-CE Deployment Experiences . . . . . . . . . . . . . . . 9 4. NAT64-FE Deployment Experiences . . . . . . . . . . . . . . . 9
4.1. NAT64-CE Networking . . . . . . . . . . . . . . . . . . . 10 4.1. NAT64-FE Networking . . . . . . . . . . . . . . . . . . . 9
4.2. Anti-DDoS/SYN Flood . . . . . . . . . . . . . . . . . . . 11 4.2. Source Address Traceability . . . . . . . . . . . . . . . 10
4.3. User Behavior Analysis . . . . . . . . . . . . . . . . . . 11 4.3. DNS Resolving . . . . . . . . . . . . . . . . . . . . . . 10
4.4. DNS Resolving . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Load Balancer . . . . . . . . . . . . . . . . . . . . . . 11
4.5. Load Balancer . . . . . . . . . . . . . . . . . . . . . . 12 4.5. MTU Consideration . . . . . . . . . . . . . . . . . . . . 11
4.6. MTU Consideration . . . . . . . . . . . . . . . . . . . . 12 4.6. Anti-DDoS/SYN Flood . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. Additional Author List . . . . . . . . . . . . . . . . . . . . 13 8. Additional Author List . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Continued development of global Internet demands IP address With IANA's global IPv4 address pool was exhausted, IPv6 is the only
consumption. The IANA global IPv4 address pool was exhausted on sustainable solution for numbering nodes on the Internet. Network
February 3, 2011. IPv6 is the only sustainable solution for operators have to deploy IPv6-only networks in order to meet the
numbering nodes on the Internet. Network operators have to deploy numbering needs of the expanding internet without available IPv4
IPv6 networks in order to meet the numbering needs of the expanding addresses.
internet without available IPv4 addresses. IPv4 numbering resources
and IPv4-only schemes to reduce the numbering utilization during the
transitional will not be adequate to maintain connectivity and
deliver Internet services.
As IPv6 deployment continues, IPv6 networks and hosts will need to As IPv6 deployment continues, IPv6 networks and hosts will need to
coexist with IPv4 numbered resources. The Internet will include coexist with IPv4 numbered resources. The Internet will include
nodes that are Dual-stack, nodes that remain IPv4-only and IPv6-only nodes that are dual-stack, nodes that remain IPv4-only, and nodes
nodes. It may be desirable in some cases for operators to deploy a that can be deployed as IPv6-only nodes.
single stack network, for reasons of simplicity, cost or performance
relative to a dual stack network. As IPv4 utilization eventually
declines, the appeal of single stack network deployments will likely
increase. In a dual-stack architecture, operators have to maintain
double management interfaces, provide operational support systems for
two networks, track multiple addresses in different families per
host, trouble shoot host behavior related to dual stack operation and
engage in other activities that increase the overhead of operating
the network.
Single stack IPv6 network deployment can simplify the network Single stack IPv6 network deployment can simplify the network
provisioning. Some justification has been described in provisioning. Some justifications have been described in
[I-D.ietf-v6ops-464xlat]. IPv6-only networks confer some benefits to [I-D.ietf-v6ops-464xlat]. IPv6-only networks confer some benefits to
mobile operators employing them. In the mobile context, it enables mobile operators employing them. In the mobile context, it enables
the use of a single IPv6 PDP(Packet Data Protocol), which eliminates the use of a single IPv6 PDP(Packet Data Protocol), which eliminates
significant network cost caused by doubling the PDP count on a mass significant network cost caused by doubling the PDP count on a mass
of legacy mobile terminals. In broadband networks overall, it can of legacy mobile terminals. In broadband networks overall, it can
allow for the scaling of edge-network growth decoupled from IPv4 allow for the scaling of edge-network growth decoupled from IPv4
numbering limitations. numbering limitations.
In a transition scenario, an existing network may rely on the IPv4 In a transition scenario, an existing network may rely on the IPv4
stack for a long time. There is also the troublesome trend of access stack for a long time. There is also the troublesome trend of access
network providers squatting on IPv4 address space that they do not network providers squatting on IPv4 address space that they do not
own. Allowing for interconnection between IPv4-only nodes and IPv6- own. Allowing for interconnection between IPv4-only nodes and IPv6-
only nodes is a critical capability. Widespread dual-stack only nodes is a critical capability. Widespread dual-stack
deployments have not materialized at the anticipated rate over the deployments have not materialized at the anticipated rate over the
last 10 years on possible conclusion being that legacy networks will last 10 years, one possible conclusion being that legacy networks
not make the jump quickly. A translation mechanism based on a will not make the jump quickly. A translation mechanism based on a
NAT64[RFC6146] function might be a key element of the internet NAT64[RFC6146] function will be a key element of the internet
infrastructure supporting such legacy networks. infrastructure supporting such legacy networks.
[RFC6036] reported at least 30% operators plan to run some kind of [RFC6036] reported at least 30% operators plan to run some kind of
translator (presumably NAT64/DNS64). Advice on NAT64 deployment and translator (presumably NAT64/DNS64). Advice on NAT64 deployment and
operation is therefore of some importance. [RFC6586] documented the operation is therefore of some importance. [RFC6586] documented the
implications for ipv6 only networks. This document intends to be implications for ipv6 only networks. This document intends to be
specific to NAT64 network planning. specific to NAT64 network planning.
In regards to IPv4/IPv6 translation, [RFC6144] has described a In regards to IPv4/IPv6 translation, [RFC6144] has described a
framework of enabling networks to make interworking possible between framework of enabling networks to make interworking possible between
IPv4-only and IPv6-only networks. Three scenarios are described, "An IPv4-only and IPv6-only networks. This document has further
IPv6 Network to the IPv4 Internet", "The IPv6 Internet to an IPv4
Network" and "An IPv6 Network to an IPv4 Network" where a NAT64
function is relevant. The scenario of "The IPv6 Internet to the IPv4
Internet" seems to be the ideal case for inter-network translation
technology. This document has focused on the three cases and further
categorized different NAT64 location and use case. The principle categorized different NAT64 location and use case. The principle
distinction of location is if the NAT64 is located in a NAT64-CGN distinction of location is if the NAT64 is located in a NAT64-CGN
(Carrier Grade NATs) or NAT64-CE (Customer Edges). NAT64-CGN (Carrier Grade NATs) or NAT64-FE (server Front End).
corresponds to the scenario "IPv6 Network to IPv4 Internet". The
NAT64-CE location roughly corresponds to the "IPv6 Internet to IPv4
Network" and "IPv6 Network to IPv4 Network" scenarios. Based on
different NAT64 modes, different considerations have been described
for ISPs to facilitate NAT64 deployments.
2. Terminology 2. Terminology
The terms of NAT-CGN/CE are understood to be a topological The terms of NAT-CGN/FE are understood to be a topological
distinction indicating different features employed in a NAT64 distinction indicating different features employed in a NAT64
deployment. deployment.
NAT64-CGN: A NAT64-CGN (Carrier Grade NATs) is placed in an ISP NAT64-CGN: A NAT64-CGN (Carrier Grade NATs) is placed in an ISP
network and managed by an administrative entity, e.g. operator. network. IPv6 only subscribers leverage the NAT64-CGN to access
From an administrator view, a NAT64-CGN usually forwards outbound existing IPv4 internet services. The ISP as an administrative
traffic into an IPv4 network. IPv6 only subscribers leverage the entity takes full control on the IPv6 side, but has limited or no
NAT64-CGN to be served by existing IPv4 internet services. The control on the IPv4 side. ISP's should attempt to accommodate the
ISP as an administrative entity takes full control on the IPv6 behavior of IPv4 networks and services.
side, but has limited or no control on the IPv4 side. ISP's
should attempt to accommodate the behavior of IPv4 networks and
services.
NAT64-CE: A NAT64-CE (Customer Edges) is placed at the edge of NAT64-FE: A NAT64-FE (server Front End) is generally a traffic load
customer network, e.g. a network operated by an Enterprise or balancer with NAT64 functionalities in a ICP network.
Consumer. A NAT64-CE makes IPv4 services accessible for the IPv6
only users. An upstream entity and ISP usually operates an IPv4
and potentially IPv6 network respectively. IPv6 access is the
common infrastructure behind the NAT64-CE.
3. NAT64-CGN Deployment Experiences 3. NAT64-CGN Deployment Experiences
A NAT64-CGN deployment scenario is depicted in Figure 1 A NAT64-CGN deployment scenario is depicted in Figure 1
----------- -----------
---------- // \\ ---------- // \\
// \\ / \ // \\ / \
/ +----+ \ / +----+ \
| |XLAT| | | |XLAT| |
skipping to change at page 6, line 30 skipping to change at page 5, line 46
----------- -----------
====> ====>
Figure 1: NAT64-CGN Scenario: IPv6 Network to IPv4 Internet Figure 1: NAT64-CGN Scenario: IPv6 Network to IPv4 Internet
3.1. NAT64-CGN Networking 3.1. NAT64-CGN Networking
The NAT64-CGN use case is employed to connect IPv6-only users to the The NAT64-CGN use case is employed to connect IPv6-only users to the
IPv4 Internet. The NAT64 gateway performs protocol translation from IPv4 Internet. The NAT64 gateway performs protocol translation from
an IPv6 packet header to an IPv4 packet header and vice versa an IPv6 packet header to an IPv4 packet header and vice versa
according to the Stateful NAT64 [RFC6146]. Address translation maps according to the stateful NAT64 [RFC6146]. Address translation maps
IPv6 addresses to IPv4 addresses and vice versa for return traffic. IPv6 addresses to IPv4 addresses and vice versa for return traffic.
All connections to the IPv4 Internet from IPv6-only clients must All connections to the IPv4 Internet from IPv6-only clients must
traverse the NAT64-CGN. It is advantageous from the vantage-point of traverse the NAT64-CGN. It is advantageous from the vantage-point of
troubleshooting and traffic engineering to carry the IPv6 traffic troubleshooting and traffic engineering to carry the IPv6 traffic
natively for as long as possible within an access network and natively for as long as possible within an access network and
translates only at or near the network egress. translates only at or near the network egress. In many service
provider networks, NAT64 is considered feature of the AS boarder.
This allows consistent attribution and traceability within the
service provider network. Meaning, within one network, the packet
only has one source. As the packet leaves the network destine for
another network, the packet source may be translated as needed.
In mobile networks, various possibilities can be envisaged in which In mobile networks, various possibilities can be envisaged to deploy
to deploy the NAT64 function. Whichever option is selected, the the NAT64 function. Whichever option is selected, the NAT64 function
NAT64 function will be deployed beyond the GGSN (Gateway GPRS Support will be deployed beyond the GGSN (Gateway GPRS Support Node) or
Node) or PDN-GW (Public Data Network-Gateway), i.e. first IP node in PDN-GW (Public Data Network-Gateway), i.e. first IP node in currently
currently deployed mobile architectures. deployed mobile architectures.
In a given implementation, NAT64 functionality can be provided by In a given implementation, NAT64 functionality can be provided by
either a dedicated GW device or an multifunction gateway with either a dedicated device or an multifunction gateway with integrated
integrated NAT64 functionality. In standalone NAT64, NAT64-CGN is NAT64 functionality. If NAT64 is integrated into an existing node,
placed to the side of a BNG or CR. An embedded NAT64 deployment capacities of existing nods can be potentially limited by the new
would be integrated with an existing GW. Capacities of an existing functionality, e.g. maximum concurrent connections. In a mobile
GW can be potentially limited by the inserted functionality. In a context, the NAT64 function likely be implemented in a firewall,
mobile context, the NAT64 function can be co-located with GGSN/PDN-GW which is the first hop routed from GGSN/PGW.
or it can be embedded in an existing FW/NAT44 already deployed in
support of IPv4 NAT or, the function can be collocated on a router.
Whatever the solution retained for the co-location option, impact on
existing services and legal obligations have to be assessed.
3.2. High Availability Considerations 3.2. High Availability Considerations
High Availability (HA) is a major requirement for every service and High Availability (HA) is a major requirement for every service.
network service.
Two mechanisms are typically used to achieve high availability, i.e. Two mechanisms are typically used to achieve high availability, i.e.
cold-standby and hot-standby. Cold-standby systems have synchronized cold-standby and hot-standby. Cold-standby systems have synchronized
configuration and mechanism to failover traffic between the hot and configuration and mechanism to failover traffic between the hot and
cold systems such as VRRP [RFC5798] . Unlike hot-standby, cold- cold systems such as VRRP [RFC5798] . Unlike hot-standby, cold-
standby does not synchronize NAT64 session state. This makes cold- standby does not synchronize NAT64 session state. This makes cold-
standby less resource intensive and generally simpler, but it standby less resource intensive and generally simpler, but it
requires clients to re-establish sessions when a fail-over occurs. requires clients to re-establish sessions when a fail-over occurs.
Hot-standby has all the features of cold-standby but must also Hot-standby has all the features of cold-standby but must also
synchronize the binding information base (BIB). Given that short synchronize the binding information base (BIB). Given that short
lived sessions account for most of the bindings, hot-standby does not lived sessions account for most of the bindings, hot-standby does not
offer much benefit for those sessions. Consideration should be given offer much benefit for those sessions. Consideration should be given
to the importance (or lack thereof) of maintaining bindings for long to the importance (or lack thereof) of maintaining bindings for long
lived sessions across failovers. lived sessions across failovers.
3.3. Traceability 3.3. Traceability
Traceablility is required in many cases to identify an attacker or a Traceablility is required in many cases such as identifying malicious
host that launches malicious attacks and/or for various other attacks sources and accounting requirements. NAT64 devices are
purposes, such as accounting requirements. NAT64 devices are
required to log events like creation and deletion of translations and required to log events like creation and deletion of translations and
information about the occupied resources. There are two different information about the occupied resources. There are two different
demands for traceability,i.e. online or offline. demands for traceability,i.e. online or offline.
o Regarding the Online requirements, XFF (X-Forwarded-For) o Regarding the Online requirements, XFF (X-Forwarded-For)
[I-D.ietf-appsawg-http-forwarded]would be a candidate, it appends [I-D.ietf-appsawg-http-forwarded]would be a candidate, it appends
IPv6 address of subscribers to HTTP headers which is passed on to IPv6 address of subscribers to HTTP headers which is passed on to
WEB servers, and the querier server can lookup radius servers for WEB servers, and the querier server can lookup radius servers for
the target subscribers based on IPv6 addresses included in XFF the target subscribers based on IPv6 addresses included in XFF
HTTP headers. X-Forwarded-For is specific to HTTP, requires the HTTP headers. X-Forwarded-For is specific to HTTP, requires the
skipping to change at page 8, line 9 skipping to change at page 7, line 23
end-to-end as it may be overwritten by other application-aware end-to-end as it may be overwritten by other application-aware
proxies such as load balancers. proxies such as load balancers.
o Some potential solutions to online traceability are explore in o Some potential solutions to online traceability are explore in
[I-D.ietf-intarea-nat-reveal-analysis]. [I-D.ietf-intarea-nat-reveal-analysis].
o A NAT64-CGN could also deliver NAT64 sessions (BIB and STE) to a o A NAT64-CGN could also deliver NAT64 sessions (BIB and STE) to a
Radius server by extension of the radius protocol. Such an Radius server by extension of the radius protocol. Such an
extension is an alternative solution for online traceability, extension is an alternative solution for online traceability,
particularly high performance would be required on Radius servers particularly high performance would be required on Radius servers
on order to achieve this. in order to achieve this.
o For off-line traceability, syslog might be a good choice. o For off-line traceability, syslog might be a good choice.
[RFC6269] indicates address sharing solutions generally need to [RFC6269] indicates address sharing solutions generally need to
record and store information for specific periods of time. A record and store information for specific periods of time. A
stateful NAT64 is supposed to manage one mapping per session. A stateful NAT64 is supposed to manage one mapping per session. A
large volume of logs poses a challenge for storage and processing. large volume of logs poses a challenge for storage and processing.
In order to mitigate the issue, In order to mitigate the issue,
[I-D.donley-behave-deterministic-cgn]proposed to pre-allocated a [I-D.donley-behave-deterministic-cgn]is proposed to pre-allocated
group of ports for each specific IPv6 host. A trade-off among a group of ports for each specific IPv6 host. A trade-off among
address multiplexing efficiency, port randomization address multiplexing efficiency, port randomization
security[RFC6056] and logging storage compression should be security[RFC6056] and logging storage compression should be
considered during the planning. A hybrid mode combining considered during the planning. A hybrid mode combining
deterministic and dynamic port assignment was recommended deterministic and dynamic port assignment was recommended
regarding the uncertainty of user traffic. regarding the uncertainty of user traffic.
3.4. Quality of Experience 3.4. Quality of Experience
NAT64 is providing a translation capability between IPv6 and IPv4 NAT64 is providing a translation capability between IPv6 and IPv4
end-nodes. In order to provide the reachability between two IP end-nodes. In order to provide the reachability between two IP
address families, NAT64-CGN has to implement appropriate ALGs where address families, NAT64-CGN has to implement appropriate ALGs where
address translation is not itself sufficient and security mechanisms address translation is not itself sufficient and security mechanisms
do not render it infeasible. e.g. FTP-ALG[RFC6384], RSTP-ALG, H.323- do not render it infeasible. e.g. FTP-ALG[RFC6384], RSTP-ALG, H.323-
ALG,etc. It should be noted that ALGs may impact the performance on ALG,etc. It should be noted that ALGs may impact the performance on
a NAT64 box to some extent. ISPs as well as content providers might a NAT64 box to some extent. ISPs as well as content providers might
choose to avoid situations where the imposition of an ALG might be choose to avoid situations where the imposition of an ALG might be
required. At the same time, it is also important to remind customers required. At the same time, it is also important to remind customers
that IPv6 end-to-end usage does not require ALG imposition and and application developers that IPv6 end-to-end usage does not
therefore results in a better overall user experience. require ALG imposition and therefore results in a better overall user
experience.
The service experience should be optimized around stateful NAT Session status normally is managed by a static life-cycle. In some
processing. Session status normally is managed by a static life- cases, NAT resource maybe significantly consumed by largely inactive
cycle. In some cases, NAT resource maybe significantly consumed by users. The NAT translator and other customers would suffer from
largely inactive users. The NAT translator and other customers would service degradation due to port consummation by other subscribers
suffer from service degradation due to port consummation by other using the same NAT64 device. A flexible NAT session control is
subscribers using the same NAT64 device. A flexible NAT session desirable to resolve the issues. PCP[I-D.ietf-pcp-base] could be a
control is desirable to resolve the issues. PCP[I-D.ietf-pcp-base] candidate to provide such capability. A NAT64-CGN should integrate
could be a candidate to provide such capability. A NAT64-CGN should with a PCP server, to allocate available IPv4 address/Port resources.
integrate with a PCP server, to allocate available IPv4 address/Port Resources could be assigned to PCP clients through PCP MAP/PEER mode.
resources. Resources could be assigned to PCP clients through PCP Such an ability should also be considered to upgrade user
MAP/PEER mode. Such an ability should also be considered to upgrade experiences, e.g. assigning different sizes of port ranges for
user experiences, e.g. assigning different sizes of port ranges for
different subscribers. Such a mechanism is also helpful to minimize different subscribers. Such a mechanism is also helpful to minimize
terminal battery consumption reducing the number of keepalive terminal battery consumption and reduce the number of keepalive
messages to be sent by terminal devices. messages to be sent by terminal devices.
3.5. Load Balancer 3.5. NAT64-CGN Load Balancer
Load balancers are an essential tool to avoid the issue of single Load balancers are an essential tool to avoid the issue of single
points of failure and add additional scale. It is potentially points of failure and add additional scale. It is potentially
important to employ load-balancing considering that deployment of important to employ load-balancing considering that deployment of
multiple NAT64 devices. Load balancers are required to achieve some multiple NAT64 devices. Load balancers are required to achieve some
service continuity and scale for customers. service continuity and scale for customers.
[I-D.zhang-behave-nat64-load-balancing] discusses several ways of [I-D.zhang-behave-nat64-load-balancing] discusses several ways of
achieving NAT64 load balancing, including anycast based policy and achieving NAT64 load balancing, including anycast based policy and
prefix64 selection based policy, either implemented via prefix64 selection based policy, either implemented via
DNS64[RFC6147] or Prefix64 assignments. Since DNS64 is normally co- DNS64[RFC6147] or Prefix64 assignments. Since DNS64 is normally co-
located with NAT64 in some scenarios, it could be leveraged to located with NAT64 in some scenarios, it could be leveraged to
perform the load balance. For traffic which does not require a DNS perform the load balance. For traffic which does not require a DNS
resolution, prefix64 assignment based resolution, prefix64 assignment based
on[I-D.ietf-behave-nat64-learn-analysis] could be adopted. on[I-D.ietf-behave-nat64-learn-analysis] could be adopted.
3.6. MTU Consideration 3.6. MTU Consideration
IPv6 requires that every link in the internet have an MTU of 1280 IPv6 requires that every link in the internet have an MTU of 1280
octets or greater[RFC2460]. However, in case of NAT64 translation octets or greater[RFC2460]. However, in case of NAT64 translation
deployments, some IPv4 MTU constrained link will be used in some deployment, some IPv4 MTU constrained link will be used in some
communication path and originating IPv6 nodes may therefore receive communication path and originating IPv6 nodes may therefore receive
an ICMP Packet Too Big message, reporting a Next-Hop MTU less than an ICMP Packet Too Big message, reporting a Next-Hop MTU less than
1280. The result would be that IPv6 allows packets to contain a 1280. The result would be that IPv6 allows packets to contain a
fragmentation header, without the packet being fragmented into fragmentation header, without the packet being fragmented into
multiple pieces. [I-D.ietf-6man-ipv6-atomic-fragments] discusses how multiple pieces. [I-D.ietf-6man-ipv6-atomic-fragments] discusses how
this situation could be exploited by an attacker to perform this situation could be exploited by an attacker to perform
fragmentation-based attacks, and also proposes an improved handling fragmentation-based attacks, and also proposes an improved handling
of such packets. It required enhancements on protocol level, which of such packets. It required enhancements on protocol level, which
might imply potential upgrade/modifications on behaviors to deployed might imply potential upgrade/modifications on behaviors to deployed
nodes. Another approach that potentially avoids this issue is to nodes. Another approach that potentially avoids this issue is to
configure IPv4 MTU>=1260. It would forbid the occurrence of configure IPv4 MTU>=1260. It would forbid the occurrence of
PTB<1280. However, such an operational consideration is hard to PTB<1280. However, such an operational consideration is hard to
universally apply to the legacy "IPv4 Internet". universally apply to the legacy "IPv4 Internet".
4. NAT64-CE Deployment Experiences 4. NAT64-FE Deployment Experiences
The NAT64-CE Scenario is depicted in Figure 2 The NAT64-FE Scenario is depicted in Figure 2
-------- --------
// \\ ---------- // \\ ----------
/ \ // \\ / \ // \\
/ +----+ \ / +----+ \
| |XLAT| | | |XLAT| |
| The IPv6 +----+ An IPv4 | | The IPv6 +----+ An IPv4 |
| Internet +----+ Network | XLAT: IPv4/IPv6 | Internet +----+ Network | XLAT: IPv4/IPv6
| /Network |DNS | | Translator | /Network |DNS | | Translator
\ +----+ / DNS: DNS64 \ +----+ / DNS: DNS64
\ / \\ // \ / \\ //
\\ // ---------- \\ // ----------
-------- --------
====> ====>
Figure 2: NAT64-CE Scenario: IPv6 Internet/Network to IPv4 Network Figure 2: NAT64-FE Scenario: IPv6 Internet/Network to IPv4 Network
4.1. NAT64-CE Networking 4.1. NAT64-FE Networking
Content providers would like to use IPv6 to serve customers since it There are plenty of practices to equip load balancer with NAT64 at
allows for the definition of new services without having to integrate front of servers. Two different cases appeared in the NAT64-FE
consideration of IPv4 NAT and address limitations of IPv4 networks, networking.
but they have to provide some IPv4 service continuity to their
customers. In some cases, customers outside the network will have
IPv6-only access provided by early adopters before the internal
network. The deployment requirements could be resolved by subsiding
NAT64 to a customer edge. [I-D.ietf-v6ops-icp-guidance] has
described the cases, in which an HTTP proxy can readily be configured
to handle incoming connections over IPv6 and to proxy them to a
server over IPv4. Those cases are sure to exist for the time being.
An administrator of the IPv4 network needs to be cautious and aware
of the operational issues this may cause, since the native IPv6 is
always more desirable than transition solution.
One potential challenge in the scenario is NAT64-CE facing IPv6 o Some content providers who has a wealth of IPv6 experiences
Internet, in which a significant number of IPv6 users may initiate consider IPv6-only strategy to serve customers since it allows new
connections. When increasingly numerous users in IPv6 Internet services delivery without having to integrate consideration of
access an IPv4 network, scalability concerns(e.g. additional latency, IPv4 NAT and address limitations of IPv4 networks. Whereas they
a single point of failure, IPv4 pool exhaustion, etc) are apt to be have to provide some IPv4 service continuity to their customers,
applied. For a given off-the-shelf NAT64-CE, those challenges should stateless IP/ICMP Translation (SIIT) [RFC6145]has been used to
be seriously assessed. Potential issues should be properly continue provide services for IPv4 subscribers.
identified.
For operators who seek a clear precedent for operating reliable IPv6- o ICPs who have insufficient IPv6 incentive likely prefer short-term
only services, it should be well noted that the usage is problematic alternatives to provide IPv6 connectivity due to the widespread
at several aspects. In some sense, it's not recommended. impact of supporting IPv6 within a ICP environment. A stateful
NAT64 has been located at front of servers. It could
simultaneously facilitate the IPv6 accessibility and conservation
of IPv4 servers. [I-D.ietf-v6ops-icp-guidance]has described the
cases, in which an HTTP proxy can readily be configured to handle
incoming connections over IPv6 and to proxy them to a server over
IPv4.
4.2. Anti-DDoS/SYN Flood For first case, [I-D.anderson-siit-dc]has provided further
descriptions and guidelines. This document is addressed to second
case. An administrator of the IPv4 network needs to be cautious and
aware of the operational issues in the case since the native IPv6 is
always more desirable than transition solutions.
For every incoming new connection from the IPv6 Internet, the One potential challenge is stateful NAT64-FE facing IPv6 Internet, in
NAT64-CE creates state and maps that connection to an internally- which a significant number of IPv6 users may initiate connections.
facing IPv4 address and port. An attacker can consume the resources When increasingly numerous users in IPv6 Internet access an IPv4
of the NAT64-CE device by sending an excessive number of connection network, scalability concerns(e.g. additional latency, a single point
attempts. Without a DDOS limitation mechanism, the NAT64 is exposed of failure, IPv4 pool exhaustion, etc) are apt to be applied. For a
to attacks from the IPv6 Internet. With service provisioning, given off-the-shelf NAT64-FE, those challenges should be seriously
attacks have the potential could also deteriorate service quality. assessed. Potential issues should be properly identified.
One consideration in internet content providers is place a L3 load
balancer with capable of line rate DDOS defense, such as the
employment of SYN PROXY-COOKIE. Security domain division is
necessary in this case. Load Balancers could not only serve for
optimization of traffic distribution, but also serve as a DOS
mitigation device
4.3. User Behavior Analysis Following subsections described several considerations to stateful
NAT64-FE case. For operators who seek a clear precedent for
operating reliable IPv6-only services, it should be well noted that
the usage is problematic.
4.2. Source Address Traceability
IP addresses are usually used as input to geo-location services. The IP addresses are usually used as input to geo-location services. The
use of address sharing will prevent these systems from resolving the use of address sharing will prevent these systems from resolving the
location of a host based on IP address alone. Applications that location of a host based on IP address alone. Applications that
assume such geographic information may not work as intended. The assume such geographic information may not work as intended. The
possible solutions listed at section 3.3 intended to bridge the gap. possible solutions listed at section 3.3 intended to bridge the gap.
However, the analysis reveals those solutions can't be a optimal However, the analysis reveals those solutions can't be a optimal
substitution to solve the problem of host identification, in substitution to solve the problem of host identification, in
particular it does not today mitigate problems with source particular it does not today mitigate problems with source
identification through translation. That makes NAT64-CE usage identification through translation. That makes NAT64-FE usage
becoming a unappealing approach, if customers require source address becoming a unappealing approach, if customers require source address
tracking. tracking.
For the operators, who already deployed NAT64-CE approach, the source For the operators, who already deployed NAT64-FE approach, the source
address of the request is obscured without the source address mapping address of the request is obscured without the source address mapping
information previously obtained. It's superior to present mapping information previously obtained. It's superior to present mapping
information directly to applications. Some application layer proxies information directly to applications. Some application layer proxies
e.g. XFF (X-Forwarded-For) , can convey this information in-band. e.g. XFF (X-Forwarded-For) , can convey this information in-band.
Another approach is to ask application coordinating the information Another approach is to ask application coordinating the information
with NAT logging. But that is not sufficient, since the applications with NAT logging. But that is not sufficient, since the applications
itself wants to know the original source address from an application itself wants to know the original source address from an application
message bus. The logging information may be used by administrators message bus. The logging information may be used by administrators
offline to inspect use behavior and preference analysis, and accurate offline to inspect use behavior and preference analysis, and accurate
advertisement delivery. advertisement delivery.
4.4. DNS Resolving 4.3. DNS Resolving
In the case of NAT64-CE, it is recommended to follow the In the case of NAT64-FE, it is recommended to follow the
recommendations in [RFC6144]. There is no need for the DNS to recommendations in [RFC6144]. There is no need for the DNS to
synthesize AAAA from A records, since static AAAA records can be synthesize AAAA from A records, since static AAAA records can be
registered in the authoritative DNS for a given domain to represent registered in the authoritative DNS for a given domain to represent
these IPv4-only hosts. How to design the FQDN for the IPv6 service these IPv4-only hosts. How to design the FQDN for the IPv6 service
is out-of-scope of this document. is out-of-scope of this document.
4.5. Load Balancer 4.4. Load Balancer
Load balancing on NAT64-CE has a couple of considerations. If Load balancing on NAT64-FE has a couple of considerations. If
dictated by scale or availability requirements traffic should be dictated by scale or availability requirements traffic should be
balanced among multiple NAT64-CE devices. One point to be noted is balanced among multiple NAT64-CE devices. One point to be noted is
that synthetic AAAA records may be added directly in authoritative that synthetic AAAA records may be added directly in authoritative
DNS. load balancing based on DNS64 synthetic resource records may not DNS. load balancing based on DNS64 synthetic resource records may not
work in those cases. Secondly, NAT64-CE could also serve as the load work in those cases. Secondly, NAT64-FE could also serve as the load
balancer for IPv4 backend servers. There are also some ways of load balancer for IPv4 backend servers. There are also some ways of load
balance for the cases, where load balancer is placed in front of balance for the cases, where load balancer is placed in front of
NAT64(s). NAT64-FE.
4.6. MTU Consideration 4.5. MTU Consideration
As compared to the MTU consideration in NAT64-CGN, the MTU of IPv4 As compared to the MTU consideration in NAT64-CGN, the MTU of IPv4
network are strongly recommended to set to more than 1260. Since a network are strongly recommended to set to more than 1260. Since a
CE IPv4 network is normally operated by a particular administrative IPv4 network is normally operated by a particular administrative
entity, it should take steps to prevent the risk of fragmentation entity, it should take steps to prevent the risk of fragmentation
discussed in [I-D.ietf-6man-ipv6-atomic-fragments]. discussed in [I-D.ietf-6man-ipv6-atomic-fragments].
4.6. Anti-DDoS/SYN Flood
For every incoming new connection from the IPv6 Internet, the
stateful NAT64-FE creates state and maps that connection to an
internally-facing IPv4 address and port. An attacker can consume the
resources of the NAT64-FE device by sending an excessive number of
connection attempts. Without a DDOS limitation mechanism, the
NAT64-FE is exposed to attacks. With service provisioning, attacks
have the potential could also deteriorate service quality. One
consideration in internet content providers is place a L3 load
balancer with capable of line rate DDOS defense, such as the
employment of SYN PROXY-COOKIE. Security domain division is
necessary in this case. Load Balancers could not only serve for
optimization of traffic distribution, but also serve as a DOS
mitigation device.
5. Security Considerations 5. Security Considerations
This document presents the deployment experiences of NAT64 in CGN and This document presents the deployment experiences of NAT64 in CGN and
CE scenario, some security considerations are described ib detail FE scenario, some security considerations are described in detail
regarding to specific NAT64 mode in section 2 and 3. In general, RFC regarding to specific NAT64 mode in section 3 and 4. In general, RFC
6146[RFC6146] provides TCP-tracking, address-dependent filtering 6146[RFC6146] provides TCP-tracking, address-dependent filtering
mechanisms to protect NAT64 from DDOS. In NAT64-CGN cases, ISP also mechanisms to protect NAT64 from DDOS. In NAT64-CGN cases, ISP also
could adopt uRPF and black/white-list to enhance the security by could adopt uRPF and black/white-list to enhance the security by
specifying access policies. for example, NAT64-CGN should forbid specifying access policies. For example, NAT64-CGN should forbid
establish NAT64 BIB for incoming IPv6 packets if URPF (Strict or establish NAT64 BIB for incoming IPv6 packets if URPF (Strict or
Loose mode) check does not pass or whose source IPv6 address is Loose mode) check does not pass or whose source IPv6 address is
associated to black-lists. associated to black-lists.
6. IANA Considerations 6. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, The authors would like to thank Jari Arkko, Dan Wing, Remi Despres,
Fred Baker, Hui Deng, Lee Howard and Iljitsch van Beijnum for their Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum and Philip
helpful comments. Many thanks to Wesley George and Satoru Matsushima Matthews for their helpful comments. Many thanks to Wesley George
for their reviews. and Satoru Matsushima for their reviews.
The authors especially thank Joel Jaeggli for his efforts and The authors especially thank Joel Jaeggli for his efforts and
contributions on editing which substantially improves the legibility contributions on editing which substantially improves the legibility
of the document. of the document.
8. Additional Author List 8. Additional Author List
The following are extended authors who contributed to the effort: The following are extended authors who contributed to the effort:
Qiong Sun Qiong Sun
skipping to change at page 13, line 31 skipping to change at page 13, line 4
QiBo Niu QiBo Niu
ZTE ZTE
50,RuanJian Road. 50,RuanJian Road.
YuHua District, YuHua District,
Nan Jing 210012 Nan Jing 210012
P.R.China P.R.China
Email: niu.qibo@zte.com.cn Email: niu.qibo@zte.com.cn
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-pcp-base] [I-D.ietf-pcp-base]
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", Selkirk, "Port Control Protocol (PCP)",
draft-ietf-pcp-base-26 (work in progress), June 2012. draft-ietf-pcp-base-29 (work in progress), November 2012.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP)
Version 3 for IPv4 and IPv6", RFC 5798, March 2010. Version 3 for IPv4 and IPv6", RFC 5798, March 2010.
[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 [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, April 2011.
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van
Beijnum, "DNS64: DNS Extensions for Network Address Beijnum, "DNS64: DNS Extensions for Network Address
Translation from IPv6 Clients to IPv4 Servers", RFC 6147, Translation from IPv6 Clients to IPv4 Servers", RFC 6147,
April 2011. April 2011.
[RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG)
for IPv6-to-IPv4 Translation", RFC 6384, October 2011. for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
9.2. Informative References 9.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] [I-D.donley-behave-deterministic-cgn]
Donley, C., Grundemann, C., Sarawat, V., and K. Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K.,
Sundaresan, "Deterministic Address Mapping to Reduce and O. Vautrin, "Deterministic Address Mapping to Reduce
Logging in Carrier Grade NAT Deployments", Logging in Carrier Grade NAT Deployments",
draft-donley-behave-deterministic-cgn-04 (work in draft-donley-behave-deterministic-cgn-05 (work in
progress), July 2012. progress), January 2013.
[I-D.ietf-6man-ipv6-atomic-fragments] [I-D.ietf-6man-ipv6-atomic-fragments]
Gont, F., "Processing of IPv6 "atomic" fragments", Gont, F., "Processing of IPv6 "atomic" fragments",
draft-ietf-6man-ipv6-atomic-fragments-00 (work in draft-ietf-6man-ipv6-atomic-fragments-03 (work in
progress), February 2012. progress), December 2012.
[I-D.ietf-appsawg-http-forwarded] [I-D.ietf-appsawg-http-forwarded]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-06 (work in progress), draft-ietf-appsawg-http-forwarded-10 (work in progress),
July 2012. October 2012.
[I-D.ietf-behave-nat64-learn-analysis] [I-D.ietf-behave-nat64-learn-analysis]
Korhonen, J. and T. Savolainen, "Analysis of solution Korhonen, J. and T. Savolainen, "Analysis of solution
proposals for hosts to learn NAT64 prefix", proposals for hosts to learn NAT64 prefix",
draft-ietf-behave-nat64-learn-analysis-03 (work in draft-ietf-behave-nat64-learn-analysis-03 (work in
progress), March 2012. progress), March 2012.
[I-D.ietf-intarea-nat-reveal-analysis] [I-D.ietf-intarea-nat-reveal-analysis]
Boucadair, M., Touch, J., Levis, P., and R. Penno, Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Solution Candidates to Reveal a Host "Analysis of Solution Candidates to Reveal a Host
Identifier (HOST_ID) in Shared Address Deployments", Identifier (HOST_ID) in Shared Address Deployments",
draft-ietf-intarea-nat-reveal-analysis-02 (work in draft-ietf-intarea-nat-reveal-analysis-04 (work in
progress), April 2012. progress), August 2012.
[I-D.ietf-v6ops-464xlat] [I-D.ietf-v6ops-464xlat]
Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", Combination of Stateful and Stateless Translation",
draft-ietf-v6ops-464xlat-06 (work in progress), draft-ietf-v6ops-464xlat-09 (work in progress),
August 2012. January 2013.
[I-D.ietf-v6ops-icp-guidance] [I-D.ietf-v6ops-icp-guidance]
Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content and Application Service Providers", Content and Application Service Providers",
draft-ietf-v6ops-icp-guidance-02 (work in progress), draft-ietf-v6ops-icp-guidance-05 (work in progress),
July 2012. January 2013.
[I-D.zhang-behave-nat64-load-balancing] [I-D.zhang-behave-nat64-load-balancing]
Zhang, D., Xu, X., and M. Boucadair, "Considerations on Zhang, D., Xu, X., and M. Boucadair, "Considerations on
NAT64 Load-Balancing", NAT64 Load-Balancing",
draft-zhang-behave-nat64-load-balancing-03 (work in draft-zhang-behave-nat64-load-balancing-03 (work in
progress), July 2011. progress), July 2011.
[RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider
Scenarios for IPv6 Deployment", RFC 6036, October 2010. Scenarios for IPv6 Deployment", RFC 6036, October 2010.
 End of changes. 67 change blocks. 
196 lines changed or deleted 185 lines changed or added

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