draft-ietf-v6ops-nat64-experience-10.txt   rfc7269.txt 
Internet Engineering Task Force G. Chen Internet Engineering Task Force (IETF) G. Chen
Internet-Draft Z. Cao Request for Comments: 7269 Z. Cao
Intended status: Informational China Mobile Category: Informational China Mobile
Expires: September 11, 2014 C. Xie ISSN: 2070-1721 C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom-Orange France Telecom-Orange
March 10, 2014 June 2014
NAT64 Deployment Options and Experience NAT64 Deployment Options and Experience
draft-ietf-v6ops-nat64-experience-10
Abstract Abstract
This document summarizes NAT64 function deployment scenarios and This document summarizes NAT64 function deployment scenarios and
operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and
NAT64 server Front End (NAT64-FE) are considered in this document. NAT64 server Front End (NAT64-FE) are considered in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on September 11, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7269.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 16 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NAT64 Networking Experience . . . . . . . . . . . . . . . . . 4 3. NAT64 Networking Experience . . . . . . . . . . . . . . . . . 4
3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4 3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4
3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4 3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4
3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4 3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4
3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5 3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5
3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5 3.1.4. Coexistence of NAT64 and NAT44 . . . . . . . . . . . 5
3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9
5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 5. Source-Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 13
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Additional Author List . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . 18
13.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Test Results for Application Behavior . . . . . . . 21
Appendix A. Testing Results of Application Behavior . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
IPv6 is the only sustainable solution for numbering nodes on Internet IPv6 is the only sustainable solution for numbering nodes on the
due to the IPv4 depletion. Network operators have to deploy Internet due to the IPv4 depletion. Network operators have to deploy
IPv6-only networks in order to meet the needs of the expanding IPv6-only networks in order to meet the needs of the expanding
internet without available IPv4 addresses. Internet without available IPv4 addresses.
Single-stack IPv6 network deployment can simplify networks Single-stack IPv6 network deployment can simplify network
provisioning, some justification was provided in 464xlat [RFC6877]. provisioning; some justification was provided in 464XLAT [RFC6877].
IPv6-only connectivity confers some benefits to mobile operators as IPv6-only connectivity confers some benefits to mobile operators as
an example. In the mobile context, IPv6-only usage enables the use an example. In the mobile context, IPv6-only usage enables the use
of a single IPv6 Packet Data Protocol(PDP) context or Evolved Packet of a single IPv6 Packet Data Protocol (PDP) context or Evolved Packet
System (EPS) bearer on Long Term Evolution (LTE) networks. This System (EPS) bearer on Long Term Evolution (LTE) networks. This
eliminates significant network costs caused by employing two PDP eliminates significant network costs (caused by employing two PDP
contexts in some cases, and the need for IPv4 addresses to be contexts in some cases) and the need for IPv4 addresses to be
assigned to customers. In broadband networks overall, it can allow assigned to customers. In broadband networks overall, it can allow
for the scaling of edge-network growth to be decoupled from IPv4 for the scaling of edge-network growth to be decoupled from IPv4
numbering limitations. numbering limitations.
In transition scenarios, some existing networks are likely to be In transition scenarios, some existing networks are likely to be IPv4
IPv4-only for quite a long time. IPv6 networks and hosts IPv6-only only for quite a long time. IPv6 networks and IPv6-only hosts will
hosts will need to coexist with IPv4 numbered resources. Widespread need to coexist with IPv4 numbered resources. Widespread dual-stack
dual-stack deployments have not materialized at the anticipated rate deployments have not materialized at the anticipated rate over the
over the last 10 years, one possible conclusion being that legacy last 10 years, one possible conclusion being that legacy networks
networks will not make the jump quickly. The Internet will include will not make the jump quickly. The Internet will include nodes that
nodes that are dual-stack, nodes that remain IPv4-only, and nodes are dual stack, nodes that remain IPv4 only, and nodes that can be
that can be deployed as IPv6-only nodes. A translation mechanism deployed as IPv6-only nodes. A translation mechanism based on a
based on a NAT64[RFC6146] [RFC6145]function is likely to be a key NAT64 function [RFC6145] [RFC6146] is likely to be a key element of
element of Internet connectivity for IPv6-IPv4 interoperability. Internet connectivity for IPv6-IPv4 interoperability.
[RFC6036] reports at least 30% of operators plan to run some kind of [RFC6036] reports 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
operations are therefore of some importance. [RFC6586] documents the operations are therefore of some importance. [RFC6586] documents 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 2. Terminology
Regarding IPv4/IPv6 translation, [RFC6144] has described a framework Regarding IPv4/IPv6 translation, [RFC6144] has described a framework
for enabling networks to make interworking possible between IPv4 and for enabling networks to make interworking possible between IPv4 and
IPv6 networks. This document has further categorized different NAT64 IPv6 networks. Two operation modes (i.e., stateful translation and
functions, locations and use-cases. The principle distinction of stateless translation) have been described in Section 3.2 of
location is whether the NAT64 is located in a Carrier Grade NAT or [RFC6144]. This document describes the usage of those two operation
server Front End. The terms of NAT-CGN/FE are understood to be a modes and has further categorized different NAT64 functions,
locations, and use cases. The principal distinction of location is
whether the NAT64 is located in a Carrier-Grade NAT or server Front
End. The terms "NAT-CGN" and "NAT-FE" are understood to be a
topological distinction indicating different features employed in a topological distinction indicating different features employed in a
NAT64 deployment. NAT64 deployment.
NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP
network. IPv6 enabled subscribers leverage the NAT64-CGN to network. IPv6-enabled subscribers leverage the NAT64-CGN to
access existing IPv4 internet services. The ISP as an access existing IPv4 Internet services. The ISP as an
administrative entity takes full control of the IPv6 side, but has administrative entity takes full control of the IPv6 side, but it
limited or no control on the IPv4 internet side. NAT64-CGN has limited or no control on the IPv4 Internet side. NAT64-CGN
deployments may have to consider the IPv4 Internet environment and deployments may have to consider the IPv4 Internet environment and
services, and make appropriate configuration choices accordingly. services, and make appropriate configuration choices accordingly.
NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device
with NAT64 functionality in a content provider or data center with NAT64 functionality in a content provider or data center
network. It could be for example a traffic load balancer or a network. It could be, for example, a traffic load balancer or a
firewall. The operator of the NAT64-FE has full control over the firewall. The operator of the NAT64-FE has full control over the
IPv4 network within the data center, but only limited influence or IPv4 network within the data center but only limited influence or
control over the external Internet IPv6 network. control over the external Internet IPv6 network.
3. NAT64 Networking Experience 3. NAT64 Networking Experience
3.1. NAT64-CGN Consideration 3.1. NAT64-CGN Consideration
3.1.1. NAT64-CGN Usages 3.1.1. NAT64-CGN Usages
Fixed network operators and mobile operators may locate NAT64 Fixed network operators and mobile operators may locate NAT64
translators in access networks or in mobile core networks. It can be translators in access networks or in mobile core networks. NAT64 can
built into various devices, including routers, gateways or firewalls be built into various devices, including routers, gateways, or
in order to connect IPv6 users to the IPv4 Internet. With regard to firewalls, in order to connect IPv6 users to the IPv4 Internet. With
the numbers of users and the shortage of public IPv4 addresses, regard to the numbers of users and the shortage of public IPv4
stateful NAT64[RFC6146] is more suited to maximize sharing of public addresses, stateful NAT64 [RFC6146] is more suited to maximize
IPv4 addresses. The usage of stateless NAT64 can provide better sharing of public IPv4 addresses. The usage of stateless NAT64 can
transparency features [I-D.ietf-softwire-stateless-4v6-motivation], provide better transparency features [MOTIVATION], but it has to be
but has to be coordinated with A+P[RFC6346] processes as specified in coordinated with Address plus Port (A+P) processes [RFC6346] as
[I-D.ietf-softwire-map-t] in order to address an IPv4 address specified in [MAP-T] in order to deal with an IPv4 address shortage.
shortage.
3.1.2. DNS64 Deployment 3.1.2. DNS64 Deployment
DNS64[RFC6147] is recommended for use in combination with stateful DNS64 [RFC6147] is recommended for use in combination with stateful
NAT64, and will likely be an essential part of an IPv6 single-stack NAT64, and it will likely be an essential part of an IPv6 single-
network that couples to the IPv4 Internet. 464xlat[RFC6877] can stack network that couples to the IPv4 Internet. 464XLAT [RFC6877]
enable access of IPv4 only applications or applications that call can enable access of IPv4-only applications or applications that call
IPv4 literal addresses. Using DNS64 will help 464xlat to IPv4 literal addresses. Using DNS64 will help 464XLAT to
automatically discover NAT64 prefix through [RFC7050]. Berkeley automatically discover NAT64 prefixes through [RFC7050]. Berkeley
Internet Name Daemon (BIND) software supports the function. It's Internet Name Daemon (BIND) software supports that function. It's
important to note that DNS64 generates the synthetic AAAA reply when important to note that DNS64 generates the synthetic AAAA reply when
services only provide A records. Operators should not expect to services only provide A records. Operators should not expect to
access IPv4 parts of a dual-stack server using NAT64/DNS64. The access IPv4 parts of a dual-stack server using NAT64/DNS64. The
traffic is forwarded on IPv6 paths if dual-stack servers are traffic is forwarded on IPv6 paths if dual-stack servers are
targeted. IPv6 traffic may be routed around rather than going targeted. IPv6 traffic may be routed around rather than going
through NAT64. Only the traffic going to IPv4-only service would through NAT64. Only the traffic going to IPv4-only services would
traverse the NAT64 translator. In some sense, it encourages IPv6 traverse the NAT64 translator. In some sense, it encourages IPv6
usage and limits NAT translation compared to employing NAT44, where usage and limits NAT translation compared to employing NAT44, where
all traffic flows have to be translated. In some cases, NAT64-CGNs all traffic flows have to be translated. In some cases, NAT64-CGNs
may serve double roles, i.e. as a translator and IPv6 forwarder. In may serve double roles, i.e., as a translator and IPv6 forwarder. In
mobile networks, NAT64 may be deployed as the default gateway serving mobile networks, NAT64 may be deployed as the default gateway serving
all the IPv6 traffic. The traffic heading to a dual-stack server is all the IPv6 traffic. The traffic heading to a dual-stack server is
only forwarded on the NAT64. Therefore, both IPv6 and IPv4 are only forwarded on the NAT64. Therefore, both IPv6 and IPv4 are
suggested to be configured on the Internet faced interfaces of NAT64. suggested to be configured on the Internet-facing interfaces of
We tested on Top100 websites (referring to [Alexa] statistics). 43% NAT64. We tested on the top 100 websites (referring to [Alexa]
of websites are connected and forwarded on the NAT64 since those statistics). 43% of websites are connected and forwarded on NAT64
websites have both AAAA and A records. With expansion of IPv6 since those websites have both AAAA and A records. With expansion of
support, the translation process on NAT64 will likely become less- IPv6 support, the translation process on NAT64 will likely become
important over time. It should be noted the DNS64-DNSSEC less important over time. It should be noted that the DNS64-DNSSEC
Interaction[RFC6147] may impact validation of Resource Records interaction [RFC6147] may impact validation of Resource Records
retrieved from the the DNS64 process. In particular, DNSSEC retrieved from the DNS64 process. In particular, DNSSEC validation
validation will fail when DNS64 synthesizes AAAA records where there will fail when DNS64 synthesizes AAAA records where there is a DNS
is a DNS query with the "DNSSEC OK" (DO) bit set and the "Checking query received with the "DNSSEC OK" (DO) bit set and the "Checking
Disabled" (CD) bit set received. Disabled" (CD) bit set.
3.1.3. NAT64 Placement 3.1.3. NAT64 Placement
All connections to IPv4 services from IPv6-only clients must traverse All connections to IPv4 services from IPv6-only clients must traverse
the NAT64-CGN. It can be advantageous from the vantage-point of the NAT64-CGN. It can be advantageous from the viewpoint 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
translate packets only at or near the network egress. NAT64 may be a translate packets only at or near the network egress. NAT64 may be a
feature of the Autonomous System (AS) border in fixed networks. It feature of the Autonomous System (AS) border in fixed networks. It
may be deployed in an IP node beyond the Gateway GPRS Support Node may be deployed in an IP node beyond the Gateway GPRS Support Node
(GGSN) or Public Data Network- Gateway (PDN-GW) in mobile networks or (GGSN) or Packet Data Network Gateway (PDN-GW) in mobile networks or
directly as part of the gateway itself in some situations. This directly as part of the gateway itself in some situations. This
allows consistent attribution and traceability within the service allows consistent attribution and traceability within the service
provider network. It has been observed that the process of provider network. It has been observed that the process of
correlating log information is problematic from multiple-vendor's correlating log information is problematic from multiple vendors'
equipment due to inconsistent formats of log records. Placing NAT64 equipment due to inconsistent formats of log records. Placing NAT64
in a centralized location may reduce diversity of log format and in a centralized location may reduce diversity of log format and
simplify the network provisioning. Moreover, since NAT64 is only simplify the network provisioning. Moreover, since NAT64 is only
targeted at serving traffic flows from IPv6 to IPv4-only services, 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, the user traffic volume should not be as high as in a NAT44 scenario,
and therefore, the gateway's capacity in such location may be less of and therefore, the gateway's capacity in such a location may be less
a concern or a hurdle to deployment. On the other-hand, placement in of a concern or a hurdle to deployment. On the other hand, placement
a centralized fashion would require more strict high availability in a centralized fashion would require more strict high-availability
(HA) design. It would also make geo-location based on IPv4 addresses (HA) design. It would also make geolocation based on IPv4 addresses
rather inaccurate as is currently the case for NAT44 CGN already rather inaccurate as is currently the case for NAT44 CGNs already
deployed in ISP networks. More considerations or workarounds on HA deployed in ISP networks. More considerations or workarounds on HA
and traceability could be found at Section 4 and Section 5. and traceability can be found in Sections 4 and 5.
3.1.4. Co-existence of NAT64 and NAT44 3.1.4. Coexistence of NAT64 and NAT44
NAT64 will likely co-exist with NAT44 in a dual-stack network where NAT64 will likely coexist with NAT44 in a dual-stack network where
IPv4 private addresses are allocated to customers. The coexistence IPv4 private addresses are allocated to customers. The coexistence
has already been observed in mobile networks, in which dual stack has already been observed in mobile networks, in which dual-stack
mobile phones normally initiate some dual-stack PDN/PDP Type[RFC6459] mobile phones normally initiate some dual-stack PDN/PDP Type
to query both IPv4/IPv6 address and IPv4 allocated addresses are very [RFC6459] to query both IPv4/IPv6 addresses and IPv4-allocated
often private ones. [RFC6724] always prioritizes IPv6 connections addresses (which are very often private ones). [RFC6724] always
regardless of whether the end-to-end path is native IPv6 or IPv6 prioritizes IPv6 connections regardless of whether the end-to-end
translated to IPv4 via NAT64/DNS64. Conversely, Happy path is native IPv6 or IPv6 translated to IPv4 via NAT64/DNS64.
Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The Conversely, a "Happy Eyeballs" [RFC6555] algorithm will direct some
selection of IPv4/IPv6 paths may depend on particular implementation IP flows across IPv4 paths. The selection of IPv4/IPv6 paths may
choices or settings on a host-by-host basis, and may differ from an depend on particular implementation choices or settings on a host-by-
operator's deterministic scheme. Our tests verified that hosts may host basis, and it may differ from an operator's deterministic
find themselves switching between IPv4 and IPv6 paths as they access scheme. Our tests verified that hosts may find themselves switching
identical service, but at different times between IPv4 and IPv6 paths as they access identical services, but at
[I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each different times [COEXIST]. Since the topology on each path is
path is potentially different, it may cause unstable user experience potentially different, it may cause unstable user experience and some
and some degradation of Quality of Experience (QoE) when falling back degradation of Quality of Experience (QoE) when falling back to the
to the other protocol. It's also difficult for operators to find a other protocol. It's also difficult for operators to find a solution
solution to make a stable network with optimal resource utilization. to make a stable network with optimal resource utilization. In
In general, it's desirable to figure out the solution that will general, it's desirable to figure out the solution that will
introduce IPv6/IPv4 translation service to IPv6-only hosts connecting introduce IPv6/IPv4 translation service to IPv6-only hosts connecting
to IPv4 servers while making sure dual-stack hosts to have at least to IPv4 servers, while making sure dual-stack hosts have at least one
one address family accessible via native service if possible. With address family accessible via native service if possible. With the
the end-to-end native IPv6 environment available, hosts should be end-to-end native IPv6 environment available, hosts should be
upgraded aggressively to migrate in favor of IPv6-only. There are upgraded aggressively to migrate in favor of IPv6 only. There are
ongoing efforts to detect host connectivity and propose a new DHCPv6 ongoing efforts to detect host connectivity and propose a new DHCPv6
option[I-D.wing-dhc-dns-reconfigure] to convey appropriate option [CONN-STATUS] to convey appropriate configuration information
configuration information to the hosts. to the hosts.
3.2. NAT64-FE Consideration 3.2. NAT64-FE Consideration
Some Internet Content Providers (ICPs) may locate NAT64 in front of Some Internet Content Providers (ICPs) may locate NAT64 in front of
an Internet Data Center (IDC), for example co-located with a load an Internet Data Center (IDC), for example, co-located with a load-
-balancing function. Load-balancers are employed to connect balancing function. Load balancers are employed to connect different
different IP family domains, and distribute workloads across multiple IP family domains and distribute workloads across multiple domains or
domains or internal servers. In some cases, IPv4 addresses internal servers. In some cases, IPv4 address exhaustion may not be
exhaustion may not be a problem in some IDC's internal networks. a problem in an IDC's internal network. IPv6 support for some
IPv6 support for some applications may require some investments and applications may require increased investment and workload, so IPv6
workloads so IPv6 support may not be a priority. The use of NAT64 support may not be a priority. NAT64 can be used to support
may be served to support widespread IPv6 adoption on the Internet widespread IPv6 adoption on the Internet while maintaining access to
while maintaining IPv4-only applications access. IPv4-only applications.
Different strategy has been described in [RFC6883] referred to as Different strategies have been described in [RFC6883]; they are
"inside out" and "outside in". An IDC operator may implement the referred to as "inside out" and "outside in". An IDC operator may
following practices in the NAT64-FE networking scenario. implement the following practices in the NAT64-FE networking
scenario.
o Some ICPs who already have satisfactory operational experience o Some ICPs who already have satisfactory operational experience
might adopt single stack IPv6 operation in building data-center might adopt single-stack IPv6 operation in building data center
networks, servers and applications, as it allows new services networks, servers, and applications, as it allows new services to
delivery without having to integrate consideration of IPv4 NAT and be delivered without having to consider IPv4 NAT or the address
address limitations of IPv4 networks. Stateless NAT64[RFC6145] limitations of IPv4 networks. Stateless NAT64 [RFC6145] can used
can used to provide services for IPv4-only enabled customers. to provide services for IPv4-only customers. [SIIT] has provided
[I-D.anderson-siit-dc] has provided further descriptions and further descriptions and guidelines.
guidelines.
o ICPs who attempt to offer customers IPv6 support in their o ICPs who attempt to offer customers IPv6 support in their
application farms at an early stage may likely run proxies load- application farms at an early stage will likely run proxies, load
balancers or translators, which are configured to handle incoming balancers, or translators that are configured to handle incoming
IPv6 flows and proxy them to IPv4 back-end systems. Many load IPv6 flows and proxy them to IPv4 back-end systems. Many load
balancers integrate proxy functionality. IPv4 addresses balancers integrate proxy functionality. IPv4 addresses
configured in the proxy may be multiplexed like a stateful NAT64 configured in the proxy may be multiplexed like a stateful NAT64
translator. A similar challenge exists once increasingly numerous translator. A similar challenge exists as more users with IPv6
users in IPv6 Internet access an IPv4 network. High loads on connectivity access IPv4 networks. High loads on load balancers
load-balancers may be apt to cause additional latency, IPv4 pool may be apt to cause additional latency, IPv4 pool exhaustion, etc.
exhaustion, etc. Therefore, this approach is only reasonable at Therefore, this approach is only reasonable at an early stage.
an early stage. ICPs may employ dual-stack or IPv6 single stack ICPs may employ dual stack or IPv6 single stack in a further
in a further stage, since the native IPv6 is frequently more stage, since native IPv6 is frequently more desirable than any of
desirable than any of the transition solutions. the transition solutions.
[RFC6144] recommends that AAAA records of load-balancers or [RFC6144] recommends that AAAA records of load balancers or
application servers can be directly registered in the authoritative application servers can be directly registered in the authoritative
DNS servers. In this case, there is no need to deploy DNS64 name- DNS servers. In this case, there is no need to deploy DNS64 name
servers. Those AAAA records can point to natively assigned IPv6 servers. Those AAAA records can point to natively assigned IPv6
addresses or IPv4-converted IPv6 addresses[RFC6052]. Hosts are not addresses or IPv4-converted IPv6 addresses [RFC6052]. Hosts are not
aware of the NAT64 translator on communication path. For the testing aware of the NAT64 translator on the communication path. For testing
purpose, operators could employ an independent sub domain e.g. purposes, operators could employ an independent subdomain, e.g.,
ipv6exp.example.com to identify experimental ipv6 services to users. ipv6exp.example.com, to identify experimental IPv6 services to users.
How to design the FQDN for the IPv6 service is out-of-scope of this How to design the Fully Qualified Domain Name (FQDN) for the IPv6
document. service is outside the scope of this document.
4. High Availability 4. High Availability
4.1. Redundancy Design 4.1. Redundancy Design
High Availability (HA) is a major requirement for every service and High Availability (HA) is a major requirement for every service and
network services. The deployment of redundancy mechanisms is an network service. Deploying redundancy mechanisms is essential to
essential approach to avoid failure and significantly increase the avoiding failure and significantly increasing the network
network reliability. It's not only useful to stateful NAT64 cases, reliability. It's useful not only to stateful NAT64 cases but also
but also to stateless NAT64 gateways. to stateless NAT64 gateways.
Three redundancy modes are mainly used: cold standby, warm standby Three redundancy modes are mainly used: Cold Standby, Warm Standby,
and hot standby. and Hot Standby.
o Cold standby HA devices do not replicate the NAT64 states from the o Cold Standby HA devices do not replicate the NAT64 states from the
primary equipment to the backup. Administrators switch on the primary equipment to the backup. Administrators switch on the
backup NAT64 only if the primary NAT64 fails. As a result, all backup NAT64 only if the primary NAT64 fails. As a result, all
existing established sessions through a failed translator will be existing established sessions through a failed translator will be
disconnected. The translated flows will need to be recreated by disconnected. The translated flows will need to be recreated by
end-systems. Since the backup NAT64 is manually configured to end systems. Since the backup NAT64 is manually configured to
switch over to active NAT64, it may have unpredictable impacts to switch over to active NAT64, it may have unpredictable impacts to
the ongoing services. the ongoing services.
o Warm standby is a flavor of the cold standby mode. Backup NAT64 o Warm Standby is a flavor of the Cold Standby mode. Backup NAT64
would keep running once the primary NAT64 is working. This makes would keep running once the primary NAT64 is working. This makes
warm standby less time consuming during the traffic failover. Warm Standby less time-consuming during the traffic failover. The
Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a
solution to enable automatic handover in the warm standby. It was solution to enable automatic handover during Warm Standby. During
tested that the handover takes as maximum as 1 minute if the testing, the handover took a maximum of 1 minute if the backup
backup NAT64 needs to take over routing and re-construct the NAT64 had to take over routing and reconstruct the Binding
Binding Information Bases (BIBs) for 30 million sessions. In Information Bases (BIBs) for 30 million sessions. In the
deployment phase, operators could balance loads on distinct NAT64s deployment phase, operators could balance loads on distinct NAT64
devices. Those NAT64s make a warm backup of each other. devices. Those NAT64 devices make a warm backup of each other.
o Hot standby must synchronize the BIBs between the primary NAT64 o Hot Standby must synchronize the BIBs between the primary NAT64
and backup. When the primary NAT64 fails, backup NAT64 would take and backup. When the primary NAT64 fails, the backup NAT64 takes
over and maintain the state of all existing sessions. The over and maintains the state of all existing sessions. The
internal hosts don't have to re-connect the external hosts. The internal hosts don't have to reconnect the external hosts. The
handover time has been extremely reduced. Employing Bidirectional handover time is extremely reduced. During testing that employed
Forwarding Detection (BFD) [RFC5880] combined with VRRP, a delay Bidirectional Forwarding Detection (BFD) [RFC5880] combined with
of only 35ms for 30 million sessions handover was observed during VRRP, a handover time of only 35 ms for 30 million sessions was
testing. Under ideal conditions hotstandby deployments could observed. Under ideal conditions, Hot Standby deployments could
guarantee the session continuity for every service. In order to guarantee the session continuity for every service. In order to
timely transmit session states, operators may have to deploy extra transmit session states in a timely manner, operators may have to
transport links between primary NAT64 and distant backup. The deploy extra transport links between the primary NAT64 and the
scale of synchronization data instance is depending on the distant backup. The scale of synchronization of the data instance
particular deployment. For example, If a NAT64-CGN is served for depends on the particular deployment. For example, if a NAT64-CGN
200,000 users, the average amount of 800, 000 sessions per second serves 200,000 users, an average amount of 800,000 sessions per
is roughly estimated for new created and expired sessions. A second is a rough estimate of the newly created and expired
physical 10Gbps transport link may have to be deployed for the sessions. A physical 10 Gbit/s transport link may have to be
sync data transmission considering the amount of sync sessions at deployed for the sync data transmission considering the amount of
the peak and capacity redundancy sync sessions at the peak and the capacity redundancy.
In general, cold-standby and warm-standby is simpler and less In general, Cold Standby and Warm Standby are simpler and less
resource intensive, but it requires clients to re-establish sessions resource intensive, but they require clients to re-establish sessions
when a fail-over occurs. Hot standby increases resource consumption when a failover occurs. Hot Standby increases resource consumption
in order to synchronize state, but potentially achieves seamless in order to synchronize state, but it potentially achieves seamless
handover. For stateless NAT64 considerations are simple, because handover. For stateless NAT64, considerations are simple because
state synchronization is unnecessary. Regarding stateful NAT64, it state synchronization is unnecessary. Regarding stateful NAT64, it
may be useful to investigate performance tolerance of applications may be useful to investigate the performance tolerance of
and the traffic characteristics in a particular network. Some applications and the traffic characteristics in a particular network.
testing results are shown in the Appendix A. Some test results are shown in the Appendix A.
Our statistics in a mobile network shown that almost 91.21% of of Our statistics in a mobile network shown that almost 91.21% of
traffic is accounted by http/https services. These services traffic is accounted by HTTP/HTTPS services. These services
generally don't require session continuity. Hot-standby does not generally don't require session continuity. Hot Standby does not
offer much benefit for those sessions on this point. In fixed offer much benefit for those sessions on this point. In fixed
networks, HTTP streaming, p2p and online games would be the major networks, HTTP streaming, P2P, and online games would be the major
traffic beneficiaries of hot-standby replication[Cisco-VNI]. traffic beneficiaries of Hot Standby replication [Cisco-VNI].
Consideration should be given to the importance of maintaining Consideration should be given to the importance of maintaining
bindings for those sessions across failover. Operators may also bindings for those sessions across failover. Operators may also
consider the Average Revenue Per User (ARPU) factors to deploy consider the Average Revenue Per User (ARPU) when deploying a
suitable redundancy mode. Warm standby may still be adopted to cover suitable redundancy mode. Warm Standby may still be adopted to cover
most services while hot standby could be used to upgrade Quality of most services, while Hot Standby could be used to upgrade the Quality
Experience (QoE) using DNS64 to generate different synthetic of Experience (QoE) and using DNS64 to generate different synthetic
responses for limited traffic or destinations. Further responses for limited traffic or destinations. Further
considerations are discussed at Section 6. considerations are discussed at Section 6.
4.2. Load Balancing 4.2. Load Balancing
Load balancing is used to accompany redundancy design so that better Load balancing is used to accompany redundancy design so that better
scalability and resiliency could be achieved. Stateless NAT64s allow scalability and resiliency can be achieved. Stateless NAT64s allow
asymmetric routing while anycast-based solutions are recommended in asymmetric routing, while anycast-based solutions are recommended in
[I-D.ietf-softwire-map-deployment]. The deployment of load balancing [MAP-DEPLOY]. The deployment of load balancing may make more sense
may make more sense to stateful NAT64s for the sake of single-point to stateful NAT64s for the sake of avoiding single-point failures.
failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct Since the NAT64-CGN and NAT64-FE have distinct facilities, the
facilities, the following lists the considerations for each case. following lists the considerations for each case.
o NAT64-CGN equipment doesn't typically implement load-balancing o NAT64-CGN normally doesn't implement load-balancing functions;
functions onboard. Therefore, the gateways have to resort to they may be implemented in other dedicated equipment. Therefore,
DNS64 or internal host's behavior. Once DNS64 is deployed, the the gateways have to resort to DNS64 or an internal host's
load balancing can be performed by synthesizing AAAA response with behavior. Once DNS64 is deployed, the load balancing can be
different IPv6 prefixes. For the applications not requiring DNS performed by synthesizing the AAAA response with different IPv6
resolver, internal hosts could learn multiple IPv6 prefixes prefixes. For the applications not requiring a DNS resolver,
through the approaches defined in[RFC7050] and then select one internal hosts could learn multiple IPv6 prefixes through the
based on a given prefix selection policy. approaches defined in [RFC7050] and then select one based on a
given prefix selection policy.
o A dedicated Load Balancer could be deployed at front of a NAT64-FE o A dedicated load balancer could be deployed at the front of a
farm. Load Balancer uses proxy mode to redirect the flows to the NAT64-FE farm. The load balancer could use proxy mode to redirect
appropriate NAT64 instance. Stateful NAT64s require a the flows to the appropriate NAT64 instance. Stateful NAT64s
deterministic pattern to arrange the traffic in order to ensure require a deterministic pattern to arrange the traffic in order to
outbound/inbound flows traverse the identical NAT64. Therefore, ensure outbound/inbound flows traverse the identical NAT64.
static scheduling algorithms, for example source-address based Therefore, static scheduling algorithms, for example, a source-
policy, is preferred. A dynamic algorithm, for example Round- address-based policy, is preferred. A dynamic algorithm, for
Robin, may have impacts on applications seeking session example, Round-Robin, may have impacts on applications seeking
continuity, which described in the Table 1. session continuity, which are described in Table 1.
5. Source Address Transparency 5. Source-Address Transparency
5.1. Traceability 5.1. Traceability
Traceability is required in many cases such as identifying malicious Traceability is required in many cases, such as meeting accounting
attacks sources and accounting requirements. Operators are asked to requirements and identifying the sources of malicious attacks.
record the NAT64 log information for specific periods of time. In Operators are asked to record the NAT64 log information for specific
our lab testing, the log information from 200,000 subscribers have periods of time. In our lab testing, the log information from
been collected from a stateful NAT64 gateway for 60 days. 200,000 subscribers was collected from a stateful NAT64 gateway for
Syslog[RFC5424] has been adopted to transmit log message from NAT64 60 days. Syslog [RFC5424] has been adopted to transmit log messages
to a log station. Each log message contains transport protocol, from NAT64 to a log station. Each log message contains the transport
source IPv6 address:port, translated IPv4 address: port and protocol, source IPv6 address:port, translated IPv4 address:port, and
timestamp. It takes almost 125 bytes in ASCII format. It has been timestamp. It takes almost 125 bytes in ASCII format. It has been
verified that the rate of traffic flow is around 72 thousand flows verified that the rate of traffic flow is around 72,000 flows per
per second and the volume of recorded information reaches up to 42.5 second, and the volume of recorded information reaches up to 42.5
terabytes in the raw format. The volume is 29.07 terabytes in a terabytes in the raw format. The volume is 29.07 terabytes in a
compact format. At scale, operators have to build up dedicated compact format. At scale, operators have to build up dedicated
transport links, storage system and servers for the purpose of transport links, storage systems, and servers for the purpose of
managing such logging. managing such logging.
There are also several improvements that can be made to mitigate the There are also several improvements that can be made to mitigate the
issue. For example, stateful NAT64 could configure with bulk port issue. For example, stateful NAT64 could be configured with the bulk
allocation method. Once a subscriber creates the first session, a port allocation method. Once a subscriber creates the first session,
number of ports are pre-allocated. A bulk allocation message is a number of ports are pre-allocated. A bulk allocation message is
logged indicating this allocation. Subsequent session creations will logged indicating this allocation. Subsequent session creations will
use one of the pre-allocated port and hence does not require logging. use one of the pre-allocated ports and hence do not require logging.
The log volume in this case may be only one thousandth of dynamic The log volume in this case may be only one thousandth of that of
port allocation. Some implementations may adopt static port-range dynamic port allocation. Some implementations may adopt static port-
allocations [I-D.donley-behave-deterministic-cgn] which eliminates range allocations [DET-CGN] that eliminate the need for per-
the need for per-subscriber logging. As a side effect, the IPv4 subscriber logging. As a side effect of those methods, the IPv4
multiplexing efficiency is decreased regarding to those methods. For multiplexing efficiency is decreased. For example, the utilization
example, the utilization ratio of public IPv4 address is dropped ratio of public IPv4 addresses drops to approximately 75% when the
approximately to 75% when NAT64 gateway is configured with bulk port NAT64 gateway is configured with bulk port allocation. (The lab
allocation (The lab testing allocates each subscriber with 400 testing allocates each subscriber with 400 ports.) In addition,
ports). In addition, port-range based allocation should also port-range-based allocation should consider port randomization as
consider port randomization described in [RFC6056] . A trade-off described in [RFC6056]. The trade-off among address multiplexing
among address multiplexing efficiency, logging storage compression efficiency, logging storage compression, and port allocation
and port allocation complexity should be considered. More complexity should be considered. More discussions can be found in
discussions could be found in [I-D.chen-sunset4-cgn-port-allocation]. [PORT-ALLOC]. The decision can balance usable IPv4 resources against
The decision can balance usable IPv4 resources against investments in investments in log systems.
log systems.
5.2. Geo-location 5.2. Geolocation
IP addresses are usually used as inputs to geo-location services. IP addresses are usually used as inputs to geolocation services. The
The use of address sharing prevents these systems from resolving the use of address sharing prevents 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 in [RFC6967] are intended to bridge the possible solutions listed in [RFC6967] are intended to bridge the
gap. However, those solutions can only provide a sub-optimal gap. However, those solutions can only provide a suboptimal
substitution to solve the problem of host identification, in substitution to solve the problem of host identification; in
particular it may not today solve problems with source identification particular, it may not solve today's problems with source
through translation. The following lists current practices to identification through translation. The following lists current
mitigate the issue. practices to mitigate the issue.
o Operators who adopt NAT64-FE may leverage the application layer o Operators who adopt NAT64-FE may leverage the application-layer
proxies, e.g. X-Forwarded-For (XFF) proxies, e.g., X-Forwarded-For (XFF) [RFC7239], to convey the IPv6
[I-D.ietf-appsawg-http-forwarded], to convey the IPv6 source source address in HTTP headers. Those messages would be passed on
address in HTTP headers. Those messages would be passed on to to web servers. The log parsing tools are required to be able to
web-servers. The log parsing tools are required to be able to support IPv6 and may lookup RADIUS servers for the target
support IPv6 and may lookup Radius servers for the target
subscribers based on IPv6 addresses included in XFF HTTP headers. subscribers based on IPv6 addresses included in XFF HTTP headers.
XFF is the de facto standard which has been integrated in most XFF is the de facto standard that has been integrated in most load
Load Balancers. Therefore, it may be superior to use in a NAT-FE balancers. Therefore, it may be superior to use in a NAT-FE
environment. In the downsides, XFF is specific to HTTP. It environment. On the downside, XFF is specific to HTTP. It
restricts the usages so that the solution can't be applied to restricts usage so that the solution can't be applied to requests
requests made over HTTPs. This makes geo-location problematic for made over HTTPS. This makes geolocation problematic for HTTPS-
HTTPs based services. based services.
o The NAT64-CGN equipment may not implement XFF. Geo-location based o The NAT64-CGN equipment may not implement XFF. Geolocation based
on shared IPv4 address is rather inaccurate in that case. on shared IPv4 addresses is rather inaccurate in that case.
Operators could subdivide the outside IPv4 address pool so an IPv6 Operators could subdivide the outside IPv4 address pool so an IPv6
address can be translated depending on their geographical address can be translated depending on the IPv6 subscriber's
locations. As consequence, location information can be identified geographical locations. As a consequence, location information
from a certain IPv4 address range. [RFC6967] also enumerates can be identified from a certain IPv4 address range. [RFC6967]
several options to reveal the host identifier. Each solution also enumerates several options to reveal the host identifier.
likely has their-own specific usage. For the geo-location systems Each solution likely has its own specific usage. For the
relying on a Radius database[RFC5580], we have investigated to geolocation systems relying on a RADIUS database [RFC5580], we
deliver NAT64 BIBs and Session Table Entries (STEs) to a Radius have investigated delivering NAT64 BIBs and Session Table Entries
server[I-D.chen-behave-nat64-radius-extension]. This method could (STEs) to a RADIUS server [NAT64-RADIUS]. This method could
provide geo-location system with an internal IPv6 address to provide a geolocation system with an internal IPv6 address to
identify each user. It can get along with [RFC5580] to convey identify each user. It can be paired with [RFC5580] to convey the
original source address through same message bus. original source address through the same message bus.
6. Quality of Experience 6. Quality of Experience
6.1. Service Reachability 6.1. Service Reachability
NAT64 is providing a translation capability between IPv6 and IPv4 NAT64 is providing a translation capability between IPv6 and IPv4 end
end-nodes. In order to provide the reachability between two IP nodes. In order to provide reachability between two IP address
address families, NAT64-CGN has to implement appropriate application families, NAT64-CGN has to implement appropriate application-aware
aware functions, i.e. Application Layer Gateway (ALG), where address functions, i.e., Application Layer Gateways (ALGs), where address
translation is not itself sufficient and security mechanisms do not translation is not sufficient and security mechanisms do not render
render it infeasible. Most NAT64-CGNs mainly provide FTP- the functions infeasible. Most NAT64-CGNs mainly provide FTP-ALG
ALG[RFC6384]. NAT64-FEs may have functional richness on Load [RFC6384]. NAT64-FEs may have functional richness on the load
Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have balancer; for example, HTTP-ALG, HTTPS-ALG, RTSP-ALG, and SMTP-ALG
been supported. Those application protocols exchange IP address and have been supported. Those application protocols exchange IP address
port parameters within control session, for example the "Via" filed and port parameters within a control session, for example, using the
in a HTTP header, "Transport" field in a RTSP SETUP message and "Via" field in a HTTP header, "Transport" field in an RTSP SETUP
"Received: " header in a SMTP message. ALG functions will detect message, or "Received:" header in a SMTP message. ALG functions will
those fields and make IP address translations. It should be noted detect those fields and make IP address translations. It should be
that ALGs may impact the performance on a NAT64 box to some extent. noted that ALGs may impact the performance on a NAT64 box to some
ISPs as well as content providers might choose to avoid situations extent. ISPs as well as content providers might choose to avoid
where the imposition of an ALG might be required. At the same time, situations where the imposition of an ALG might be required. At the
it is also important to remind customers and application developers same time, it is also important to remind customers and application
that IPv6 end-to-end usage does not require ALG imposition and developers that IPv6 end-to-end usage does not require ALG imposition
therefore results in a better overall user experience. and therefore results in a better overall user experience.
The service reachability is also subject to the IPv6 support in the The service reachability is also subject to the IPv6 support in the
client side. We tested several kinds of applications as shown in the client side. We tested several kinds of applications as shown in the
below table to verify the IPv6 supports. The experiences of some below table to verify the IPv6 support. The experiences of some
applications are still align with [RFC6586]. For example, we have applications are still aligned with [RFC6586]. For example, we
tested P2P file sharing and streaming applications including eMule tested P2P file sharing and streaming applications including eMule
v0.50a, Thunder v7.9 and PPS TV v3.2.0. It has been found there are v0.50a, Thunder v7.9, and PPS TV v3.2.0. It has been found there are
some software issues to support IPv6 at this time. The application some software issues with the support of IPv6 at this time. The
software would benefit from 464xlat[RFC6877] until the software adds application software would benefit from 464XLAT [RFC6877] until the
IPv6 support.. A SIP based voice call has been tested in LTE mobile software adds IPv6 support. A SIP-based voice call has been tested
environment as specified in [IR.92]. The voice call is failed due to in the LTE mobile environment as specified in [IR.92]. The voice
the lack of NAT64 traversal when an IPv6 SIP user agent communicates call failed due to the lack of NAT64 traversal when an IPv6 SIP user
with an IPv4 SIP user agent. In order to address the failure, agent communicates with an IPv4 SIP user agent. In order to address
Interactive Connectivity Establishment (ICE) described in [RFC5245] the failure, Interactive Connectivity Establishment (ICE) as
is recommended to be supported for the SIP IPv6 transition. described in [RFC5245] is recommended to be supported for the SIP
[RFC6157] describes both signaling and media layer process, which IPv6 transition. [RFC6157] describes both signaling and the media-
should be followed. In addition, it may be worth to notice that ICE layer process, which should be followed. In addition, it is worth
is not only useful for NAT traversal, but also firewall[RFC6092] noting that ICE is not only useful for NAT traversal, but also for
traversal in native IPv6 deployment. firewall [RFC6092] traversal in a native IPv6 deployment.
Different IPsec modes for VPN services have been tested, including Different IPsec modes for VPN services have been tested, including
IPsec-AH and IPsec-ESP. It has been testified IPsec-AH can't survive IPsec Authentication Header (AH) and IPsec Encapsulating Security
since the destination host detects the IP header changes and Payload (ESP). It has been shown that IPsec AH fails because the
invalidate the packets. IPsec-ESP failed in our testing because the destination host detects the IP header changes and invalidates the
NAT64 does not translate IPsec ESP (i.e. protocol 50) packets. It packets. IPsec ESP failed in our testing because the NAT64 does not
has been suggested that IPsec ESP should succeed if the IPSec client translate IPsec ESP (i.e., protocol 50) packets. It has been
supports NAT-Traversal in the IKE[RFC3947] and uses IPsec ESP over suggested that IPsec ESP would succeed if the IPsec client supports
UDP[RFC3948]. NAT traversal in the Internet Key Exchange Protocol (IKE) [RFC3947]
and uses IPsec ESP over UDP [RFC3948].
Table 1: The tested applications Table 1: The Tested Applications
+----------------+----------------------------------------------------+
| APPs | Results and Found Issues |. +----------------+----------------------------------------------------+
+----------------+----------------------------------------------------+ | Application | Results and Issues Found |
| Webservice |Mostly pass, some failure cases due to IPv4 Literals| +----------------+----------------------------------------------------+
+----------------+----------------------------------------------------+ | Web service | Mostly pass; some failures due to IPv4 literals |
|Instant Message |Mostly fail, software can't support IPv6 | +----------------+----------------------------------------------------+
+----------------+----------------------------------------------------+ |Instant Message | Mostly fail; software can't support IPv6 |
| Games |Mostly pass for web-based games; mostly fail for | +----------------+----------------------------------------------------+
| |standalone games due to the lack of IPv6 support in | | Games | Mostly pass for web-based games; mostly fail for |
| |software | | | standalone games due to the lack of IPv6 support |
+----------------+----------------------------------------------------+ | | in software |
| SIP-VoIP |Fail, due to the lack of NAT64 traversal | +----------------+----------------------------------------------------+
+----------------+----------------------------------------------------+ | SIP VoIP | Fail, due to the lack of NAT64 traversal |
| IPsec-VPN |Fail, the translated IPsec packets are invalidated | +----------------+----------------------------------------------------+
+----------------+----------------------------------------------------+ | IPsec VPN | Fail; the translated IPsec packets are invalidated |
|P2P file sharing|Mostly fail, software can't support IPv6, e.g. eMule| +----------------+----------------------------------------------------+
|and streaming |Thunder and PPS TV | |P2P file sharing| Mostly fail; software can't support IPv6, |
+----------------+----------------------------------------------------+ |and streaming | e.g., eMule, Thunder, and PPS TV |
| FTP |Pass | +----------------+----------------------------------------------------+
+----------------+----------------------------------------------------+ | FTP | Pass |
| Email |Pass | +----------------+----------------------------------------------------+
+----------------+----------------------------------------------------+ | Email | Pass |
+----------------+----------------------------------------------------+
6.2. Resource Reservation 6.2. Resource Reservation
Session status normally is managed by a static timer. For example, Session status normally is managed by a static timer. For example,
the value of the "established connection idle-timeout" for TCP the value of the "established connection idle-timeout" must not be
sessions must not be less than 2 hours 4 minutes[RFC5382] and 5 less than 2 hours 4 minutes [RFC5382] for TCP sessions and 5 minutes
minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe for UDP sessions [RFC4787]. In some cases, NAT resources may be
significantly consumed by largely inactive users. The NAT translator significantly consumed by largely inactive users. The NAT and other
and other customers would suffer from service degradation due to port customers would suffer from service degradation due to port
consummation by other subscribers using the same NAT64 device. A consumption by other subscribers using the same NAT64 device. A
flexible NAT session control is desirable to resolve the issues. flexible NAT session control is desirable to resolve these issues.
PCP[RFC6887] could be a candidate to provide such capability. A The Port Control Protocol (PCP) [RFC6887] could be a candidate to
NAT64-CGN should integrate with a PCP server, to allocate available provide such capability. A NAT64-CGN should integrate with a PCP
IPv4 address/port resources. Resources could be assigned to PCP server to allocate available IPv4 address/port resources. Resources
clients through PCP MAP/PEER mode. Such ability can be considered to could be assigned to PCP clients through PCP MAP/PEER mode. Doing so
upgrade user experiences, for example assigning different sizes of might improve user experiences, for example, by assigning different
port ranges for different subscribers. Those mechanisms are also sizes of port ranges for different subscribers. Those mechanisms are
helpful to minimize terminal battery consumption and reduce the also helpful to minimize terminal battery consumption and reduce the
number of keep-alive messages to be sent by mobile terminal devices. number of keep-alive messages sent by mobile terminal devices.
Subscribers can also benefit from network reliability. It has been Subscribers can also benefit from network reliability. It has been
discussed that hot-standby offers satisfactory experience once outage discussed that Hot Standby offers a satisfactory experience after
of primary NAT64 is occurred. Operators may rightly be concerned outage of the primary NAT64 has occurred. Operators may rightly be
about the considerable investment required for NAT64 equipment concerned about the considerable investment required for NAT64
relative to low ARPU income. For example, transport links may cost equipment relative to low ARPU. For example, transport links may be
much, because primary NAT64 and backup are normally located at expensive, because the primary NAT64 and the backup are normally
different locations, separated by a relatively large distance. located at different locations, separated by a relatively large
Additional cost has to be assumed to ensure the connectivity quality. distance. Additional cost would be incurred to ensure the
However, that may be necessary to some applications, which are delay- connectivity quality. However, that may be necessary to applications
sensitive and seek session continuity, for example on-line games and that are delay-sensitive and seek session continuity, for example,
live-streaming. Operators may be able to get added-values from those online games and live streaming. Operators may be able to get added
services by offering first-class services. It can be pre-configured value from those services by offering first-class services. The
on the gateway to hot-standby modes depending on subscriber's service sessions can be pre-configured on the gateway to Hot Standby
profile. The rest of other sessions can be covered by cold/warm mode depending on the subscriber's profile. The rest of the sessions
standby. can be covered by Cold or Warm Standby.
7. MTU Considerations 7. MTU Considerations
IPv6 requires that every link in the internet have an Maximum IPv6 requires that every link in the Internet have a Maximum
Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. However, Transmission Unit (MTU) of 1280 octets or greater [RFC2460].
in case of NAT64 translation deployment, some IPv4 MTU constrained However, if NAT64 translation is deployed, some IPv4 MTU constrained
link will be used in some communication path and originating IPv6 link will be used in a communication path and the originating IPv6
nodes may therefore receive an ICMP Packet Too Big (PTB) message, nodes may therefore receive an ICMP Packet Too Big (PTB) message,
reporting a Next-Hop MTU less than 1280 bytes. The result would be reporting a Next-Hop MTU less than 1280 bytes. The result would be
that IPv6 allows packets to contain a fragmentation header, without that IPv6 allows packets to contain a fragmentation header, without
the packet being fragmented into multiple pieces. A NAT64 would the packet being fragmented into multiple pieces. A NAT64 would
receive IPv6 packets with fragmentation header in which "M" flag receive IPv6 packets with a fragmentation header in which the "M"
equal to 0 and "Fragment Offset" equal to 0. Those packets likely flag is set to 0 and the "Fragment Offset" is set to 0. Those
impact other fragments already queued with the same set of {IPv6 packets likely impact other fragments already queued with the same
Source Address, IPv6 Destination Address, Fragment Identification}. set of {IPv6 Source Address, IPv6 Destination Address, Fragment
If the NAT64 box is compliant with [RFC5722], there is risk that all Identification}. If the NAT64 box is compliant with [RFC5722], there
the fragments have to be dropped. is a risk that all the fragments will have to be dropped.
[RFC6946] discusses how this situation could be exploited by an [RFC6946] discusses how this situation could be exploited by an
attacker to perform fragmentation-based attacks, and also proposes an attacker to perform fragmentation-based attacks and also proposes
improved handling of such packets. It required enhancements on NAT64 improved handling of such packets. It requires enhancements on NAT64
gateway implementations to isolate packet's processing. NAT64 should gateway implementations to isolate the processing of packets. NAT64
follow the recommendation and take steps to prevent the risks of devices should follow the recommendations and take steps to prevent
fragmentation. the risks of fragmentation.
Another approach that potentially avoids this issue is to configure Another approach that potentially avoids this issue is to configure
IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB the IPv4 MTU to more than 1260 bytes. This would prevent getting a
smaller than 1280 bytes. Such an operational consideration is hard PTB message for an MTU smaller than 1280 bytes. Such an operational
to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged. consideration is hard to universally apply to the legacy "IPv4
However, it's a feasible approach in NAT64-FE cases, since a IPv4 Internet" that is bridged by NAT64-CGNs. However, it's a feasible
network NAT64-FE connected is rather well-organized and operated by a approach in NAT64-FE cases, since an IPv4 network NAT64-FE is rather
IDC operator or content provider. Therefore, the MTU of IPv4 network well-organized and operated by an IDC operator or content provider.
in NAT64-FE case are strongly recommended to set to more than 1260 Therefore, the MTU of an IPv4 network in NAT64-FE case is strongly
bytes. recommended to be set to more than 1260 bytes.
8. ULA Usages 8. ULA Usages
Unique Local Addresses (ULAs) are defined in [RFC4193] to be Unique Local Addresses (ULAs) are defined in [RFC4193] to be
renumbered within a network site for local communications. Operators renumbered within a network site for local communications. Operators
may use ULAs as NAT64 prefixes to provide site-local IPv6 may use ULAs as NAT64 prefixes to provide site-local IPv6
connectivity. Those ULA prefixes are stripped when the packets going connectivity. Those ULA prefixes are stripped when the packets go to
to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site. the IPv4 Internet; therefore, ULAs are only valid in the IPv6 site.
The use of ULAs could help in identifying the translation The use of ULAs could help in identifying the translation traffic.
traffic.[I-D.ietf-v6ops-ula-usage-recommendations] provides further [ULA-USAGE] provides further guidance on using ULAs.
guidance for the ULAs usages.
We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is
only assigned with an IPv6 address and connected to NAT64-CGN, when assigned with only an IPv6 address and connected to a NAT64-CGN, when
connect to an IPv4 service, it would receive AAAA record generated by it connects to an IPv4 service, it would receive a AAAA record
the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will generated by the DNS64 with the ULA prefix. A Global Unicast Address
be selected as the source address to the ULA destination address. (GUA) will be selected as the source address to the ULA destination
When the host has both IPv4 and IPv6 address, it would initiate both address. When the host has both IPv4 and IPv6 addresses, it would
A and AAAA record lookup, then both original A record and initiate both A and AAAA record lookup, then both the original A
DNS64-generated AAAA record would be received. A host, which is record and DNS64-generated AAAA record would be received. A host
compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4 that is compliant with [RFC6724] will never prefer a ULA over an IPv4
path will be always selected. It may be undesirable because the address. An IPv4 path will always be selected. It may be
NAT64-CGN will never be used. Operators may consider to add undesirable because the NAT64-CGN will never be used. Operators may
additional site-specific rows into the default policy table for host consider adding additional site-specific rows into the default policy
address selection in order to steer traffic flows going through table for host address selection in order to steer traffic flows
NAT64-CGN. However, it involves significant costs to change through the NAT64-CGN. However, it involves significant costs to
terminal's behavior. Therefore, operators are not suggested to change a terminal's behavior. Therefore, it is not suggested that
configure ULAs on a NAT64-CGN. operators configure ULAs on a NAT64-CGN.
ULAs can't work when hosts transit the Internet to connect with ULAs can't work when hosts transit the Internet to connect with
NAT64. Therefore, ULAs are inapplicable to the case of NAT64-FE. NAT64. Therefore, ULAs are not applicable to the case of NAT64-FE.
9. Security Considerations 9. Security Considerations
This document presents the deployment experiences of NAT64 in CGN and This document presents the deployment experiences of NAT64 in CGN and
FE scenarios. In general, RFC 6146[RFC6146] provides TCP-tracking, FE scenarios. In general, RFC 6146 [RFC6146] provides TCP-tracking,
address-dependent filtering mechanisms to protect NAT64 from address-dependent filtering mechanisms to protect NAT64 from
Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators
also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and could also adopt unicast Reverse Path Forwarding (uRPF) [RFC3704] and
black/white-list to enhance the security by specifying access blacklisting and whitelisting to enhance security by specifying
policies. For example, NAT64-CGN should forbid establish NAT64 BIB access policies. For example, NAT64-CGN should forbid establishing
for incoming IPv6 packets if uRPF in Strict or Loose mode check does NAT64 BIB for incoming IPv6 packets if they do not pass the uRPF
not pass or whose source IPv6 address is associated to black-lists. check in Strict or Loose mode or if their source IPv6 address is
blacklisted.
The stateful NAT64-FE creates state and maps that connection to an 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. Load Balancer is recommended to NAT64-FE is exposed to attacks. The load balancer is recommended to
enable the capabilities of line rate DDOS defense, such as the enable the capabilities for line-rate DDOS defense, such as the
employment of SYN PROXY-COOKIE. Security domain division is employment of SYN proxy/cookie. In this case, division of the
necessary as well in this case. Therefore, Load Balancers could not security domain is necessary as well. Therefore, load balancers
only serve for optimization of traffic distribution, but also prevent could not only optimize the traffic distribution but also prevent
service from quality deterioration due to security attacks. service from quality deterioration due to security attacks.
The DNS64 process will potentially interfere with the DNSSEC The DNS64 process will potentially interfere with the DNSSEC
functions[RFC4035], since DNS response is modified and DNSSEC intends functions [RFC4035], since the DNS response is modified and DNSSEC
to prevent such changes. More detailed discussions can be found in intends to prevent such changes. More detailed discussions can be
[RFC6147]. found in [RFC6147].
10. IANA Considerations
This memo includes no request to IANA.
11. 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, Iljitsch van Beijnum, Philip Matthews, Randy Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy
Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley, Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley,
Tim Chown, Gert Doering and Simon Perreault for their helpful Tim Chown, Gert Doering, and Simon Perreault for their helpful
comments. comments.
Many thanks to Wesley George, Lee Howard and Satoru Matsushima for Many thanks to Wesley George, Lee Howard, and Satoru Matsushima for
their detailed reviews. their detailed reviews.
The authors especially thank Joel Jaeggli and Ray Hunter for his The authors especially thank Joel Jaeggli and Ray Hunter for their
efforts and contributions on editing which substantially improves the efforts and contributions on editing, which substantially improved
legibility of the document. the readability of the document.
Thanks to Cameron Byrne who was an active co-author of some earlier
versions of this draft.
12. Additional Author List Thanks to Cameron Byrne who was an active coauthor of some earlier
draft versions of this document.
The following are extended authors who contributed to the effort: 11. Contributors
Qiong Sun The following individuals contributed extensively to the effort:
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100035
P.R.China
Phone: +86-10-58552936
Email: sunqiong@ctbri.com.cn
QiBo Niu Qiong Sun
ZTE China Telecom
50,RuanJian Road. Room 708, No. 118, Xizhimennei Street
YuHua District, Beijing 100035
Nan Jing 210012 P.R. China
P.R.China Phone: +86-10-58552936
Email: niu.qibo@zte.com.cn EMail: sunqiong@ctbri.com.cn
13. References QiBo Niu
ZTE
50 RuanJian Road
YuHua District,
Nan Jing 210012
P.R. China
EMail: niu.qibo@zte.com.cn
13.1. Normative References 12. References
[I-D.ietf-appsawg-http-forwarded] 12.1. Normative References
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 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.
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005. January 2005.
skipping to change at page 18, line 35 skipping to change at page 18, line 26
Selkirk, "Port Control Protocol (PCP)", RFC 6887, April Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
2013. 2013.
[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC
6946, May 2013. 6946, May 2013.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", RFC the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
7050, November 2013. 7050, November 2013.
13.2. Informative References [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, June 2014.
[Alexa] Alexa, "http://www.alexa.com/topsites", April 2013. 12.2. Informative References
[Cisco-VNI] [Alexa] Alexa, "Top 500 Global Sites", April 2013,
Cisco, "Cisco Visual Networking Index: Forecast and <http://www.alexa.com/topsites>.
Methodology, 2012-2017,
http://ciscovni.com/forecast-widget/index.html", May 2013.
[I-D.anderson-siit-dc] [COEXIST] Kaliwoda, A. and D. Binet, "Co-existence of both dual-
Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data stack and IPv6-only hosts", Work in Progress, October
Centre Environments", draft-anderson-siit-dc-00 (work in 2012.
progress), November 2012.
[I-D.chen-behave-nat64-radius-extension] [CONN-STATUS]
Chen, G. and D. Binet, "Radius Attributes for Stateful Patil, P., Boucadair, M., Wing, D., and T. Reddy, "IP
NAT64", draft-chen-behave-nat64-radius-extension-00 (work Connectivity Status Notifications for DHCPv6", Work in
in progress), July 2013. Progress, February 2014.
[I-D.chen-sunset4-cgn-port-allocation] [Cisco-VNI]
Chen, G., Tsou, T., Donley, C., and T. Taylor, "Analysis Cisco, "Cisco VNI Global Mobile Data Traffic Forecast,
of NAT64 Port Allocation Method", draft-chen-sunset4-cgn- 2012-2018", February 2014,
port-allocation-03 (work in progress), February 2014. <http://ciscovni.com/forecast-widget/index.html>.
[I-D.donley-behave-deterministic-cgn] [DET-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", draft-donley- Logging in Carrier Grade NAT Deployments", Work in
behave-deterministic-cgn-07 (work in progress), January Progress, January 2014.
2014.
[I-D.ietf-softwire-map-deployment] [IR.92] Global System for Mobile Communications Association
(GSMA), "IMS Profile for Voice and SMS Version 7.0", March
2013.
[MAP-DEPLOY]
Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault,
"Mapping of Address and Port (MAP) - Deployment "Mapping of Address and Port (MAP) - Deployment
Considerations", draft-ietf-softwire-map-deployment-03 Considerations", Work in Progress, April 2014.
(work in progress), October 2013.
[I-D.ietf-softwire-map-t] [MAP-T] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and
T. Murakami, "Mapping of Address and Port using T. Murakami, "Mapping of Address and Port using
Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work Translation (MAP-T)", Work in Progress, February 2014.
in progress), February 2014.
[I-D.ietf-softwire-stateless-4v6-motivation] [MOTIVATION]
Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Boucadair, M., Matsushima, S., Lee, Y., Bonness, O.,
Borges, I., and G. Chen, "Motivations for Carrier-side Borges, I., and G. Chen, "Motivations for Carrier-side
Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- Stateless IPv4 over IPv6 Migration Solutions", Work in
softwire-stateless-4v6-motivation-05 (work in progress), Progress, November 2012.
November 2012.
[I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B. and S. Jiang, "Recommendations of Using Unique
Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-02 (work in progress), February 2014.
[I-D.kaliwoda-sunset4-dual-ipv6-coexist]
Kaliwoda, A. and D. Binet, "Co-existence of both dual-
stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual-
ipv6-coexist-01 (work in progress), October 2012.
[I-D.wing-dhc-dns-reconfigure] [NAT64-RADIUS]
Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6 Chen, G. and D. Binet, "Radius Attributes for Stateful
Dynamic Reconfiguration", draft-wing-dhc-dns- NAT64", Work in Progress, July 2013.
reconfigure-02 (work in progress), September 2013.
[IR.92] Global System for Mobile Communications Association [PORT-ALLOC]
(GSMA), , "IMS Profile for Voice and SMS Version 7.0", Chen, G., Tsou, T., Donley, C., and T. Taylor, "Analysis
March 2013. of NAT64 Port Allocation Methods for Shared IPv4
Addresses", Work in Progress, April 2014.
[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, January Protocol Port Randomization", BCP 156, RFC 6056, January
2011. 2011.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
skipping to change at page 20, line 48 skipping to change at page 20, line 26
[RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet
Content Providers and Application Service Providers", RFC Content Providers and Application Service Providers", RFC
6883, March 2013. 6883, March 2013.
[RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
"Analysis of Potential Solutions for Revealing a Host "Analysis of Potential Solutions for Revealing a Host
Identifier (HOST_ID) in Shared Address Deployments", RFC Identifier (HOST_ID) in Shared Address Deployments", RFC
6967, June 2013. 6967, June 2013.
Appendix A. Testing Results of Application Behavior [SIIT] Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data
Centre Environments", Work in Progress, November 2012.
We test several application behaviors in a lab environment to [ULA-USAGE]
Liu, B. and S. Jiang, "Recommendations of Using Unique
Local Addresses", Work in Progress, February 2014.
Appendix A. Test Results for Application Behavior
We tested several application behaviors in a lab environment to
evaluate the impact when a primary NAT64 is out of service. In this evaluate the impact when a primary NAT64 is out of service. In this
testing, participants are asked to connect a IPv6-only WiFi network testing, participants were asked to connect an IPv6-only WiFi network
using laptops, tablets or mobile phones. NAT64 is deployed as the using laptops, tablets, or mobile phones. NAT64 was deployed as the
gateway to connect Internet service. The tested applications are gateway to provide Internet service. The tested applications are
shown in the below table. Cold standby, warm standby and hot standby shown in the table below. Cold Standby, Warm Standby, and Hot
are taken turn to be tested. The participants may experience service Standby were each tested. The participants may have experienced
interruption due to the NAT64 handover. Different interruption service interruption due to the NAT64 handover. Different
intervals are tested to gauge application behaviors. The results are interruption intervals were tested to gauge application behaviors.
illuminated as below. The results are shown below.
Table 2: The Acceptable Delay of Applications
Table 2: The acceptable delay of applications
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| APPs | Acceptable Interrupt | Session Continuity | | Application | Acceptable Interrupt | Session Continuity |
| | Recovery | | | | Recovery | |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| Web Browse |As maximum as 6s | No | | Web browsing | Maximum of 6 s | No |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Http streaming |As maximum as 10s(cache)| Yes | | HTTP streaming | Maximum of 10 s (cache)| Yes |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| Gaming | 200ms~400ms | Yes | | Games | 200-400 ms | Yes |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|P2P streaming, | 10~16s | Yes | |P2P file sharing| 10-16 s | Yes |
|file sharing | | | |and streaming | | |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Instant Message |1 minute | Yes | | Instant Message| 1 minute | Yes |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Mail |30 seconds | No | | Email | 30 s | No |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Downloading |1 minutes | No | | Downloading | 1 minute | No |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
Authors' Addresses Authors' Addresses
Gang Chen Gang Chen
China Mobile China Mobile
Xuanwumenxi Ave. No.32, Xuanwumenxi Ave. No. 32
Xuanwu District, Xuanwu District
Beijing 100053 Beijing 100053
China P.R. China
EMail: chengang@chinamobile.com, phdgang@gmail.com
Email: phdgang@gmail.com
Zhen Cao Zhen Cao
China Mobile China Mobile
Xuanwumenxi Ave. No.32, Xuanwumenxi Ave. No. 32
Xuanwu District, Xuanwu District
Beijing 100053 Beijing 100053
China P.R. China
Email: caozhen@chinamobile.com, zehn.cao@gmail.com EMail: caozhen@chinamobile.com, zehn.cao@gmail.com
Chongfeng Xie Chongfeng Xie
China Telecom China Telecom
Room 708 No.118, Xizhimenneidajie Room 708, No. 118, Xizhimennei Street
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-Orange France Telecom-Orange
Rennes Rennes
35000 35000
France France
Email: david.binet@orange.com EMail: david.binet@orange.com
 End of changes. 144 change blocks. 
568 lines changed or deleted 553 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/