draft-ietf-v6ops-nat64-experience-02.txt   draft-ietf-v6ops-nat64-experience-03.txt 
Internet Engineering Task Force 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: January 10, 2014 C. Xie Expires: April 05, 2014 C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom-Orange France Telecom-Orange
July 09, 2013 October 02, 2013
NAT64 Operational Experiences NAT64 Operational Experiences
draft-ietf-v6ops-nat64-experience-02 draft-ietf-v6ops-nat64-experience-03
Abstract Abstract
This document summarizes NAT64 function deployment scenarios and This document summarizes NAT64 function deployment scenarios and
operational experience. Both NAT64-CGN (NAT64 Carrier Grade NATs) operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and
and NAT64-FE (NAT64 server Front End) are considered in this NAT64 server Front End (NAT64-FE) are considered in this document.
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 January 10, 2014. This Internet-Draft will expire on April 05, 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
skipping to change at page 2, line 14 skipping to change at page 2, line 13
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. NAT64 Networking Experiences . . . . . . . . . . . . . . . . 4 3. NAT64 Networking Experiences . . . . . . . . . . . . . . . . 4
3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4 3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4
3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 5 3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 6 3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 6 3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 4
3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5
3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 8 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 8
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. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 10
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Additional Author List . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12. Additional Author List . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Testing Results of Application Behavior . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Now that IANA's global IPv4 address pool has been exhausted, IPv6 is IPv6 is the only sustainable solution for numbering nodes on Internet
the only sustainable solution for numbering nodes on Internet. due to the IPv4 depletion. Network operators have to deploy
Network operators have to deploy IPv6-only networks in order to meet IPv6-only networks in order to meet the needs of the expanding
the needs of the expanding internet without available IPv4 addresses. internet without available IPv4 addresses.
As IPv6 deployment continues, IPv6 networks and hosts will need to
coexist with IPv4 numbered resources. The Internet will include
nodes that are dual-stack, nodes that remain IPv4-only, and 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 network's
provisioning. Some justifications have been described in 464xlat provisioning. Some justifications have been described in 464xlat
[RFC6877]. As an example, IPv6-only connectivity confers some [RFC6877]. As an example, IPv6-only connectivity confers some
benefits to mobile operators. In such mobile context, it enables the benefits to mobile operators. In such mobile context, it enables the
use of a single IPv6 PDP(Packet Data Protocol) context or EPS use of a single IPv6 Packet Data Protocol(PDP) context or Evolved
(Evolved Packet System) bearer if Long Term Evolution (LTE) network Packet System (EPS) bearer if Long Term Evolution (LTE) network is
is considered, which eliminates significant network costs caused by considered, which eliminates significant network costs caused by
doubling the number of PDP contexts in some cases and the need of doubling the number of PDP contexts in some cases and the need of
IPv4 addresses to be assigned to customers. In broadband networks IPv4 addresses to be assigned to customers. In broadband networks
overall, it can allow for the scaling of edge-network growth overall, it can allow for the scaling of edge-network growth
decoupled from IPv4 numbering limitations. decoupled from IPv4 numbering limitations.
In a transition scenario, some existing networks are likely to be In a transition scenario, some existing networks are likely to be
IPv4-only configured for quite a long time. Allowing for IPv4-only configured for quite a long time. IPv6 networks and hosts
interconnection between IPv4-only nodes and IPv6-only nodes is a will need to coexist with IPv4 numbered resources. Widespread dual-
critical capability for service continuity. Widespread dual-stack stack deployments have not materialized at the anticipated rate over
deployments have not materialized at the anticipated rate over the 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. The Internet will include nodes that
will not make the jump quickly. A translation mechanism based on a are dual-stack, nodes that remain IPv4-only, and nodes that can be
deployed as IPv6-only nodes. A translation mechanism based on a
NAT64[RFC6146] [RFC6145]function is likely to be a key element of the NAT64[RFC6146] [RFC6145]function is likely to be a key element of the
Internet for IPv6-IPv4 interoperability. Internet for IPv6-IPv4 interoperability.
[RFC6036] reported 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
operation is therefore of some importance. [RFC6586] documented 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
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 and IPv6 networks. This document has further categorized IPv4 and IPv6 networks. This document has further categorized
different NAT64 function locations and use cases. 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 Carrier Grade
(Carrier Grade NATs) or NAT64-FE (server Front End). The terms of NAT or server Front End. The terms of NAT-CGN/FE are understood to be
NAT-CGN/FE are understood to be a topological distinction indicating a topological distinction indicating different features employed in a
different features employed in a NAT64 deployment. NAT64 deployment.
NAT64-CGN: A NAT64-CGN (Carrier Grade NATs) is placed in an ISP NAT64-CGN: A NAT64-CGN is placed in an ISP network. IPv6
network. IPv6 subscribers leverage the NAT64-CGN to access subscribers leverage the NAT64-CGN to access existing IPv4
existing IPv4 internet services. The ISP as an administrative internet services. The ISP as an administrative entity takes full
entity takes full control on the IPv6 side, but has limited or no control on the IPv6 side, but has limited or no control on the
control on the IPv4 side. NAT64-CGN may have to consider the IPv4 IPv4 side. NAT64-CGN may have to consider the IPv4 Internet
Internet environment and services to make appropriate environment and services to make appropriate configurations.
configurations.
NAT64-FE: A NAT64-FE (server Front End) is generally a device with NAT64-FE: A NAT64-FE is generally a device with NAT64 functionality
NAT64 functionalities in a content provider or data center in a content provider or data center network. It could be for
network. It could be for example a traffic load balancer or a example a traffic load balancer or a firewall. The operator of
firewall. The operator of the NAT64-FE has full control over the the NAT64-FE has full control over the IPv4 network within the
IPv4 network within the data center, but only limited influence or data center, but only limited influence or control over the
control over the external IPv6 network. external IPv6 network.
3. NAT64 Networking Experiences 3. NAT64 Networking Experiences
3.1. NAT64-CGN Consideration 3.1. NAT64-CGN Consideration
3.1.1. NAT64-CGN Usages
Fixed network operators and mobile operators may locate NAT64 in Fixed network operators and mobile operators may locate NAT64 in
access networks or in mobile core networks. It can be built into access networks or in mobile core networks. It can be built into
various devices, including routers, gateways or firewalls in order to various devices, including routers, gateways or firewalls in order to
connect IPv6 users to the IPv4 Internet. With regard to the numbers connect IPv6 users to the IPv4 Internet. With regard to the numbers
of users and the shortage of public IPv4 addresses, stateful of users and the shortage of public IPv4 addresses, stateful
NAT64[RFC6146] is more adapted to perform some maximal sharing of NAT64[RFC6146] is more adapted to perform some maximal sharing of
public IPv4 addresses. The usage of stateless NAT64 can be seen with public IPv4 addresses. The usage of stateless NAT64 can be seen with
better transparency features better transparency features
[I-D.ietf-softwire-stateless-4v6-motivation], while it has to be [I-D.ietf-softwire-stateless-4v6-motivation], while it has to be
coordinated with A+P[RFC6346] processes as specified in 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 [I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope
with IPv4 shortage. with IPv4 shortage.
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 will likely be an essential part of an IPv6 single-stack
network that couples to the IPv4 Internet. And, it will help 464xlat network that couples to the IPv4 Internet. 464xlat[RFC6877] is
to automatically discover NAT64 prefix through proposed to enable access of IPv4 only applications or applications
that call IPv4 literal addresses. Using DNS64 will help 464xlat to
automatically discover NAT64 prefix through
[I-D.ietf-behave-nat64-discovery-heuristic]. Berkeley Internet Name [I-D.ietf-behave-nat64-discovery-heuristic]. Berkeley Internet Name
Daemon(BIND) software supports the function. It's important to note Daemon (BIND) software supports the function. It's important to note
that DNS64 generates the synthetic AAAA reply when services only that DNS64 generates the synthetic AAAA reply when services only
register A records. Operators should not expect to access IPv4 parts register A records. Operators should not expect to access IPv4 parts
of a dual-stack server using NAT64/DNS64. NAT64 would forwards all of a dual-stack server using NAT64/DNS64. The traffic is forwarded
the traffic on IPv6 paths if dual-stack servers are targeted. In on IPv6 paths if dual-stack servers are targeted. IPv6 traffic may
some sense, it encourages IPv6 transmission and restrains NAT uses be routed not going through NAT64. Only the traffic going to
compared to NAT44(if used), on which all traffic flows have to IPv4-only service would traverse NAT64. In some sense, it encourages
traverse. Therefore, NAT64 may serve double roles in some cases, IPv6 transmission and restrains NAT uses compared to NAT44(if used),
i.e. a translator and IPv6 forwarder. Some failure cases may occur on which all traffic flows have to be traversed and translated. In
once NAT64 serves a IPv6 gateway but is configured only with IPv4 on some cases, NAT64-CGN may serve double roles, i.e. a translator and
WAN links. We tested on Top100 websites (referring to [Alexa] IPv6 forwarder. Some failure cases may be occurred once NAT64 serves
statistics) in such condition. 43% of websites are failed to be a IPv6 gateway while is configured only with IPv4 on WAN links. We
connected since those websites have both AAAA and A records. To be tested on Top100 websites (referring to [Alexa] statistics) in such
reliable, it's recommended to enable NAT64 WAN links with dual-stack condition. 43% of websites are failed to be connected since those
connections in the deployment. websites have both AAAA and A records. Therefore, it's recommended
to enable NAT64 WAN links with dual-stack connections in such case.
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 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
translate packets only at or near the network egress. NAT64 can be translate packets only at or near the network egress. NAT64 can be
considered as a feature of the AS (Autonomous System) border in fixed considered as a feature of the Autonomous System (AS) border in fixed
networks. And, it is likely to be deployed in an IP node beyond the networks. And, it is likely to be deployed in an IP node beyond the
GGSN (Gateway GPRS Support Node) or PDN-GW (Public Data Network- Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway
Gateway) in mobile networks or directly in the gateway itself in some (PDN-GW) in mobile networks or directly in the gateway itself in some
situations. This allows consistent attribution and traceability situations. This allows consistent attribution and traceability
within the service provider network. It has been observed that the within the service provider network. It has been observed that the
process of correlating log information is problematic from multiple- process of correlating log information is problematic from multiple-
vendor's equipments due to inconsistent formats of log records. vendor's equipment due to inconsistent formats of log records.
Placing NAT64 in a centralized location may reduce diversity of log Placing NAT64 in a centralized location may reduce diversity of log
format and simplify the network provisioning. Moreover, since NAT64 format and simplify the network provisioning. Moreover, since NAT64
is only targeted at serving traffic flows from IPv6 to IPv4-only 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 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 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 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 hand, the placement in a centralized way would require more strict
high availability (HA) design. It would also make geo-location based high availability (HA) design. It would also make geo-location based
on IPv4 addresses rather inaccurate as it is currently the case for on IPv4 addresses rather inaccurate as it is currently the case for
NAT44 CGN already deployed in ISP networks. More considerations or NAT44 CGN already deployed in ISP networks. More considerations or
workarounds on HA and traceability could be found at Section4 and workarounds on HA and traceability could be found at Section 4 and
Section5 . Section 5.
3.1.4. Co-existence of NAT64 and NAT44
NAT64 could likely co-exist with NAT44 in a dual-stack network mostly NAT64 could likely co-exist with NAT44 in a dual-stack network mostly
because IPv4 private addresses are allocated to customers. The because IPv4 private addresses are allocated to customers. The
coexistence has already appeared in mobile networks, in which dual coexistence has already appeared in mobile networks, in which dual
stack mobile phones normally initiate some dual-stack PDN/PDP stack mobile phones normally initiate some dual-stack PDN/PDP
Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated
addresses are very often private ones. [RFC6724] always prioritizes addresses are very often private ones. [RFC6724] always prioritizes
IPv6 connections regardless of whether the end-to-end path is native IPv6 connections regardless of whether the end-to-end path is native
IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy
Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The
skipping to change at page 6, line 25 skipping to change at page 6, line 37
services delivery without having to integrate consideration of services delivery without having to integrate consideration of
IPv4 NAT and address limitations of IPv4 networks. Stateless IPv4 NAT and address limitations of IPv4 networks. Stateless
NAT64[RFC6145]is used to provide services for IPv4-only NAT64[RFC6145]is used to provide services for IPv4-only
subscribers. [I-D.anderson-siit-dc]has provided further subscribers. [I-D.anderson-siit-dc]has provided further
descriptions and guidelines. descriptions and 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 some proxies, application farms at an early stage may likely run some proxies,
which are configured to handle incoming IPv6 flows and proxy them which are configured to handle incoming IPv6 flows and proxy them
to IPv4 back-end systems. Many load balancers have already to IPv4 back-end systems. Many load balancers have already
integrated some proxy functionalities. IPv4 addresses configured integrated some proxy functionality. IPv4 addresses configured in
in the proxy can be multiplexed like a stateful NAT64 performs. A the proxy can be multiplexed like a stateful NAT64 performs. A
similar challenge exists once increasingly numerous users in IPv6 similar challenge exists once increasingly numerous users in IPv6
Internet access an IPv4 network. High loads on load-balancers may Internet access an IPv4 network. High loads on load-balancers may
be apt to cause additional latency, IPv4 pool exhaustion, etc. be apt to cause additional latency, IPv4 pool exhaustion, etc.
Therefore, this approach is only reasonable at an early stage. Therefore, this approach is only reasonable at an early stage.
ICPs may learn from the experiences and move on to dual-stack or 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 IPv6 single stack in a further stage, since the native IPv6 is
always more desirable than transition solutions. always more desirable than 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
skipping to change at page 7, line 30 skipping to change at page 7, line 42
services. Normally, the handover would take several minutes so as services. Normally, the handover would take several minutes so as
to wait for the whole process of NAT64 bootstrap loader. to wait for the whole process of NAT64 bootstrap loader.
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.
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 in the warm standby. It was
tested that the handover takes as maximum as 1 minute if the tested that the handover takes as maximum as 1 minute if the
backup NAT64 needs to take over routing and re-construct the backup NAT64 needs to take over routing and re-construct the
Binding Information Base (BIB) for 30 million sessions. In Binding Information Bases (BIBs) for 30 million sessions. In
deployment phase, operators could balance loads on distinct NAT64s deployment phase, operators could balance loads on distinct NAT64s
devices. Those NAT64s make a warm backup of each other. devices. Those NAT64s 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, backup NAT64 would take
over and maintain the state of all existing sessions. The over and maintain 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 re-connect the external hosts. The
handover time has been extremely reduced. Thanks to Bidirectional handover time has been extremely reduced. Thanks to Bidirectional
Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay
of only 35ms for 30 million sessions handover was observed during of only 35ms for 30 million sessions handover was observed during
skipping to change at page 8, line 7 skipping to change at page 8, line 19
In general, cold-standby and warm-standby is simpler and less In general, cold-standby and warm-standby is simpler and less
resource intensive, but it requires clients to re-establish sessions resource intensive, but it requires clients to re-establish sessions
when a fail-over occurs. Hot standby doubles resource's consumption when a fail-over occurs. Hot standby doubles resource's consumption
to synchronize the states, but it achieve seamless handover. The to synchronize the states, but it achieve seamless handover. The
consideration of redundancy mode for stateless NAT64 is simple, consideration of redundancy mode for stateless NAT64 is simple,
because it doesn't have to consider time consuming for states because it doesn't have to consider time consuming for states
maintenance. The warm standby is sufficient for stateless NAT64. In maintenance. The warm standby is sufficient for stateless NAT64. In
regards to stateful NAT64, it maybe useful to investigate performance regards to stateful NAT64, it maybe useful to investigate performance
tolerance of applications and the traffic characteristics in a tolerance of applications and the traffic characteristics in a
particular network. The following table is trying to evaluate user particular network. Some testing results are shown in the
experience from a lab testing. Appendix A.
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 |
+----------------+------------------------+-------------------------+
Our statistics in a mobile network shown that almost 91.21% of amount Our statistics in a mobile network shown that almost 91.21% of amount
of traffic is accounted by browsing services. Those services don't of traffic is accounted by browsing services. Those services don't
require session continuity. The handover time of warm standby is require session continuity. The handover time of warm standby is
qualified to the delay tolerance. Hot-standby does not offer much qualified to the delay tolerance. Hot-standby does not offer much
benefit for those sessions on this point. In a fixed network, HTTP benefit for those sessions on this point. In a fixed network, HTTP
streaming, p2p and online games would be the major streaming, p2p and online games would be the major
traffic[Cisco-VNI]. Consideration should be given to the importance traffic[Cisco-VNI]. Consideration should be given to the importance
of maintaining bindings for those sessions across failovers. of maintaining bindings for those sessions across failover.
Operators may also consider the Average Revenue Per User (ARPU) Operators may also consider the Average Revenue Per User (ARPU)
factors to deploy suitable redundancy mode. Warm standby may still factors to deploy suitable redundancy mode. Warm standby may still
be adopted to cover most services while hot standby could be used to be adopted to cover most services while hot standby could be used to
upgrade Quality of Experience (QoE) using DNS64 with different upgrade Quality of Experience (QoE) using DNS64 with different
synthetic responses for limited traffic. Further considerations are synthetic responses for limited traffic. Further considerations are
discussed at Section 6. 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 could 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 [I-D.ietf-softwire-map-deployment]. The deployment of load balancing
may make more sense to stateful NAT64s for the sake of single-point may make more sense to stateful NAT64s for the sake of single-point
failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct
facilities, the following lists the considerations for each case. facilities, the following lists the considerations for each case.
o NAT64-CGN equipments don't implement load balancer functions on a o NAT64-CGN equipment doesn't implement load balancer functions on a
board card. Therefore, the gateways have to resort to DNS64 or board card. Therefore, the gateways have to resort to DNS64 or
internal host's behavior. Once DNS64 is deployed, the load internal host's behavior. Once DNS64 is deployed, the load
balancing can be performed by synthesizing AAAA response with balancing can be performed by synthesizing AAAA response with
different IPv6 prefixes. With the absence of DNS64, internal different IPv6 prefixes. For the applications not requiring DNS
hosts could learn multiple IPv6 prefixes through the approaches resolver, internal hosts could learn multiple IPv6 prefixes
defined in[I-D.ietf-behave-nat64-discovery-heuristic] and then through the approaches defined
select one based on a given prefix selection policy. in[I-D.ietf-behave-nat64-discovery-heuristic] 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 front of a NAT64-FE
farm. Load Balancer uses proxy mode to redirect the flows to the farm. Load Balancer uses proxy mode to redirect the flows to the
appropriate NAT64 instance. Stateful NAT64s require a appropriate NAT64 instance. Stateful NAT64s require a
deterministic pattern to arrange the traffic in order to ensure deterministic pattern to arrange the traffic in order to ensure
outbound/inbound flows traverse the identical NAT64. Therefore, outbound/inbound flows traverse the identical NAT64. Therefore,
static scheduling algorithms, for example source-address based static scheduling algorithms, for example source-address based
policy, is preferred. A dynamic algorithm, for example Round- policy, is preferred. A dynamic algorithm, for example Round-
Robin, may have impacts on applications seeking session Robin, may have impacts on applications seeking session
continuity, which described in the Table 1. continuity, which described in the Table 1.
skipping to change at page 9, line 45 skipping to change at page 9, line 37
been collected from a stateful NAT64 gateway for 60 days. been collected from a stateful NAT64 gateway for 60 days.
Syslog[RFC5424] has been adopted to transmit log message from NAT64 Syslog[RFC5424] has been adopted to transmit log message from NAT64
to a log station. Each log message contains transport protocol, to a log station. Each log message contains transport protocol,
source IPv6 address:port, translated IPv4 address: port and source IPv6 address:port, translated IPv4 address: port and
timestamp. It takes almost 125 bytes long in ASCII format. It has timestamp. It takes almost 125 bytes long in ASCII format. It has
been verified that the volume of recorded information reach up to 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 42.5 terabytes in the raw format and 29.07 terabytes in a compact
format. Operators have to build up dedicated transport links, format. Operators have to build up dedicated transport links,
storage system and servers for the purpose. There are also several storage system and servers for the purpose. There are also several
implementations to mitigate the issue. For example, stateful NAT64 implementations to mitigate the issue. For example, stateful NAT64
could dynamically assign a port range to each subscriber or perform could configure with bulk port allocation method. Once a subscriber
static port-range allocations as creates the first session, a number of ports are pre-allocated. A
[I-D.donley-behave-deterministic-cgn] proposed. Those methods can bulk allocation message is logged indicating this allocation.
change log granularity from per-session to per-customer. The Subsequent session creations will use one of the pre-allocated port
recorded log volume can be reduced to 40.6 gigabytes accordingly. and hence does not require logging. The log volume in this case may
However, the IPv4 multiplexing efficiency is also decreased regarding be only one thousandth of dynamic port allocation. Some
to those methods. For example, the utilization ratio of public IPv4 implementations may adopt static port-range allocations
address is dropped approximately to 75% when sized 400 ports range [I-D.donley-behave-deterministic-cgn] which eliminates the need for
allocated to each device according to our statistics. In addition, per-subscriber logging. As a side effect, the IPv4 multiplexing
efficiency is decreased regarding to those methods. For example, the
utilization ratio of public IPv4 address is dropped approximately to
75% when NAT64 gateway is configured with bulk port allocation (The
lab testing allocates each subscriber with 400 ports). In addition,
port-range based allocation should also consider port randomization port-range based allocation should also consider port randomization
described in [RFC6056] . A trade-off among address multiplexing described in [RFC6056] . A trade-off among address multiplexing
efficiency, logging storage compression and port allocation efficiency, logging storage compression and port allocation
complexity should be considered. More discussions could be found in complexity should be considered. More discussions could be found in
[I-D.chen-sunset4-cgn-port-allocation].Basically, the decision [I-D.chen-sunset4-cgn-port-allocation].Basically, the decision
depends on usable IPv4 resource and investments of log systems. depends on usable IPv4 resource and investments of log systems.
5.2. Geo-location 5.2. Geo-location
IP addresses are usually used as inputs to geo-location services. IP addresses are usually used as inputs to geo-location services.
skipping to change at page 10, line 27 skipping to change at page 10, line 23
the location of a host based on IP address alone. Applications that the 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 sub-optimal
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 today solve problems with source identification
through translation. The following lists current practices to through translation. The following lists current practices to
mitigate the issue. 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. XFF (X-Forwarded-For) proxies, e.g. X-Forwarded-For (XFF)
[I-D.ietf-appsawg-http-forwarded], to convey the IPv6 source [I-D.ietf-appsawg-http-forwarded], to convey the IPv6 source
address in HTTP headers. Those messages would be passed on to address in HTTP headers. Those messages would be passed on to
web-servers. The queried server can lookup Radius servers for the web-servers. The queried server can lookup Radius servers for the
target subscribers based on IPv6 addresses included in XFF HTTP target subscribers based on IPv6 addresses included in XFF HTTP
headers. XFF is the de facto standard which has been integrated headers. XFF is the de facto standard which has been integrated
in most Load Balancers. Therefore, it may be superior to use in a in most Load Balancers. Therefore, it may be superior to use in a
NAT-FE environment. In the downsides, XFF is specific to HTTP. NAT-FE environment. In the downsides, XFF is specific to HTTP.
It restricts the usages so that the solution can't be applied to It restricts the usages so that the solution can't be applied to
requests made over HTTPs. This makes geo-location problematic for requests made over HTTPs. This makes geo-location problematic for
HTTPs based services. HTTPs based services.
o The NAT64-CGN equipments may not implement XFF. Geo-location o The NAT64-CGN equipment may not implement XFF. Geo-location based
based on shared IPv4 address is rather inaccurate in that case. on shared IPv4 address is rather inaccurate in that case.
It's desirable to offer geo-location system more information, for Operators could subdivide the outside IPv4 address pool so an IPv6
example port number to retrieve the internal IPv6 address, which address can be translated depending on their geographical
has meaning in global scale. We have investigated to deliver locations. As consequence, location information can be identified
NAT64 BIBs and Session Table Entrys (STEs) to a Radius from a certain IPv4 address range. [RFC6967] also enumerates
server[I-D.chen-behave-nat64-radius-extension], since current geo- several options to reveal the host identifier. Each solution
location systems rely on a Radius database to inspect location likely has their-own specific usage. For the geo-location systems
information, for example the information provided in [RFC5580]. relying on a Radius database[RFC5580], we have investigated to
Those methods could convey original source address through same deliver NAT64 BIBs and Session Table Entrys (STEs) to a Radius
message bus. Another approach is to ask NAT64-CGN providing server[I-D.chen-behave-nat64-radius-extension]. This method could
application aware gateway to insert IPv6 source addresses. provide geo-location system with an internal IPv6 address to
However, that may introduce complexity and performance identify each user. It can get along with [RFC5580] to convey
degradation. original source address through 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-nodes. In order to provide the reachability between two IP end-nodes. In order to provide the reachability between two IP
address families, NAT64-CGN has to implement appropriate application address families, NAT64-CGN has to implement appropriate application
aware functions, i.e. Application Layer Gateway(ALG), where address aware functions, i.e. Application Layer Gateway (ALG), where address
translation is not itself sufficient and security mechanisms do not translation is not itself sufficient and security mechanisms do not
render it infeasible. Most NAT64-CGNs mainly provide FTP- render it infeasible. Most NAT64-CGNs mainly provide FTP-
ALG[RFC6384]. NAT64-FEs may have functional richness on Load ALG[RFC6384]. NAT64-FEs may have functional richness on 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 have
been supported. It should be noted that ALGs may impact the been supported. It should be noted that ALGs may impact the
performance on a NAT64 box to some extent. ISPs as well as content performance on a NAT64 box to some extent. ISPs as well as content
providers might choose to avoid situations where the imposition of an providers might choose to avoid situations where the imposition of an
ALG might be required. At the same time, it is also important to ALG might be required. At the same time, it is also important to
remind customers and application developers that IPv6 end-to-end remind customers and application developers that IPv6 end-to-end
usage does not require ALG imposition and therefore results in a usage does not require ALG imposition and therefore results in a
skipping to change at page 13, line 12 skipping to change at page 12, line 43
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 IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB
smaller than 1280 bytes. Such an operational consideration is hard smaller than 1280 bytes. Such an operational consideration is hard
to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged. to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged.
However, it's a feasible approach in NAT64-FE cases, since a IPv4 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 network NAT64-FE connected is rather well-organized and operated by a
IDC operator or content provider. Therefore, the MTU of IPv4 network IDC operator or content provider. Therefore, the MTU of IPv4 network
in NAT64-FE case are strongly recommended to set to more than 1260 in NAT64-FE case are strongly recommended to set to more than 1260
bytes. bytes.
8. Security Considerations 8. ULA Usages
Unique Local Addresses (ULAs) are defined in [RFC4193] to be
renumbered within a network site for local communications. Operators
may use ULAs as NAT64 prefixes to provide site-local IPv6
connectivity. Those ULA prefixes are stripped when the packets going
to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site.
The use of ULAs could help in identifying the translation
traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided
further guidance for the ULAs usages.
This document presents the deployment experiences of NAT64 in CGN and 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
connect to an IPv4 service, it would receive AAAA record generated by
the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will
be selected as the source address to the ULA destination address.
When the host has both IPv4 and IPv6 address, it would initiate both
A and AAAA record lookup may due to Happy Eyeballs [RFC6555], then
both original A record and DNS64-generated AAAA record would be
received. The host would prefer the AAAA record as the destination,
if the address selection process still follows the recommendation of
[RFC3484]. While, if the host implements the default policy table as
defined in [RFC6724], since the IPv4 takes the precedence over ULA
(which is difference than [RFC3484]), an IPv4 path will be always
preferred. It may be undesirable because the traffic path is
unexpected due to vary implementations on hosts. Operators have to
make site-specific rules to gauge the host's behaviors, which may
likely add the operational complexity.
ULAs can't work when hosts transit the Internet to connect with
NAT64. Therefore, ULAs are inapplicable to the case of NAT64-FE.
9. Security Considerations
his 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 also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and
black/white-list to enhance the security by specifying access black/white-list to enhance the security by specifying access
policies. For example, NAT64-CGN should forbid establish NAT64 BIB policies. For example, NAT64-CGN should forbid establish NAT64 BIB
for incoming IPv6 packets if uRPF in Strict or Loose mode check does 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. not pass or whose source IPv6 address is associated to black-lists.
The stateful NAT64-FE creates state and maps that connection to an 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. Load Balancer is recommended to NAT64-FE is exposed to attacks. Load Balancer is recommended to
enable the capabilities of line rate DDOS defense, such as the enable the capabilities 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 as well in this case. Therefore, Load Balancers could not necessary as well in this case. Therefore, Load Balancers could not
only serve for optimization of traffic distribution, but also prevent only serve for optimization of traffic distribution, but also prevent
service from quality deterioration due to security attacks. service from quality deterioration due to security attacks.
9. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
10. Acknowledgements 11. 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, Philip Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum, Philip
Matthews and Randy Bush for their helpful comments. Matthews, Randy Bush, Mikael Abrahamsson, Lorenzo Colitti and Sheng
Jiang for their helpful comments.
Many thanks to Wesley George and Satoru Matsushima for their reviews. Many thanks to Wesley George and Satoru Matsushima for their detailed
reviews.
The authors especially thank Joel Jaeggli and Ray Hunter for his The authors especially thank Joel Jaeggli and Ray Hunter for his
efforts and contributions on editing which substantially improves the efforts and contributions on editing which substantially improves the
legibility of the document. legibility of the document.
Thanks to Cameron Byrne who was an active co-author of some earlier Thanks to Cameron Byrne who was an active co-author of some earlier
versions of this draft. versions of this draft.
11. Additional Author List 12. 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
12. References 13. References
12.1. Normative References 13.1. Normative References
[I-D.ietf-appsawg-http-forwarded] [I-D.ietf-appsawg-http-forwarded]
Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
draft-ietf-appsawg-http-forwarded-10 (work in progress), draft-ietf-appsawg-http-forwarded-10 (work in progress),
October 2012. October 2012.
[I-D.ietf-behave-nat64-discovery-heuristic] [I-D.ietf-behave-nat64-discovery-heuristic]
Savolainen, T., Korhonen, J., and D. Wing, "Discovery of Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", draft- the IPv6 Prefix Used for IPv6 Address Synthesis", draft-
ietf-behave-nat64-discovery-heuristic-17 (work in ietf-behave-nat64-discovery-heuristic-17 (work in
progress), April 2013. 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 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009.
skipping to change at page 16, line 12 skipping to change at page 16, line 38
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
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.
12.2. Informative References 13.2. Informative References
[Alexa] Alexa, "http://www.alexa.com/topsites", April 2013. [Alexa] Alexa, "http://www.alexa.com/topsites", April 2013.
[Cisco-VNI] [Cisco-VNI]
Cisco, "Cisco Visual Networking Index: Forecast and Cisco, "Cisco Visual Networking Index: Forecast and
Methodology, 2012-2017, Methodology, 2012-2017,
http://ciscovni.com/forecast-widget/index.html", May 2013. 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] [I-D.chen-behave-nat64-radius-extension]
Chen, G. and D. Binet, "Radius Attributes for Stateful Chen, G. and D. Binet, "Radius Attributes for Stateful
NAT64", draft-chen-behave-nat64-radius-extension-00 (work NAT64", draft-chen-behave-nat64-radius-extension-00 (work
in progress), July 2013. in progress), July 2013.
[I-D.chen-sunset4-cgn-port-allocation] [I-D.chen-sunset4-cgn-port-allocation]
Chen, G., "Analysis of NAT64 Port Allocation Method", Chen, G., "Analysis of NAT64 Port Allocation Method",
draft-chen-sunset4-cgn-port-allocation-01 (work in draft-chen-sunset4-cgn-port-allocation-02 (work in
progress), February 2013. progress), July 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", draft-donley- Logging in Carrier Grade NAT Deployments", draft-donley-
behave-deterministic-cgn-05 (work in progress), January behave-deterministic-cgn-06 (work in progress), July 2013.
2013.
[I-D.ietf-softwire-4rd] [I-D.ietf-softwire-4rd]
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless
Solution (4rd)", draft-ietf-softwire-4rd-05 (work in Solution (4rd)", draft-ietf-softwire-4rd-06 (work in
progress), April 2013. progress), July 2013.
[I-D.ietf-softwire-map-deployment] [I-D.ietf-softwire-map-deployment]
Sun, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, Sun, 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-01 Considerations", draft-ietf-softwire-map-deployment-02
(work in progress), February 2013. (work in progress), July 2013.
[I-D.ietf-softwire-map-t] [I-D.ietf-softwire-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-02 (work Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work
in progress), July 2013. in progress), September 2013.
[I-D.ietf-softwire-stateless-4v6-motivation] [I-D.ietf-softwire-stateless-4v6-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", draft-ietf-
softwire-stateless-4v6-motivation-05 (work in progress), softwire-stateless-4v6-motivation-05 (work in progress),
November 2012. November 2012.
[I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B., Jiang, S., and C. Byrne, "Recommendations of
Using Unique Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-00 (work in progress), May 2013.
[I-D.kaliwoda-sunset4-dual-ipv6-coexist] [I-D.kaliwoda-sunset4-dual-ipv6-coexist]
Kaliwoda, A. and D. Binet, "Co-existence of both dual- Kaliwoda, A. and D. Binet, "Co-existence of both dual-
stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual- stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual-
ipv6-coexist-01 (work in progress), October 2012. ipv6-coexist-01 (work in progress), October 2012.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[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.
[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.
skipping to change at page 18, line 18 skipping to change at page 18, line 49
[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
We test several application behaviors in a lab environment to
evaluate the impact when a primary NAT64 is out of service. In this
testing, participants are asked to connect a IPv6-only WiFi network
using laptops, tablets or mobile phones. NAT64 is deployed as the
gateway to connect Internet service. The tested applications are
shown in the below table. Cold standby, warm standby and hot standby
are taken truns to be tested. The partipants may experience service
interruption due to the NAT64 handover. Different interruption
intervals are tested to gauge application behaviors. The results are
illuminated as below.
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 |
+----------------+------------------------+-------------------------+
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
 End of changes. 57 change blocks. 
155 lines changed or deleted 224 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/