draft-ietf-v6ops-nat64-experience-04.txt   draft-ietf-v6ops-nat64-experience-05.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: April 17, 2014 C. Xie Expires: June 12, 2014 C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom-Orange France Telecom-Orange
October 14, 2013 December 9, 2013
NAT64 Operational Experiences NAT64 Operational Experience
draft-ietf-v6ops-nat64-experience-04 draft-ietf-v6ops-nat64-experience-05
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 Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 April 17, 2014. This Internet-Draft will expire on June 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
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 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 . . . . . . . . . . . . . . . . . . . 4 3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5
3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5 3.1.4. Co-existence 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 . . . . . . . . . . . . . . . . . . . . . 8 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. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 10 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
12. Additional Author List . . . . . . . . . . . . . . . . . . . 14 12. Additional Author List . . . . . . . . . . . . . . . . . . . 15
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. Testing Results of Application Behavior . . . . . . 18 Appendix A. Testing Results of Application Behavior . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 Internet
due to the IPv4 depletion. Network operators have to deploy 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 network's 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
skipping to change at page 3, line 38 skipping to change at page 3, line 38
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 Carrier Grade distinction of location is if the NAT64 is located in a Carrier Grade
NAT or server Front End. The terms of NAT-CGN/FE are understood to be NAT or server Front End. The terms of NAT-CGN/FE are understood to be
a topological distinction indicating different features employed in a a topological distinction indicating different features employed in a
NAT64 deployment. NAT64 deployment.
NAT64-CGN: A NAT64-CGN is placed in an ISP network. IPv6 NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP
subscribers leverage the NAT64-CGN to access existing IPv4 network. IPv6 subscribers leverage the NAT64-CGN to access
internet services. The ISP as an administrative entity takes full existing IPv4 internet services. The ISP as an administrative
control on the IPv6 side, but has limited or no control on the entity takes full control on the IPv6 side, but has limited or no
IPv4 side. NAT64-CGN may have to consider the IPv4 Internet control on the IPv4 side. NAT64-CGN may have to consider the IPv4
environment and services to make appropriate configurations. Internet environment and services to make appropriate
configurations.
NAT64-FE: A NAT64-FE is generally a device with NAT64 functionality NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device
in a content provider or data center network. It could be for with NAT64 functionality in a content provider or data center
example a traffic load balancer or a firewall. The operator of network. It could be for example a traffic load balancer or a
the NAT64-FE has full control over the IPv4 network within the firewall. The operator of the NAT64-FE has full control over the
data center, but only limited influence or control over the IPv4 network within the data center, but only limited influence or
external IPv6 network. control over the external IPv6 network.
3. NAT64 Networking Experiences 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 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
skipping to change at page 4, line 31 skipping to change at page 4, line 31
[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 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. 464xlat[RFC6877] is network that couples to the IPv4 Internet. 464xlat[RFC6877] is
proposed to enable access of IPv4 only applications or applications proposed to enable access of IPv4 only applications or applications
that call IPv4 literal addresses. Using DNS64 will help 464xlat to that call IPv4 literal addresses. Using DNS64 will help 464xlat to
automatically discover NAT64 prefix through automatically discover NAT64 prefix through [RFC7050]. Berkeley
[I-D.ietf-behave-nat64-discovery-heuristic]. Berkeley Internet Name Internet Name Daemon (BIND) software supports the function. It's
Daemon (BIND) software supports the function. It's important to note important to note that DNS64 generates the synthetic AAAA reply when
that DNS64 generates the synthetic AAAA reply when services only services only register A records. Operators should not expect to
register A records. Operators should not expect to access IPv4 parts access IPv4 parts of a dual-stack server using NAT64/DNS64. The
of a dual-stack server using NAT64/DNS64. The traffic is forwarded traffic is forwarded on IPv6 paths if dual-stack servers are
on IPv6 paths if dual-stack servers are targeted. IPv6 traffic may targeted. IPv6 traffic may be routed not going through NAT64. Only
be routed not going through NAT64. Only the traffic going to the traffic going to IPv4-only service would traverse NAT64. In some
IPv4-only service would traverse NAT64. In some sense, it encourages sense, it encourages IPv6 transmission and restrains NAT uses
IPv6 transmission and restrains NAT uses compared to NAT44(if used), compared to NAT44(if used), on which all traffic flows have to be
on which all traffic flows have to be traversed and translated. In traversed and translated. In some cases, NAT64-CGN may serve double
some cases, NAT64-CGN may serve double roles, i.e. a translator and roles, i.e. a translator and IPv6 forwarder. In mobile networks,
IPv6 forwarder. Some failure cases may be occurred once NAT64 serves NAT64 is likely deployed as the default gateway serving for all the
a IPv6 gateway while is configured only with IPv4 on WAN links. We IPv6 traffic. The traffic heading to a dual-stack server is only
tested on Top100 websites (referring to [Alexa] statistics) in such forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested
condition. 43% of websites are failed to be connected since those to be configured on the Internet faced interfaces of NAT64. We
websites have both AAAA and A records. Therefore, it's recommended tested on Top100 websites (referring to [Alexa] statistics). 43% of
to enable NAT64 WAN links with dual-stack connections in such case. websites are connected and forwarded on the NAT64 since those
websites have both AAAA and A records. With expansion of IPv6
supports, the translation process on NAT64 will likely be faded.
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 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 Autonomous System (AS) 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
Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway
(PDN-GW) 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
skipping to change at page 5, line 49 skipping to change at page 5, line 52
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
selection of IPv4/IPv6 paths may depend on particular implementation selection of IPv4/IPv6 paths may depend on particular implementation
choices or settings on a host-by-host basis, and may differ from an choices or settings on a host-by-host basis, and may differ from an
operator's deterministic scheme. Our tests verified that hosts may operator's deterministic scheme. Our tests verified that hosts may
find themselves switching between IPv4 and IPv6 paths as they access find themselves switching between IPv4 and IPv6 paths as they access
identical service, but at different times identical service, but at different times
[I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each [I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each
path is different, it may cause unstable user experiences and some path is different, it may cause unstable user experiences and some
degradation of Quality of Experience (QoE) when fallback to the other degradation of Quality of Experience (QoE) when fallback to the other
protocol is not powerful enough for example. It's also difficult for protocol is not powerful enough. It's also difficult for operators
operators to debug the issue and make optimal resource usages on both to find a solution to make a stable network with optimal resource
NAT44 and NAT64. It's desirable to find the solutions that will utilization. In general, it's desirable to figure out the solution
allow introducing IPv6/IPv4 translation service to IPv6-only hosts that will introduce IPv6/IPv4 translation service to IPv6-only hosts
while keeping dual-stack hosts unaffected and IPv4 service unchanged. connecting to IPv4 servers while making sure dual-stack hosts to have
at least one address family accessible via native service if it's
possible. With the end-to-end native IPv6 environment is available,
hosts should be upgraded aggressively to migrate to IPv6-only. There
is an ongoing effort to detect host connectivity and propose new
DHCPv6 option[I-D.wing-dhc-dns-reconfigure] to convey appropriate
configuration information 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 load an Internet Data Center (IDC), for example co-located with load
balancing function. Load balancers are employed to connect different balancing function. Load balancers are employed to connect different
IP family domains, meanwhile distribute workloads across multiple IP family domains, meanwhile distribute workloads across multiple
domains or internal servers actually. In some cases, IPv4 addresses domains or internal servers actually. In some cases, IPv4 addresses
exhaustion may not be a problem in some IDC's networks. IPv6 support exhaustion may not be a problem in some IDC's networks. IPv6 support
for some applications may require some investments and workloads so for some applications may require some investments and workloads so
skipping to change at page 7, line 7 skipping to change at page 7, line 15
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
DNS servers requiring to populate these servers with corresponding DNS servers requiring to populate these servers with corresponding
AAAA records. In this case, there is no need to deploy DNS64 AAAA records. In this case, there is no need to deploy DNS64
servers. Those AAAA records can be some native IPv6 addresses or servers. Those AAAA records can be some native IPv6 addresses or
some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6 some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6
address does not give the possibility to nodes to get any information address does not give the possibility to nodes to get any information
about NAT64 presence on communication path and the possibility to about NAT64 presence on communication path and the possibility to
prefer IPv4 path or the IPv6 path in dual-stack networks. Using an prefer IPv4 path or the IPv6 path in dual-stack networks. For the
independent sub domain e.g. ipv6exp.xxx.xxx may help to identify testing purpose, operators could use an independent sub domain e.g.
experimental ipv6 services to users. How to design the FQDN for the ipv6exp.xxx.xxx to identify experimental ipv6 services to users. How
IPv6 service is out-of-scope of this document. to design the FQDN for the IPv6 service is out-of-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 mechanism is an network services. The deployment of redundancy mechanism is an
essential approach to avoid single-point failure and significantly essential approach to avoid single-point failure and significantly
increase the network reliability. It's not only useful to stateful increase the network reliability. It's not only useful to stateful
NAT64 cases, but also to stateless NAT64 gateways. NAT64 cases, but also to stateless NAT64 gateways.
skipping to change at page 8, line 6 skipping to change at page 8, line 15
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
testing. In some sense, it could guarantee the session continuity testing. In some sense, it could guarantee the session continuity
for every service. In order to timely transmit states for every service. In order to timely transmit session states,
information, operators may have to deploy extra transport links operators may have to deploy extra transport links between primary
between primary NAT64 and distant backup. NAT64 and distant backup. The scale of synchronization data
instance is depending on the particular deployment. For example,
If a NAT64-CGN is served for 200,000 users, the average amount of
800, 000 sessions per second is roughly estimated for new created
and expired sessions. A 10Gbps transport link should be used for
the sync data transmission.
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 may be useful to investigate
tolerance of applications and the traffic characteristics in a performance tolerance of applications and the traffic characteristics
particular network. Some testing results are shown in the in a particular network. Some testing results are shown in the
Appendix A. Appendix A.
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 failover. of maintaining bindings for those sessions across failover.
skipping to change at page 9, line 5 skipping to change at page 9, line 21
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 equipment doesn'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. For the applications not requiring DNS different IPv6 prefixes. For the applications not requiring DNS
resolver, internal hosts could learn multiple IPv6 prefixes resolver, internal hosts could learn multiple IPv6 prefixes
through the approaches defined through the approaches defined in[RFC7050] and then select one
in[I-D.ietf-behave-nat64-discovery-heuristic] and then select one
based on a given prefix selection policy. 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
skipping to change at page 9, line 35 skipping to change at page 9, line 50
record the NAT64 log information for specific periods of time. In record the NAT64 log information for specific periods of time. In
our lab testing, the log information from 200,000 subscribers have our lab testing, the log information from 200,000 subscribers have
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.
implementations to mitigate the issue. For example, stateful NAT64
could configure with bulk port allocation method. Once a subscriber There are also several implementations to mitigate the issue. For
creates the first session, a number of ports are pre-allocated. A example, stateful NAT64 could configure with bulk port allocation
bulk allocation message is logged indicating this allocation. method. Once a subscriber creates the first session, a number of
Subsequent session creations will use one of the pre-allocated port ports are pre-allocated. A bulk allocation message is logged
and hence does not require logging. The log volume in this case may indicating this allocation. Subsequent session creations will use
be only one thousandth of dynamic port allocation. Some one of the pre-allocated port and hence does not require logging.
implementations may adopt static port-range allocations The log volume in this case may be only one thousandth of dynamic
[I-D.donley-behave-deterministic-cgn] which eliminates the need for port allocation. Some implementations may adopt static port-range
per-subscriber logging. As a side effect, the IPv4 multiplexing allocations [I-D.donley-behave-deterministic-cgn] which eliminates
efficiency is decreased regarding to those methods. For example, the the need for per-subscriber logging. As a side effect, the IPv4
utilization ratio of public IPv4 address is dropped approximately to multiplexing efficiency is decreased regarding to those methods. For
75% when NAT64 gateway is configured with bulk port allocation (The example, the utilization ratio of public IPv4 address is dropped
lab testing allocates each subscriber with 400 ports). In addition, approximately to 75% when NAT64 gateway is configured with bulk port
port-range based allocation should also consider port randomization allocation (The lab testing allocates each subscriber with 400
described in [RFC6056] . A trade-off among address multiplexing ports). In addition, port-range based allocation should also
efficiency, logging storage compression and port allocation consider port randomization described in [RFC6056] . A trade-off
complexity should be considered. More discussions could be found in among address multiplexing efficiency, logging storage compression
and port allocation complexity should be considered. More
discussions could be found in
[I-D.chen-sunset4-cgn-port-allocation].Basically, the decision [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.
The use of address sharing will prevent these systems from resolving The use of address sharing will prevent these systems from resolving
the location of a host based on IP address alone. Applications that 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. X-Forwarded-For (XFF) 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 log parsing tools are required to be able to
target subscribers based on IPv6 addresses included in XFF HTTP support IPv6 and may lookup Radius servers for the target
headers. XFF is the de facto standard which has been integrated subscribers based on IPv6 addresses included in XFF HTTP headers.
in most Load Balancers. Therefore, it may be superior to use in a XFF is the de facto standard which has been integrated in most
NAT-FE environment. In the downsides, XFF is specific to HTTP. Load Balancers. Therefore, it may be superior to use in a NAT-FE
It restricts the usages so that the solution can't be applied to environment. In the downsides, XFF is specific to HTTP. It
restricts the usages so that the solution can't be applied to
requests made over HTTPs. This makes geo-location problematic for requests made over HTTPs. This makes geo-location problematic for
HTTPs based services. HTTPs based services.
o The NAT64-CGN equipment may not implement XFF. Geo-location based o The NAT64-CGN equipment may not implement XFF. Geo-location based
on shared IPv4 address is rather inaccurate in that case. on shared IPv4 address 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 their geographical
locations. As consequence, location information can be identified locations. As consequence, location information can be identified
from a certain IPv4 address range. [RFC6967] also enumerates from a certain IPv4 address range. [RFC6967] also enumerates
several options to reveal the host identifier. Each solution several options to reveal the host identifier. Each solution
skipping to change at page 11, line 22 skipping to change at page 11, line 40
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
better overall user experience. better overall user experience.
The service reachability is also subject to the IPv6 support in the
client side. We tested several kinds of applications as shown in the
below table to verify the IPv6 supports.
Table 1: The tested applications
+----------------+----------------------------------------------------+
| APPs | Results and Found Issues |
+----------------+----------------------------------------------------+
| Webservices |Mostly pass, some failure cases due to IPv4 Literals|
+----------------+----------------------------------------------------+
|Instance Message|Mostly fail, softwares don't support IPv6 |
+----------------+----------------------------------------------------+
| Games |Mostly pass for web-based games and mostly fail for |
| |standalone games due to software supports |
+----------------+----------------------------------------------------+
| P2P |Mostly fail, tracker is unable to support IPv6 peer |
| |or some software can't use IPv6 connections |
+----------------+----------------------------------------------------+
| FTP | Pass |
+----------------+----------------------------------------------------+
| Email | Pass |
+----------------+----------------------------------------------------+
| VoIP | Fail, due to the lack of SIP-ALG support on NAT64 |
+----------------+----------------------------------------------------+
| VPN | Fail, due to incapability of IPsec verification |
+----------------+----------------------------------------------------+
The experiences of some applications are still align with [RFC6586].
In addition, we tested several P2P softwares including BitTorrent,
Thunder, PPS TV and eMule. Some failures happened because local
tracker servers don't setup with IPv6 extension patch or software
can't support IPv6. For VoIP services, we mainly tested Voice over
LTE services[IR.92], which is the major solution for voice in the
fourth generation communication ages. NAT64 is testified with some
issues of SIP-ALG supports. In regard to the widespread applications
of VoLTE in the near future, SIP-ALG is of great value to be
implemented on NAT64-CGN.
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" for TCP
sessions must not be less than 2 hours 4 minutes[RFC5382] and 5 sessions must not be less than 2 hours 4 minutes[RFC5382] and 5
minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe
significantly consumed by largely inactive users. The NAT translator significantly consumed by largely inactive users. The NAT translator
and other customers would suffer from service degradation due to port and other customers would suffer from service degradation due to port
consummation by other subscribers using the same NAT64 device. A consummation 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 the issues.
skipping to change at page 13, line 24 skipping to change at page 14, line 24
only assigned with an IPv6 address and connected to NAT64-CGN, when only assigned with an IPv6 address and connected to NAT64-CGN, when
connect to an IPv4 service, it would receive AAAA record generated by connect to an IPv4 service, it would receive AAAA record generated by
the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will
be selected as the source address to the ULA destination address. be selected as the source address to the ULA destination address.
When the host has both IPv4 and IPv6 address, it would initiate both When the host has both IPv4 and IPv6 address, it would initiate both
A and AAAA record lookup, then both original A record and A and AAAA record lookup, then both original A record and
DNS64-generated AAAA record would be received. A host, which is DNS64-generated AAAA record would be received. A host, which is
compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4 compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4
path will be always selected. It may be undesirable because the path will be always selected. It may be undesirable because the
NAT64-CGN will never be used. Operators may consider to add NAT64-CGN will never be used. Operators may consider to add
additional site-specific rows to the default table to steer traffic additional site-specific rows into the default policy table for host
flows going through NAT64-CGN. However, it involves significant address selection in order to steer traffic flows going through
costs to change terminal's behavior. Therefore, operators are not NAT64-CGN. However, it involves significant costs to change
suggested to configure ULAs on a NAT64-CGN. terminal's behavior. Therefore, operators are not suggested to
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 inapplicable to the case of NAT64-FE.
9. Security Considerations 9. Security Considerations
his document presents the deployment experiences of NAT64 in CGN and 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
skipping to change at page 14, line 14 skipping to change at page 15, line 15
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.
10. IANA Considerations 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. 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, Iljitsch van Beijnum, Philip Matthews, Randy
Matthews, Randy Bush, Mikael Abrahamsson, Lorenzo Colitti and Sheng Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley,
Jiang for their helpful comments. Tim Chown and Gert Doering for their helpful comments.
Many thanks to Wesley George and Satoru Matsushima for their detailed Many thanks to Wesley George, Lee Howard and Satoru Matsushima for
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 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.
12. Additional Author List 12. Additional Author List
skipping to change at page 15, line 11 skipping to change at page 16, line 11
Email: niu.qibo@zte.com.cn Email: niu.qibo@zte.com.cn
13. References 13. References
13.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.wing-dhc-dns-reconfigure]
Savolainen, T., Korhonen, J., and D. Wing, "Discovery of Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6
the IPv6 Prefix Used for IPv6 Address Synthesis", draft- Dynamic Reconfiguration", draft-wing-dhc-dns-
ietf-behave-nat64-discovery-heuristic-17 (work in reconfigure-02 (work in progress), September 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 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
skipping to change at page 16, line 34 skipping to change at page 17, line 34
"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.
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of
the IPv6 Prefix Used for IPv6 Address Synthesis", RFC
7050, November 2013.
13.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]
skipping to change at page 17, line 23 skipping to change at page 18, line 26
Logging in Carrier Grade NAT Deployments", draft-donley- Logging in Carrier Grade NAT Deployments", draft-donley-
behave-deterministic-cgn-06 (work in progress), July 2013. behave-deterministic-cgn-06 (work in progress), July 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-07 (work in Solution (4rd)", draft-ietf-softwire-4rd-07 (work in
progress), October 2013. progress), October 2013.
[I-D.ietf-softwire-map-deployment] [I-D.ietf-softwire-map-deployment]
Sun, 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-02 Considerations", draft-ietf-softwire-map-deployment-03
(work in progress), July 2013. (work in progress), October 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-04 (work Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work
in progress), September 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] [I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B., Jiang, S., and C. Byrne, "Recommendations of Liu, B., Jiang, S., and C. Byrne, "Recommendations of
Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- Using Unique Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-00 (work in progress), May 2013. recommendations-01 (work in progress), October 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 [IR.92] Global System for Mobile Communications Association
Protocol version 6 (IPv6)", RFC 3484, February 2003. (GSMA), , "IMS Profile for Voice and SMS Version 7.0",
March 2013.
[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 44 skipping to change at page 20, line 4
[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 Appendix A. Testing Results of Application Behavior
We test several application behaviors in a lab environment to We test 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 are asked to connect a IPv6-only WiFi network
using laptops, tablets or mobile phones. NAT64 is deployed as the using laptops, tablets or mobile phones. NAT64 is deployed as the
gateway to connect Internet service. The tested applications are gateway to connect Internet service. The tested applications are
shown in the below table. Cold standby, warm standby and hot standby shown in the below table. Cold standby, warm standby and hot standby
are taken truns to be tested. The partipants may experience service are taken turn to be tested. The participants may experience service
interruption due to the NAT64 handover. Different interruption interruption due to the NAT64 handover. Different interruption
intervals are tested to gauge application behaviors. The results are intervals are tested to gauge application behaviors. The results are
illuminated as below. illuminated as below.
Table 1: The acceptable delay of applications Table 2: The acceptable delay of applications
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| APPs | Acceptable Interrupt | Session Continuity | | APPs | Acceptable Interrupt | Session Continuity |
| | Recovery | | | | Recovery | |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| Web Browse |As maximum as 6s | No | | Web Browse |As maximum as 6s | No |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Http streaming |As maximum as 10s(cache)| Yes | |Http streaming |As maximum as 10s(cache)| Yes |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
| Gaming | 200ms~400ms | Yes | | Gaming | 200ms~400ms | Yes |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
 End of changes. 34 change blocks. 
117 lines changed or deleted 177 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/