draft-ietf-v6ops-nat64-experience-01.txt   draft-ietf-v6ops-nat64-experience-02.txt 
v6ops G. Chen Internet Engineering Task Force G. Chen
Internet-Draft Z. Cao Internet-Draft Z. Cao
Intended status: Informational China Mobile Intended status: Informational China Mobile
Expires: August 4, 2013 C. Byrne Expires: January 10, 2014 C. Xie
T-Mobile USA
C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom France Telecom-Orange
January 31, 2013 July 09, 2013
NAT64 Deployment Considerations NAT64 Operational Experiences
draft-ietf-v6ops-nat64-experience-01 draft-ietf-v6ops-nat64-experience-02
Abstract Abstract
This document summarizes NAT64 deployment scenarios and operational This document summarizes NAT64 function deployment scenarios and
experience with stateful NAT64-CGN(NAT64 Carrier Grade NATs) and operational experience. Both NAT64-CGN (NAT64 Carrier Grade NATs)
NAT64-FE (NAT64 server Front End). and NAT64-FE (NAT64 server Front End) are considered in this
document.
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 August 4, 2013. This Internet-Draft will expire on January 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NAT64-CGN Deployment Experiences . . . . . . . . . . . . . . . 5 3. NAT64 Networking Experiences . . . . . . . . . . . . . . . . 4
3.1. NAT64-CGN Networking . . . . . . . . . . . . . . . . . . . 5 3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4
3.2. High Availability Considerations . . . . . . . . . . . . . 6 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 5
3.3. Traceability . . . . . . . . . . . . . . . . . . . . . . . 6 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Quality of Experience . . . . . . . . . . . . . . . . . . 7 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 6
3.5. NAT64-CGN Load Balancer . . . . . . . . . . . . . . . . . 8 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 8
3.6. MTU Consideration . . . . . . . . . . . . . . . . . . . . 8 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9
4. NAT64-FE Deployment Experiences . . . . . . . . . . . . . . . 9 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
4.1. NAT64-FE Networking . . . . . . . . . . . . . . . . . . . 9 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Source Address Traceability . . . . . . . . . . . . . . . 10 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
4.3. DNS Resolving . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
4.4. Load Balancer . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11
4.5. MTU Consideration . . . . . . . . . . . . . . . . . . . . 11 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12
4.6. Anti-DDoS/SYN Flood . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 11. Additional Author List . . . . . . . . . . . . . . . . . . . 14
8. Additional Author List . . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
With IANA's global IPv4 address pool was exhausted, IPv6 is the only Now that IANA's global IPv4 address pool has been exhausted, IPv6 is
sustainable solution for numbering nodes on the Internet. Network the only sustainable solution for numbering nodes on Internet.
operators have to deploy IPv6-only networks in order to meet the Network operators have to deploy IPv6-only networks in order to meet
numbering needs of the expanding internet without available IPv4 the needs of the expanding internet without available IPv4 addresses.
addresses.
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 nodes nodes that are dual-stack, nodes that remain IPv4-only, and nodes
that can be deployed as IPv6-only nodes. that can be deployed as IPv6-only nodes.
Single stack IPv6 network deployment can simplify the network Single stack IPv6 network deployment can simplify the network
provisioning. Some justifications have been described in provisioning. Some justifications have been described in 464xlat
[I-D.ietf-v6ops-464xlat]. IPv6-only networks confer some benefits to [RFC6877]. As an example, IPv6-only connectivity confers some
mobile operators employing them. In the mobile context, it enables benefits to mobile operators. In such mobile context, it enables the
the use of a single IPv6 PDP(Packet Data Protocol), which eliminates use of a single IPv6 PDP(Packet Data Protocol) context or EPS
significant network cost caused by doubling the PDP count on a mass (Evolved Packet System) bearer if Long Term Evolution (LTE) network
of legacy mobile terminals. In broadband networks overall, it can is considered, which eliminates significant network costs caused by
allow for the scaling of edge-network growth decoupled from IPv4 doubling the number of PDP contexts in some cases and the need of
numbering limitations. IPv4 addresses to be assigned to customers. In broadband networks
overall, it can allow for the scaling of edge-network growth
decoupled from IPv4 numbering limitations.
In a transition scenario, an existing network may rely on the IPv4 In a transition scenario, some existing networks are likely to be
stack for a long time. There is also the troublesome trend of access IPv4-only configured for quite a long time. Allowing for
network providers squatting on IPv4 address space that they do not interconnection between IPv4-only nodes and IPv6-only nodes is a
own. Allowing for interconnection between IPv4-only nodes and IPv6- critical capability for service continuity. 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, one possible conclusion being that legacy networks last 10 years, one possible conclusion being that legacy networks
will 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 will be a key element of the internet NAT64[RFC6146] [RFC6145]function is likely to be a key element of the
infrastructure supporting such legacy networks. Internet for IPv6-IPv4 interoperability.
[RFC6036] reported at least 30% operators plan to run some kind of [RFC6036] reported at least 30% of 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.
2. Terminology
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. This document has further IPv4 and IPv6 networks. This document has further categorized
categorized different NAT64 location and use case. The principle different NAT64 function locations and use cases. 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-FE (server Front End). (Carrier Grade NATs) or NAT64-FE (server Front End). The terms of
NAT-CGN/FE are understood to be a topological distinction indicating
2. Terminology different features employed in a NAT64 deployment.
The terms of NAT-CGN/FE are understood to be a topological
distinction indicating different features employed in a NAT64
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. IPv6 only subscribers leverage the NAT64-CGN to access network. IPv6 subscribers leverage the NAT64-CGN to access
existing IPv4 internet services. The ISP as an administrative existing IPv4 internet services. The ISP as an administrative
entity takes full control on the IPv6 side, but has limited or no entity takes full control on the IPv6 side, but has limited or no
control on the IPv4 side. ISP's should attempt to accommodate the control on the IPv4 side. NAT64-CGN may have to consider the IPv4
behavior of IPv4 networks and services. Internet environment and services to make appropriate
configurations.
NAT64-FE: A NAT64-FE (server Front End) is generally a traffic load
balancer with NAT64 functionalities in a ICP network.
3. NAT64-CGN Deployment Experiences
A NAT64-CGN deployment scenario is depicted in Figure 1 NAT64-FE: A NAT64-FE (server Front End) is generally a device with
NAT64 functionalities in a content provider or data center
network. It could be for example a traffic load balancer or a
firewall. The operator of the NAT64-FE has full control over the
IPv4 network within the data center, but only limited influence or
control over the external IPv6 network.
----------- 3. NAT64 Networking Experiences
---------- // \\
// \\ / \
/ +----+ \
| |XLAT| |
| An IPv6 +----+ The IPv4 |
| Network +----+ Internet | XLAT: IPv6/IPv4
| |DNS | | Translator
\ +----+ / DNS: DNS64
\\ // \ /
--------- \\ //
-----------
====>
Figure 1: NAT64-CGN Scenario: IPv6 Network to IPv4 Internet 3.1. NAT64-CGN Consideration
3.1. NAT64-CGN Networking Fixed network operators and mobile operators may locate NAT64 in
access networks or in mobile core networks. It can be built into
various devices, including routers, gateways or firewalls in order to
connect IPv6 users to the IPv4 Internet. With regard to the numbers
of users and the shortage of public IPv4 addresses, stateful
NAT64[RFC6146] is more adapted to perform some maximal sharing of
public IPv4 addresses. The usage of stateless NAT64 can be seen with
better transparency features
[I-D.ietf-softwire-stateless-4v6-motivation], while it has to be
coordinated with A+P[RFC6346] processes as specified in
[I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope
with IPv4 shortage.
The NAT64-CGN use case is employed to connect IPv6-only users to the DNS64[RFC6147] is recommended for use in combination with stateful
IPv4 Internet. The NAT64 gateway performs protocol translation from NAT64, and will likely be an essential part of an IPv6 single-stack
an IPv6 packet header to an IPv4 packet header and vice versa network that couples to the IPv4 Internet. And, it will help 464xlat
according to the stateful NAT64 [RFC6146]. Address translation maps to automatically discover NAT64 prefix through
IPv6 addresses to IPv4 addresses and vice versa for return traffic. [I-D.ietf-behave-nat64-discovery-heuristic]. Berkeley Internet Name
Daemon(BIND) software supports the function. It's important to note
that DNS64 generates the synthetic AAAA reply when services only
register A records. Operators should not expect to access IPv4 parts
of a dual-stack server using NAT64/DNS64. NAT64 would forwards all
the traffic on IPv6 paths if dual-stack servers are targeted. In
some sense, it encourages IPv6 transmission and restrains NAT uses
compared to NAT44(if used), on which all traffic flows have to
traverse. Therefore, NAT64 may serve double roles in some cases,
i.e. a translator and IPv6 forwarder. Some failure cases may occur
once NAT64 serves a IPv6 gateway but is configured only with IPv4 on
WAN links. We tested on Top100 websites (referring to [Alexa]
statistics) in such condition. 43% of websites are failed to be
connected since those websites have both AAAA and A records. To be
reliable, it's recommended to enable NAT64 WAN links with dual-stack
connections in the deployment.
All connections to the IPv4 Internet from IPv6-only clients must All connections to IPv4 services from IPv6-only clients must traverse
traverse the NAT64-CGN. It is advantageous from the vantage-point of the NAT64-CGN. It can be 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. In many service translate packets only at or near the network egress. NAT64 can be
provider networks, NAT64 is considered feature of the AS boarder. considered as a feature of the AS (Autonomous System) border in fixed
This allows consistent attribution and traceability within the networks. And, it is likely to be deployed in an IP node beyond the
service provider network. Meaning, within one network, the packet GGSN (Gateway GPRS Support Node) or PDN-GW (Public Data Network-
only has one source. As the packet leaves the network destine for Gateway) in mobile networks or directly in the gateway itself in some
another network, the packet source may be translated as needed. situations. This allows consistent attribution and traceability
within the service provider network. It has been observed that the
process of correlating log information is problematic from multiple-
vendor's equipments due to inconsistent formats of log records.
Placing NAT64 in a centralized location may reduce diversity of log
format and simplify the network provisioning. Moreover, since NAT64
is only targeted at serving traffic flows from IPv6 to IPv4-only
services, the user traffic volume should not be as high as in a NAT44
scenario, and therefore, the gateway's capacity in such location may
not be as much of a concern or a hurdle to deployment. On the other
hand, the placement in a centralized way would require more strict
high availability (HA) design. It would also make geo-location based
on IPv4 addresses rather inaccurate as it is currently the case for
NAT44 CGN already deployed in ISP networks. More considerations or
workarounds on HA and traceability could be found at Section4 and
Section5 .
In mobile networks, various possibilities can be envisaged to deploy NAT64 could likely co-exist with NAT44 in a dual-stack network mostly
the NAT64 function. Whichever option is selected, the NAT64 function because IPv4 private addresses are allocated to customers. The
will be deployed beyond the GGSN (Gateway GPRS Support Node) or coexistence has already appeared in mobile networks, in which dual
PDN-GW (Public Data Network-Gateway), i.e. first IP node in currently stack mobile phones normally initiate some dual-stack PDN/PDP
deployed mobile architectures. Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated
addresses are very often private ones. [RFC6724] always prioritizes
IPv6 connections regardless of whether the end-to-end path is native
IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy
Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The
selection of IPv4/IPv6 paths may depend on particular implementation
choices or settings on a host-by-host basis, and may differ from an
operator's deterministic scheme. Our tests verified that hosts may
find themselves switching between IPv4 and IPv6 paths as they access
identical service, but at different times
[I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each
path is different, it may cause unstable user experiences and some
degradation of Quality of Experience (QoE) when fallback to the other
protocol is not powerful enough for example. It's also difficult for
operators to debug the issue and make optimal resource usages on both
NAT44 and NAT64. It's desirable to find the solutions that will
allow introducing IPv6/IPv4 translation service to IPv6-only hosts
while keeping dual-stack hosts unaffected and IPv4 service unchanged.
In a given implementation, NAT64 functionality can be provided by 3.2. NAT64-FE Consideration
either a dedicated device or an multifunction gateway with integrated
NAT64 functionality. If NAT64 is integrated into an existing node,
capacities of existing nods can be potentially limited by the new
functionality, e.g. maximum concurrent connections. In a mobile
context, the NAT64 function likely be implemented in a firewall,
which is the first hop routed from GGSN/PGW.
3.2. High Availability Considerations Some Internet Content Providers (ICPs) may locate NAT64 in front of
an Internet Data Center (IDC), for example co-located with load
balancing function. Load balancers are employed to connect different
IP family domains, meanwhile distribute workloads across multiple
domains or internal servers actually. In some cases, IPv4 addresses
exhaustion may not be a problem in some IDC's networks. IPv6 support
for some applications may require some investments and workloads so
IPv6 support may not be a priority. The use of NAT64 may be served
to support widespread IPv6 adoption on the Internet while maintaining
IPv4-only applications access.
High Availability (HA) is a major requirement for every service. Different strategy has been described in [RFC6883]referred to as
"inside out" and "outside in". An IDC operator may implement the
following practices in the NAT64-FE networking.
Two mechanisms are typically used to achieve high availability, i.e. o Some ICPs who already have satisfactory operational experiences
cold-standby and hot-standby. Cold-standby systems have synchronized would adopt single stack IPv6 operations to build up their data
configuration and mechanism to failover traffic between the hot and center network, servers and applications since it allows new
cold systems such as VRRP [RFC5798] . Unlike hot-standby, cold- services delivery without having to integrate consideration of
standby does not synchronize NAT64 session state. This makes cold- IPv4 NAT and address limitations of IPv4 networks. Stateless
standby less resource intensive and generally simpler, but it NAT64[RFC6145]is used to provide services for IPv4-only
requires clients to re-establish sessions when a fail-over occurs. subscribers. [I-D.anderson-siit-dc]has provided further
Hot-standby has all the features of cold-standby but must also descriptions and guidelines.
synchronize the binding information base (BIB). Given that short
lived sessions account for most of the bindings, hot-standby does not
offer much benefit for those sessions. Consideration should be given
to the importance (or lack thereof) of maintaining bindings for long
lived sessions across failovers.
3.3. Traceability o ICPs who attempt to offer customers IPv6 support in their
application farms at an early stage may likely run some proxies,
which are configured to handle incoming IPv6 flows and proxy them
to IPv4 back-end systems. Many load balancers have already
integrated some proxy functionalities. IPv4 addresses configured
in the proxy can be multiplexed like a stateful NAT64 performs. A
similar challenge exists once increasingly numerous users in IPv6
Internet access an IPv4 network. High loads on load-balancers may
be apt to cause additional latency, IPv4 pool exhaustion, etc.
Therefore, this approach is only reasonable at an early stage.
ICPs may learn from the experiences and move on to dual-stack or
IPv6 single stack in a further stage, since the native IPv6 is
always more desirable than transition solutions.
Traceablility is required in many cases such as identifying malicious [RFC6144] recommends that AAAA records of load-balancers or
attacks sources and accounting requirements. NAT64 devices are application servers can be directly registered in the authoritative
required to log events like creation and deletion of translations and DNS servers requiring to populate these servers with corresponding
information about the occupied resources. There are two different AAAA records. In this case, there is no need to deploy DNS64
demands for traceability,i.e. online or offline. servers. Those AAAA records can be some native IPv6 addresses or
some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6
address does not give the possibility to nodes to get any information
about NAT64 presence on communication path and the possibility to
prefer IPv4 path or the IPv6 path in dual-stack networks. Using an
independent sub domain e.g. ipv6exp.xxx.xxx may help to identify
experimental ipv6 services to users. How to design the FQDN for the
IPv6 service is out-of-scope of this document.
o Regarding the Online requirements, XFF (X-Forwarded-For) 4. High Availability
[I-D.ietf-appsawg-http-forwarded]would be a candidate, it appends
IPv6 address of subscribers to HTTP headers which is passed on to
WEB servers, and the querier server can lookup radius servers for
the target subscribers based on IPv6 addresses included in XFF
HTTP headers. X-Forwarded-For is specific to HTTP, requires the
use of an application aware gateway, cannot in general be applied
to requests made over HTTPs and cannot be assumed to be preserved
end-to-end as it may be overwritten by other application-aware
proxies such as load balancers.
o Some potential solutions to online traceability are explore in 4.1. Redundancy Design
[I-D.ietf-intarea-nat-reveal-analysis]. High Availability (HA) is a major requirement for every service and
network services. The deployment of redundancy mechanism is an
essential approach to avoid single-point failure and significantly
increase the network reliability. It's not only useful to stateful
NAT64 cases, but also to stateless NAT64 gateways.
o A NAT64-CGN could also deliver NAT64 sessions (BIB and STE) to a Three redundancy modes are mainly used hereafter: cold standby, warm
Radius server by extension of the radius protocol. Such an standby and hot standby.
extension is an alternative solution for online traceability,
particularly high performance would be required on Radius servers
in order to achieve this.
o For off-line traceability, syslog might be a good choice. o Cold standby can't replicate the NAT64 states from the primary
[RFC6269] indicates address sharing solutions generally need to equipment to the backup. Administrators switch on the backup
record and store information for specific periods of time. A NAT64 only if the primary NAT64 fails. As the results, all the
stateful NAT64 is supposed to manage one mapping per session. A existing established sessions will be disconnected. The internal
large volume of logs poses a challenge for storage and processing. hosts are required to re-establish sessions to the external hosts.
In order to mitigate the issue, Since the backup NAT64 is manually configured to switch over to
[I-D.donley-behave-deterministic-cgn]is proposed to pre-allocated active NAT64, it may have unpredictable impacts to the ongoing
a group of ports for each specific IPv6 host. A trade-off among services. Normally, the handover would take several minutes so as
address multiplexing efficiency, port randomization to wait for the whole process of NAT64 bootstrap loader.
security[RFC6056] and logging storage compression should be
considered during the planning. A hybrid mode combining
deterministic and dynamic port assignment was recommended
regarding the uncertainty of user traffic.
3.4. Quality of Experience o Warm standby is a flavor of the cold standby mode. Backup NAT64
would keep running once the primary NAT64 is working. This makes
warm standby less time consuming during the traffic failover.
Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a
solution to enable automatic handover in the warm standby. It was
tested that the handover takes as maximum as 1 minute if the
backup NAT64 needs to take over routing and re-construct the
Binding Information Base (BIB) for 30 million sessions. In
deployment phase, operators could balance loads on distinct NAT64s
devices. Those NAT64s make a warm backup of each other.
NAT64 is providing a translation capability between IPv6 and IPv4 o Hot standby must synchronize the BIBs between the primary NAT64
end-nodes. In order to provide the reachability between two IP and backup. When the primary NAT64 fails, backup NAT64 would take
address families, NAT64-CGN has to implement appropriate ALGs where over and maintain the state of all existing sessions. The
address translation is not itself sufficient and security mechanisms internal hosts don't have to re-connect the external hosts. The
do not render it infeasible. e.g. FTP-ALG[RFC6384], RSTP-ALG, H.323- handover time has been extremely reduced. Thanks to Bidirectional
ALG,etc. It should be noted that ALGs may impact the performance on Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay
a NAT64 box to some extent. ISPs as well as content providers might of only 35ms for 30 million sessions handover was observed during
choose to avoid situations where the imposition of an ALG might be testing. In some sense, it could guarantee the session continuity
required. At the same time, it is also important to remind customers for every service. In order to timely transmit states
and application developers that IPv6 end-to-end usage does not information, operators may have to deploy extra transport links
require ALG imposition and therefore results in a better overall user between primary NAT64 and distant backup.
experience.
Session status normally is managed by a static life-cycle. In some In general, cold-standby and warm-standby is simpler and less
cases, NAT resource maybe significantly consumed by largely inactive resource intensive, but it requires clients to re-establish sessions
users. The NAT translator and other customers would suffer from when a fail-over occurs. Hot standby doubles resource's consumption
service degradation due to port consummation by other subscribers to synchronize the states, but it achieve seamless handover. The
using the same NAT64 device. A flexible NAT session control is consideration of redundancy mode for stateless NAT64 is simple,
desirable to resolve the issues. PCP[I-D.ietf-pcp-base] could be a because it doesn't have to consider time consuming for states
candidate to provide such capability. A NAT64-CGN should integrate maintenance. The warm standby is sufficient for stateless NAT64. In
with a PCP server, to allocate available IPv4 address/Port resources. regards to stateful NAT64, it maybe useful to investigate performance
Resources could be assigned to PCP clients through PCP MAP/PEER mode. tolerance of applications and the traffic characteristics in a
Such an ability should also be considered to upgrade user particular network. The following table is trying to evaluate user
experiences, e.g. assigning different sizes of port ranges for experience from a lab testing.
different subscribers. Such a mechanism is also helpful to minimize
terminal battery consumption and reduce the number of keepalive
messages to be sent by terminal devices.
3.5. NAT64-CGN Load Balancer Table 1: The acceptable delay of applications
+----------------+------------------------+-------------------------+
| APPs | Acceptable Interrupt | Session Continuity |
| | Recovery | |
+----------------+------------------------+-------------------------+
| Web Browse |As maximum as 6s | No |
+----------------+------------------------+-------------------------+
|Http streaming |As maximum as 10s(cache)| Yes |
+----------------+------------------------+-------------------------+
| Gaming | 200ms~400ms | Yes |
+----------------+------------------------+-------------------------+
| P2P | 10~16s | Yes |
+----------------+------------------------+-------------------------+
|Instant Message |1 minute | Yes |
+----------------+------------------------+-------------------------+
|Mail |30 seconds | No |
+----------------+------------------------+-------------------------+
|Downloading |1 minutes | No |
+----------------+------------------------+-------------------------+
Load balancers are an essential tool to avoid the issue of single Our statistics in a mobile network shown that almost 91.21% of amount
points of failure and add additional scale. It is potentially of traffic is accounted by browsing services. Those services don't
important to employ load-balancing considering that deployment of require session continuity. The handover time of warm standby is
multiple NAT64 devices. Load balancers are required to achieve some qualified to the delay tolerance. Hot-standby does not offer much
service continuity and scale for customers. benefit for those sessions on this point. In a fixed network, HTTP
[I-D.zhang-behave-nat64-load-balancing] discusses several ways of streaming, p2p and online games would be the major
achieving NAT64 load balancing, including anycast based policy and traffic[Cisco-VNI]. Consideration should be given to the importance
prefix64 selection based policy, either implemented via of maintaining bindings for those sessions across failovers.
DNS64[RFC6147] or Prefix64 assignments. Since DNS64 is normally co- Operators may also consider the Average Revenue Per User (ARPU)
located with NAT64 in some scenarios, it could be leveraged to factors to deploy suitable redundancy mode. Warm standby may still
perform the load balance. For traffic which does not require a DNS be adopted to cover most services while hot standby could be used to
resolution, prefix64 assignment based upgrade Quality of Experience (QoE) using DNS64 with different
on[I-D.ietf-behave-nat64-learn-analysis] could be adopted. synthetic responses for limited traffic. Further considerations are
discussed at Section 6.
3.6. MTU Consideration 4.2. Load Balancing
IPv6 requires that every link in the internet have an MTU of 1280 Load balancing is used to accompany redundancy design so that better
octets or greater[RFC2460]. However, in case of NAT64 translation scalability and resiliency could be achieved. Stateless NAT64s allow
deployment, some IPv4 MTU constrained link will be used in some asymmetric routing while anycast-based solutions are recommended in
communication path and originating IPv6 nodes may therefore receive [I-D.ietf-softwire-map-deployment]. The deployment of load balancing
an ICMP Packet Too Big message, reporting a Next-Hop MTU less than may make more sense to stateful NAT64s for the sake of single-point
1280. The result would be that IPv6 allows packets to contain a failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct
fragmentation header, without the packet being fragmented into facilities, the following lists the considerations for each case.
multiple pieces. [I-D.ietf-6man-ipv6-atomic-fragments] discusses how
this situation could be exploited by an attacker to perform
fragmentation-based attacks, and also proposes an improved handling
of such packets. It required enhancements on protocol level, which
might imply potential upgrade/modifications on behaviors to deployed
nodes. Another approach that potentially avoids this issue is to
configure IPv4 MTU>=1260. It would forbid the occurrence of
PTB<1280. However, such an operational consideration is hard to
universally apply to the legacy "IPv4 Internet".
4. NAT64-FE Deployment Experiences o NAT64-CGN equipments don't implement load balancer functions on a
board card. Therefore, the gateways have to resort to DNS64 or
internal host's behavior. Once DNS64 is deployed, the load
balancing can be performed by synthesizing AAAA response with
different IPv6 prefixes. With the absence of DNS64, internal
hosts could learn multiple IPv6 prefixes through the approaches
defined in[I-D.ietf-behave-nat64-discovery-heuristic] and then
select one based on a given prefix selection policy.
The NAT64-FE Scenario is depicted in Figure 2 o A dedicated Load Balancer could be deployed at front of a NAT64-FE
-------- farm. Load Balancer uses proxy mode to redirect the flows to the
// \\ ---------- appropriate NAT64 instance. Stateful NAT64s require a
/ \ // \\ deterministic pattern to arrange the traffic in order to ensure
/ +----+ \ outbound/inbound flows traverse the identical NAT64. Therefore,
| |XLAT| | static scheduling algorithms, for example source-address based
| The IPv6 +----+ An IPv4 | policy, is preferred. A dynamic algorithm, for example Round-
| Internet +----+ Network | XLAT: IPv4/IPv6 Robin, may have impacts on applications seeking session
| /Network |DNS | | Translator continuity, which described in the Table 1.
\ +----+ / DNS: DNS64
\ / \\ //
\\ // ----------
--------
====>
Figure 2: NAT64-FE Scenario: IPv6 Internet/Network to IPv4 Network 5. Source Address Transparency
4.1. NAT64-FE Networking 5.1. Traceability
There are plenty of practices to equip load balancer with NAT64 at Traceability is required in many cases such as identifying malicious
front of servers. Two different cases appeared in the NAT64-FE attacks sources and accounting requirements. Operators are asked to
networking. record the NAT64 log information for specific periods of time. In
our lab testing, the log information from 200,000 subscribers have
been collected from a stateful NAT64 gateway for 60 days.
Syslog[RFC5424] has been adopted to transmit log message from NAT64
to a log station. Each log message contains transport protocol,
source IPv6 address:port, translated IPv4 address: port and
timestamp. It takes almost 125 bytes long in ASCII format. It has
been verified that the volume of recorded information reach up to
42.5 terabytes in the raw format and 29.07 terabytes in a compact
format. Operators have to build up dedicated transport links,
storage system and servers for the purpose. There are also several
implementations to mitigate the issue. For example, stateful NAT64
could dynamically assign a port range to each subscriber or perform
static port-range allocations as
[I-D.donley-behave-deterministic-cgn] proposed. Those methods can
change log granularity from per-session to per-customer. The
recorded log volume can be reduced to 40.6 gigabytes accordingly.
However, the IPv4 multiplexing efficiency is also decreased regarding
to those methods. For example, the utilization ratio of public IPv4
address is dropped approximately to 75% when sized 400 ports range
allocated to each device according to our statistics. In addition,
port-range based allocation should also consider port randomization
described in [RFC6056] . A trade-off among address multiplexing
efficiency, logging storage compression and port allocation
complexity should be considered. More discussions could be found in
[I-D.chen-sunset4-cgn-port-allocation].Basically, the decision
depends on usable IPv4 resource and investments of log systems.
o Some content providers who has a wealth of IPv6 experiences 5.2. Geo-location
consider IPv6-only strategy to serve customers since it allows new
services delivery without having to integrate consideration of
IPv4 NAT and address limitations of IPv4 networks. Whereas they
have to provide some IPv4 service continuity to their customers,
stateless IP/ICMP Translation (SIIT) [RFC6145]has been used to
continue provide services for IPv4 subscribers.
o ICPs who have insufficient IPv6 incentive likely prefer short-term IP addresses are usually used as inputs to geo-location services.
alternatives to provide IPv6 connectivity due to the widespread The use of address sharing will prevent these systems from resolving
impact of supporting IPv6 within a ICP environment. A stateful the location of a host based on IP address alone. Applications that
NAT64 has been located at front of servers. It could assume such geographic information may not work as intended. The
simultaneously facilitate the IPv6 accessibility and conservation possible solutions listed in [RFC6967] are intended to bridge the
of IPv4 servers. [I-D.ietf-v6ops-icp-guidance]has described the gap. However, those solutions can only provide a sub-optimal
cases, in which an HTTP proxy can readily be configured to handle substitution to solve the problem of host identification, in
incoming connections over IPv6 and to proxy them to a server over particular it may not today solve problems with source identification
IPv4. through translation. The following lists current practices to
mitigate the issue.
For first case, [I-D.anderson-siit-dc]has provided further o Operators who adopt NAT64-FE may leverage the application layer
descriptions and guidelines. This document is addressed to second proxies, e.g. XFF (X-Forwarded-For)
case. An administrator of the IPv4 network needs to be cautious and [I-D.ietf-appsawg-http-forwarded], to convey the IPv6 source
aware of the operational issues in the case since the native IPv6 is address in HTTP headers. Those messages would be passed on to
always more desirable than transition solutions. web-servers. The queried server can lookup Radius servers for the
target subscribers based on IPv6 addresses included in XFF HTTP
headers. XFF is the de facto standard which has been integrated
in most Load Balancers. Therefore, it may be superior to use in a
NAT-FE environment. In the downsides, XFF is specific to HTTP.
It restricts the usages so that the solution can't be applied to
requests made over HTTPs. This makes geo-location problematic for
HTTPs based services.
One potential challenge is stateful NAT64-FE facing IPv6 Internet, in o The NAT64-CGN equipments may not implement XFF. Geo-location
which a significant number of IPv6 users may initiate connections. based on shared IPv4 address is rather inaccurate in that case.
When increasingly numerous users in IPv6 Internet access an IPv4 It's desirable to offer geo-location system more information, for
network, scalability concerns(e.g. additional latency, a single point example port number to retrieve the internal IPv6 address, which
of failure, IPv4 pool exhaustion, etc) are apt to be applied. For a has meaning in global scale. We have investigated to deliver
given off-the-shelf NAT64-FE, those challenges should be seriously NAT64 BIBs and Session Table Entrys (STEs) to a Radius
assessed. Potential issues should be properly identified. server[I-D.chen-behave-nat64-radius-extension], since current geo-
location systems rely on a Radius database to inspect location
information, for example the information provided in [RFC5580].
Those methods could convey original source address through same
message bus. Another approach is to ask NAT64-CGN providing
application aware gateway to insert IPv6 source addresses.
However, that may introduce complexity and performance
degradation.
Following subsections described several considerations to stateful 6. Quality of Experience
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 6.1. Service Reachability
IP addresses are usually used as input to geo-location services. The NAT64 is providing a translation capability between IPv6 and IPv4
use of address sharing will prevent these systems from resolving the end-nodes. In order to provide the reachability between two IP
location of a host based on IP address alone. Applications that address families, NAT64-CGN has to implement appropriate application
assume such geographic information may not work as intended. The aware functions, i.e. Application Layer Gateway(ALG), where address
possible solutions listed at section 3.3 intended to bridge the gap. translation is not itself sufficient and security mechanisms do not
However, the analysis reveals those solutions can't be a optimal render it infeasible. Most NAT64-CGNs mainly provide FTP-
substitution to solve the problem of host identification, in ALG[RFC6384]. NAT64-FEs may have functional richness on Load
particular it does not today mitigate problems with source Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have
identification through translation. That makes NAT64-FE usage been supported. It should be noted that ALGs may impact the
becoming a unappealing approach, if customers require source address performance on a NAT64 box to some extent. ISPs as well as content
tracking. providers might choose to avoid situations where the imposition of an
ALG might be required. At the same time, it is also important to
remind customers and application developers that IPv6 end-to-end
usage does not require ALG imposition and therefore results in a
better overall user experience.
For the operators, who already deployed NAT64-FE approach, the source 6.2. Resource Reservation
address of the request is obscured without the source address mapping
information previously obtained. It's superior to present mapping
information directly to applications. Some application layer proxies
e.g. XFF (X-Forwarded-For) , can convey this information in-band.
Another approach is to ask application coordinating the information
with NAT logging. But that is not sufficient, since the applications
itself wants to know the original source address from an application
message bus. The logging information may be used by administrators
offline to inspect use behavior and preference analysis, and accurate
advertisement delivery.
4.3. DNS Resolving Session status normally is managed by a static timer. For example,
the value of the "established connection idle-timeout" for TCP
sessions must not be less than 2 hours 4 minutes[RFC5382] and 5
minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe
significantly consumed by largely inactive users. The NAT translator
and other customers would suffer from service degradation due to port
consummation by other subscribers using the same NAT64 device. A
flexible NAT session control is desirable to resolve the issues.
PCP[RFC6887] could be a candidate to provide such capability. A
NAT64-CGN should integrate with a PCP server, to allocate available
IPv4 address/port resources. Resources could be assigned to PCP
clients through PCP MAP/PEER mode. Such ability can be considered to
upgrade user experiences, for example assigning different sizes of
port ranges for different subscribers. Those mechanisms are also
helpful to minimize terminal battery consumption and reduce the
number of keep-alive messages to be sent by mobile terminal devices.
In the case of NAT64-FE, it is recommended to follow the Subscribers can also benefit from network reliability. It has been
recommendations in [RFC6144]. There is no need for the DNS to discussed that hot-standby offers satisfactory experience once outage
synthesize AAAA from A records, since static AAAA records can be of primary NAT64 is occurred. Operators may rightly be concerned
registered in the authoritative DNS for a given domain to represent about the considerable investment required for NAT64 equipment
these IPv4-only hosts. How to design the FQDN for the IPv6 service relative to low ARPU income. For example, transport links may cost
is out-of-scope of this document. much, because primary NAT64 and backup are normally located at
different locations, separated by a relatively large distance.
Additional maintenance has to be spent to ensure the connectivity
quality. However, that may be necessary to some applications, which
are delay-sensitive and seek session continuity, for example on-line
games and live-streaming. Operators may be able to get added-values
from those services by offering first-class services. It can be pre-
configured on the gateway to hot-standby modes depending on
subscriber's profile. The rest of other sessions can be covered by
cold/warm standby.
4.4. Load Balancer 7. MTU Considerations
Load balancing on NAT64-FE has a couple of considerations. If IPv6 requires that every link in the internet have an Maximum
dictated by scale or availability requirements traffic should be Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. However,
balanced among multiple NAT64-CE devices. One point to be noted is in case of NAT64 translation deployment, some IPv4 MTU constrained
that synthetic AAAA records may be added directly in authoritative link will be used in some communication path and originating IPv6
DNS. load balancing based on DNS64 synthetic resource records may not nodes may therefore receive an ICMP Packet Too Big (PTB) message,
work in those cases. Secondly, NAT64-FE could also serve as the load reporting a Next-Hop MTU less than 1280 bytes. The result would be
balancer for IPv4 backend servers. There are also some ways of load that IPv6 allows packets to contain a fragmentation header, without
balance for the cases, where load balancer is placed in front of the packet being fragmented into multiple pieces. A NAT64 would
NAT64-FE. receive IPv6 packets with fragmentation header in which "M" flag
equal to 0 and "Fragment Offset" equal to 0. Those packets likely
impact other fragments already queued with the same set of {IPv6
Source Address, IPv6 Destination Address, Fragment Identification}.
If the NAT64 box is compliant with [RFC5722], there is risk that all
the fragments have to be dropped.
4.5. MTU Consideration [RFC6946] discusses how this situation could be exploited by an
attacker to perform fragmentation-based attacks, and also proposes an
improved handling of such packets. It required enhancements on NAT64
gateway implementations to isolate packet's processing. NAT64 should
follow the recommendation and take steps to prevent the risks of
fragmentation.
As compared to the MTU consideration in NAT64-CGN, the MTU of IPv4 Another approach that potentially avoids this issue is to configure
network are strongly recommended to set to more than 1260. Since a IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB
IPv4 network is normally operated by a particular administrative smaller than 1280 bytes. Such an operational consideration is hard
entity, it should take steps to prevent the risk of fragmentation to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged.
discussed in [I-D.ietf-6man-ipv6-atomic-fragments]. However, it's a feasible approach in NAT64-FE cases, since a IPv4
network NAT64-FE connected is rather well-organized and operated by a
IDC operator or content provider. Therefore, the MTU of IPv4 network
in NAT64-FE case are strongly recommended to set to more than 1260
bytes.
4.6. Anti-DDoS/SYN Flood 8. Security Considerations
For every incoming new connection from the IPv6 Internet, the This document presents the deployment experiences of NAT64 in CGN and
stateful NAT64-FE creates state and maps that connection to an FE scenarios. In general, RFC 6146[RFC6146] provides TCP-tracking,
address-dependent filtering mechanisms to protect NAT64 from
Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators
also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and
black/white-list to enhance the security by specifying access
policies. For example, NAT64-CGN should forbid establish NAT64 BIB
for incoming IPv6 packets if uRPF in Strict or Loose mode check does
not pass or whose source IPv6 address is associated to black-lists.
The stateful NAT64-FE creates state and maps that connection to an
internally-facing IPv4 address and port. An attacker can consume the internally-facing IPv4 address and port. An attacker can consume the
resources of the NAT64-FE device by sending an excessive number of resources of the NAT64-FE device by sending an excessive number of
connection attempts. Without a DDOS limitation mechanism, the connection attempts. Without a DDoS limitation mechanism, the
NAT64-FE is exposed to attacks. With service provisioning, attacks NAT64-FE is exposed to attacks. Load Balancer is recommended to
have the potential could also deteriorate service quality. One enable the capabilities of line rate DDOS defense, such as the
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 employment of SYN PROXY-COOKIE. Security domain division is
necessary in this case. Load Balancers could not only serve for necessary as well in this case. Therefore, Load Balancers could not
optimization of traffic distribution, but also serve as a DOS only serve for optimization of traffic distribution, but also prevent
mitigation device. service from quality deterioration due to security attacks.
5. Security Considerations
This document presents the deployment experiences of NAT64 in CGN and
FE scenario, some security considerations are described in detail
regarding to specific NAT64 mode in section 3 and 4. In general, RFC
6146[RFC6146] provides TCP-tracking, address-dependent filtering
mechanisms to protect NAT64 from DDOS. In NAT64-CGN cases, ISP also
could adopt uRPF and black/white-list to enhance the security by
specifying access policies. For example, NAT64-CGN should forbid
establish NAT64 BIB for incoming IPv6 packets if URPF (Strict or
Loose mode) check does not pass or whose source IPv6 address is
associated to black-lists.
6. IANA Considerations 9. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
7. Acknowledgements 10. 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, Iljitsch van Beijnum and Philip Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum, Philip
Matthews for their helpful comments. Many thanks to Wesley George Matthews and Randy Bush for their helpful comments.
and Satoru Matsushima for their reviews.
The authors especially thank Joel Jaeggli for his efforts and Many thanks to Wesley George and Satoru Matsushima for their reviews.
contributions on editing which substantially improves the legibility
of the document.
8. Additional Author List The authors especially thank Joel Jaeggli and Ray Hunter for his
efforts and contributions on editing which substantially improves the
legibility of the document.
Thanks to Cameron Byrne who was an active co-author of some earlier
versions of this draft.
11. 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
China Telecom China Telecom
Room 708, No.118, Xizhimennei Street Room 708, No.118, Xizhimennei Street
Beijing 100035 Beijing 100035
P.R.China P.R.China
Phone: +86-10-58552936 Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn Email: sunqiong@ctbri.com.cn
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 12. References
9.1. Normative References
[I-D.ietf-pcp-base] 12.1. Normative References
Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", [I-D.ietf-appsawg-http-forwarded]
draft-ietf-pcp-base-29 (work in progress), November 2012. Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 2012.
[I-D.ietf-behave-nat64-discovery-heuristic]
Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", draft-
ietf-behave-nat64-discovery-heuristic-17 (work in
progress), April 2013.
[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.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
[RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B.
Aboba, "Carrying Location Objects in RADIUS and Diameter",
RFC 5580, August 2009.
[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
RFC 5722, December 2009.
[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.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[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, 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 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
6946, May 2013.
12.2. Informative References
[Alexa] Alexa, "http://www.alexa.com/topsites", April 2013.
[Cisco-VNI]
Cisco, "Cisco Visual Networking Index: Forecast and
Methodology, 2012-2017,
http://ciscovni.com/forecast-widget/index.html", May 2013.
[I-D.anderson-siit-dc] [I-D.anderson-siit-dc]
Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data
Centre Environments", draft-anderson-siit-dc-00 (work in Centre Environments", draft-anderson-siit-dc-00 (work in
progress), November 2012. progress), November 2012.
[I-D.chen-behave-nat64-radius-extension]
Chen, G. and D. Binet, "Radius Attributes for Stateful
NAT64", draft-chen-behave-nat64-radius-extension-00 (work
in progress), July 2013.
[I-D.chen-sunset4-cgn-port-allocation]
Chen, G., "Analysis of NAT64 Port Allocation Method",
draft-chen-sunset4-cgn-port-allocation-01 (work in
progress), February 2013.
[I-D.donley-behave-deterministic-cgn] [I-D.donley-behave-deterministic-cgn]
Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 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", Logging in Carrier Grade NAT Deployments", draft-donley-
draft-donley-behave-deterministic-cgn-05 (work in behave-deterministic-cgn-05 (work in progress), January
progress), January 2013. 2013.
[I-D.ietf-6man-ipv6-atomic-fragments]
Gont, F., "Processing of IPv6 "atomic" fragments",
draft-ietf-6man-ipv6-atomic-fragments-03 (work in
progress), December 2012.
[I-D.ietf-appsawg-http-forwarded]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 2012.
[I-D.ietf-behave-nat64-learn-analysis] [I-D.ietf-softwire-4rd]
Korhonen, J. and T. Savolainen, "Analysis of solution Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
proposals for hosts to learn NAT64 prefix", M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
draft-ietf-behave-nat64-learn-analysis-03 (work in Solution (4rd)", draft-ietf-softwire-4rd-05 (work in
progress), March 2012. progress), April 2013.
[I-D.ietf-intarea-nat-reveal-analysis] [I-D.ietf-softwire-map-deployment]
Boucadair, M., Touch, J., Levis, P., and R. Penno, Sun, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault,
"Analysis of Solution Candidates to Reveal a Host "Mapping of Address and Port (MAP) - Deployment
Identifier (HOST_ID) in Shared Address Deployments", Considerations", draft-ietf-softwire-map-deployment-01
draft-ietf-intarea-nat-reveal-analysis-04 (work in (work in progress), February 2013.
progress), August 2012.
[I-D.ietf-v6ops-464xlat] [I-D.ietf-softwire-map-t]
Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
Combination of Stateful and Stateless Translation", T. Murakami, "Mapping of Address and Port using
draft-ietf-v6ops-464xlat-09 (work in progress), Translation (MAP-T)", draft-ietf-softwire-map-t-02 (work
January 2013. in progress), July 2013.
[I-D.ietf-v6ops-icp-guidance] [I-D.ietf-softwire-stateless-4v6-motivation]
Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Content and Application Service Providers", Borges, I., and G. Chen, "Motivations for Carrier-side
draft-ietf-v6ops-icp-guidance-05 (work in progress), Stateless IPv4 over IPv6 Migration Solutions", draft-ietf-
January 2013. softwire-stateless-4v6-motivation-05 (work in progress),
November 2012.
[I-D.zhang-behave-nat64-load-balancing] [I-D.kaliwoda-sunset4-dual-ipv6-coexist]
Zhang, D., Xu, X., and M. Boucadair, "Considerations on Kaliwoda, A. and D. Binet, "Co-existence of both dual-
NAT64 Load-Balancing", stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual-
draft-zhang-behave-nat64-load-balancing-03 (work in ipv6-coexist-01 (work in progress), October 2012.
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.
[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, Protocol Port Randomization", BCP 156, RFC 6056, January
January 2011. 2011.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011. IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, Roberts, "Issues with IP Address Sharing", RFC 6269, June
June 2011. 2011.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012.
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012. Network", RFC 6586, April 2012.
[RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT:
Combination of Stateful and Stateless Translation", RFC
6877, April 2013.
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers", RFC
6883, March 2013.
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Potential Solutions for Revealing a Host
Identifier (HOST_ID) in Shared Address Deployments", RFC
6967, June 2013.
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
China China
Email: phdgang@gmail.com Email: phdgang@gmail.com
Zhen Cao Zhen Cao
China Mobile China Mobile
53A,Xibianmennei Ave., 53A,Xibianmennei Ave.,
Xuanwu District, Xuanwu District,
Beijing 100053 Beijing 100053
China China
Email: caozhen@chinamobile.com Email: caozhen@chinamobile.com
Cameron Byrne
T-Mobile USA
Bellevue
Washington 98105
USA
Email: cameron.byrne@t-mobile.com
Chongfeng Xie Chongfeng Xie
China Telecom China Telecom
Room 708 No.118, Xizhimenneidajie Room 708 No.118, Xizhimenneidajie
Beijing 100035 Beijing 100035
P.R.China P.R.China
Email: xiechf@ctbri.com.cn Email: xiechf@ctbri.com.cn
David Binet David Binet
France Telecom France Telecom-Orange
Rennes Rennes
35000 35000
France France
Email: david.binet@orange.com Email: david.binet@orange.com
 End of changes. 90 change blocks. 
428 lines changed or deleted 612 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/