draft-ietf-v6ops-nat64-experience-09.txt   draft-ietf-v6ops-nat64-experience-10.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: July 17, 2014 C. Xie Expires: September 11, 2014 C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom-Orange France Telecom-Orange
January 13, 2014 March 10, 2014
NAT64 Operational Experience NAT64 Deployment Options and Experience
draft-ietf-v6ops-nat64-experience-09 draft-ietf-v6ops-nat64-experience-10
Abstract Abstract
This document summarizes NAT64 function deployment scenarios and This document summarizes NAT64 function deployment scenarios and
operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and
NAT64 server Front End (NAT64-FE) are considered in this document. NAT64 server Front End (NAT64-FE) are considered in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This 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 July 17, 2014. This Internet-Draft will expire on September 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . 9 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9
5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 13 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
12. Additional Author List . . . . . . . . . . . . . . . . . . . 16 12. Additional Author List . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Testing Results of Application Behavior . . . . . . 21 Appendix A. Testing Results of Application Behavior . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
IPv6 is the only sustainable solution for numbering nodes on Internet IPv6 is the only sustainable solution for numbering nodes on 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 networks Single-stack IPv6 network deployment can simplify networks
provisioning. Some justifications have been described in 464xlat provisioning, some justification was provided in 464xlat [RFC6877].
[RFC6877]. As an example, IPv6-only connectivity confers some IPv6-only connectivity confers some benefits to mobile operators as
benefits to mobile operators. In such mobile context, it enables the an example. In the mobile context, IPv6-only usage enables the use
use of a single IPv6 Packet Data Protocol(PDP) context or Evolved of a single IPv6 Packet Data Protocol(PDP) context or Evolved Packet
Packet System (EPS) bearer if Long Term Evolution (LTE) network is System (EPS) bearer on Long Term Evolution (LTE) networks. This
considered, which eliminates significant network costs caused by eliminates significant network costs caused by employing two PDP
doubling the number of PDP contexts in some cases and the need of contexts in some cases, and the need for IPv4 addresses to be
IPv4 addresses to be assigned to customers. In broadband networks assigned to customers. In broadband networks overall, it can allow
overall, it can allow for the scaling of edge-network growth for the scaling of edge-network growth to be decoupled from IPv4
decoupled from IPv4 numbering limitations. numbering limitations.
In a transition scenario, some existing networks are likely to be In transition scenarios, some existing networks are likely to be
IPv4-only configured for quite a long time. IPv6 networks and hosts IPv4-only for quite a long time. IPv6 networks and hosts IPv6-only
will need to coexist with IPv4 numbered resources. Widespread dual- hosts will need to coexist with IPv4 numbered resources. Widespread
stack deployments have not materialized at the anticipated rate over dual-stack deployments have not materialized at the anticipated rate
the last 10 years, one possible conclusion being that legacy networks over the last 10 years, one possible conclusion being that legacy
will not make the jump quickly. The Internet will include nodes that networks will not make the jump quickly. The Internet will include
are dual-stack, nodes that remain IPv4-only, and nodes that can be nodes that are dual-stack, nodes that remain IPv4-only, and nodes
deployed as IPv6-only nodes. A translation mechanism based on a that can be deployed as IPv6-only nodes. A translation mechanism
NAT64[RFC6146] [RFC6145]function is likely to be a key element of the based on a NAT64[RFC6146] [RFC6145]function is likely to be a key
Internet for IPv6-IPv4 interoperability. element of Internet connectivity for IPv6-IPv4 interoperability.
[RFC6036] reports at least 30% of operators plan to run some kind of [RFC6036] reports at least 30% of operators plan to run some kind of
translator (presumably NAT64/DNS64). Advice on NAT64 deployment and translator (presumably NAT64/DNS64). Advice on NAT64 deployment and
operations are therefore of some importance. [RFC6586] documents the operations are therefore of some importance. [RFC6586] documents the
implications for IPv6 only networks. This document intends to be implications for IPv6 only networks. This document intends to be
specific to NAT64 network planning. specific to NAT64 network planning.
2. Terminology 2. Terminology
In regards to IPv4/IPv6 translation, [RFC6144] has described a Regarding IPv4/IPv6 translation, [RFC6144] has described a framework
framework of enabling networks to make interworking possible between for enabling networks to make interworking possible between IPv4 and
IPv4 and IPv6 networks. This document has further categorized IPv6 networks. This document has further categorized different NAT64
different NAT64 function locations and use cases. The principle functions, locations and use-cases. The principle distinction of
distinction of location is if the NAT64 is located in a Carrier Grade location is whether the NAT64 is located in a Carrier Grade NAT or
NAT or server Front End. The terms of NAT-CGN/FE are understood to be server Front End. The terms of NAT-CGN/FE are understood to be a
a topological distinction indicating different features employed in a topological distinction indicating different features employed in a
NAT64 deployment. NAT64 deployment.
NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP
network. IPv6 subscribers leverage the NAT64-CGN to access network. IPv6 enabled subscribers leverage the NAT64-CGN to
existing IPv4 internet services. The ISP as an administrative access existing IPv4 internet services. The ISP as an
entity takes full control on the IPv6 side, but has limited or no administrative entity takes full control of the IPv6 side, but has
control on the IPv4 side. NAT64-CGN may have to consider the IPv4 limited or no control on the IPv4 internet side. NAT64-CGN
Internet environment and services to make appropriate deployments may have to consider the IPv4 Internet environment and
configurations. services, and make appropriate configuration choices accordingly.
NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device
with NAT64 functionality in a content provider or data center with NAT64 functionality in a content provider or data center
network. It could be for example a traffic load balancer or a network. It could be for example a traffic load balancer or a
firewall. The operator of the NAT64-FE has full control over the firewall. The operator of the NAT64-FE has full control over the
IPv4 network within the data center, but only limited influence or IPv4 network within the data center, but only limited influence or
control over the external IPv6 network. control over the external Internet IPv6 network.
3. NAT64 Networking Experience 3. NAT64 Networking Experience
3.1. NAT64-CGN Consideration 3.1. NAT64-CGN Consideration
3.1.1. NAT64-CGN Usages 3.1.1. NAT64-CGN Usages
Fixed network operators and mobile operators may locate NAT64 in Fixed network operators and mobile operators may locate NAT64
access networks or in mobile core networks. It can be built into translators in access networks or in mobile core networks. It can be
various devices, including routers, gateways or firewalls in order to built into various devices, including routers, gateways or firewalls
connect IPv6 users to the IPv4 Internet. With regard to the numbers in order to connect IPv6 users to the IPv4 Internet. With regard to
of users and the shortage of public IPv4 addresses, stateful the numbers of users and the shortage of public IPv4 addresses,
NAT64[RFC6146] is more adapted to perform some maximal sharing of stateful NAT64[RFC6146] is more suited to maximize sharing of public
public IPv4 addresses. The usage of stateless NAT64 can be seen with IPv4 addresses. The usage of stateless NAT64 can provide better
better transparency features transparency features [I-D.ietf-softwire-stateless-4v6-motivation],
[I-D.ietf-softwire-stateless-4v6-motivation], while it has to be but 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] in order to address an IPv4 address
[I-D.ietf-softwire-map-t] in order to cope with IPv4 shortage. shortage.
3.1.2. DNS64 Deployment 3.1.2. DNS64 Deployment
DNS64[RFC6147] is recommended for use in combination with stateful DNS64[RFC6147] is recommended for use in combination with stateful
NAT64, and will likely be an essential part of an IPv6 single-stack NAT64, and 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] can
proposed to enable access of IPv4 only applications or applications enable access of IPv4 only applications or applications that call
that call IPv4 literal addresses. Using DNS64 will help 464xlat to IPv4 literal addresses. Using DNS64 will help 464xlat to
automatically discover NAT64 prefix through [RFC7050]. Berkeley automatically discover NAT64 prefix through [RFC7050]. Berkeley
Internet Name Daemon (BIND) software supports the function. It's Internet Name Daemon (BIND) software supports the function. It's
important to note that DNS64 generates the synthetic AAAA reply when important to note that DNS64 generates the synthetic AAAA reply when
services only register A records. Operators should not expect to services only provide A records. Operators should not expect to
access IPv4 parts of a dual-stack server using NAT64/DNS64. The access IPv4 parts of a dual-stack server using NAT64/DNS64. The
traffic is forwarded on IPv6 paths if dual-stack servers are traffic is forwarded on IPv6 paths if dual-stack servers are
targeted. IPv6 traffic may be routed not going through NAT64. Only targeted. IPv6 traffic may be routed around rather than going
the traffic going to IPv4-only service would traverse NAT64. In some through NAT64. Only the traffic going to IPv4-only service would
sense, it encourages IPv6 transmission and restrains NAT uses traverse the NAT64 translator. In some sense, it encourages IPv6
compared to NAT44(if used), on which all traffic flows have to be usage and limits NAT translation compared to employing NAT44, where
traversed and translated. In some cases, NAT64-CGN may serve double all traffic flows have to be translated. In some cases, NAT64-CGNs
roles, i.e. a translator and IPv6 forwarder. In mobile networks, may serve double roles, i.e. as a translator and IPv6 forwarder. In
NAT64 is likely deployed as the default gateway serving for all the mobile networks, NAT64 may be deployed as the default gateway serving
IPv6 traffic. The traffic heading to a dual-stack server is only all the IPv6 traffic. The traffic heading to a dual-stack server is
forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested only forwarded on the NAT64. Therefore, both IPv6 and IPv4 are
to be configured on the Internet faced interfaces of NAT64. We suggested to be configured on the Internet faced interfaces of NAT64.
tested on Top100 websites (referring to [Alexa] statistics). 43% of We tested on Top100 websites (referring to [Alexa] statistics). 43%
websites are connected and forwarded on the NAT64 since those of websites are connected and forwarded on the NAT64 since those
websites have both AAAA and A records. With expansion of IPv6 websites have both AAAA and A records. With expansion of IPv6
supports, the translation process on NAT64 will likely be faded. In support, the translation process on NAT64 will likely become less-
addition, it should be noted the DNS64-DNSSEC Interaction[RFC6147] important over time. It should be noted the DNS64-DNSSEC
may impact the DNS64 process. For example, DNS64 will not work with Interaction[RFC6147] may impact validation of Resource Records
the case, where there is a DNS query with the "DNSSEC OK" (DO) bit retrieved from the the DNS64 process. In particular, DNSSEC
set and the "Checking Disabled" (CD) bit set received. validation will fail when DNS64 synthesizes AAAA records where there
is a DNS query with the "DNSSEC OK" (DO) bit set and the "Checking
Disabled" (CD) bit set received.
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 may be a
considered as a feature of the Autonomous System (AS) border in fixed feature of the Autonomous System (AS) border in fixed networks. It
networks. And, it is likely to be deployed in an IP node beyond the may be deployed in an IP node beyond the Gateway GPRS Support Node
Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway (GGSN) or Public Data Network- Gateway (PDN-GW) in mobile networks or
(PDN-GW) in mobile networks or directly in the gateway itself in some directly as part of the gateway itself in some situations. This
situations. This allows consistent attribution and traceability allows consistent attribution and traceability within the service
within the service provider network. It has been observed that the provider network. It has been observed that the process of
process of correlating log information is problematic from multiple- correlating log information is problematic from multiple-vendor's
vendor's equipment due to inconsistent formats of log records. equipment due to inconsistent formats of log records. Placing NAT64
Placing NAT64 in a centralized location may reduce diversity of log in a centralized location may reduce diversity of log format and
format and simplify the network provisioning. Moreover, since NAT64 simplify the network provisioning. Moreover, since NAT64 is only
is only targeted at serving traffic flows from IPv6 to IPv4-only targeted at serving traffic flows from IPv6 to IPv4-only services,
services, the user traffic volume should not be as high as in a NAT44 the user traffic volume should not be as high as in a NAT44 scenario,
scenario, and therefore, the gateway's capacity in such location may and therefore, the gateway's capacity in such location may be less of
not be as much of a concern or a hurdle to deployment. On the other a concern or a hurdle to deployment. On the other-hand, placement in
hand, the placement in a centralized way would require more strict a centralized fashion would require more strict high availability
high availability (HA) design. It would also make geo-location based (HA) design. It would also make geo-location based on IPv4 addresses
on IPv4 addresses rather inaccurate as it is currently the case for rather inaccurate as is currently the case for NAT44 CGN already
NAT44 CGN already deployed in ISP networks. More considerations or deployed in ISP networks. More considerations or workarounds on HA
workarounds on HA and traceability could be found at Section 4 and and traceability could be found at Section 4 and Section 5.
Section 5.
3.1.4. Co-existence of NAT64 and NAT44 3.1.4. Co-existence of NAT64 and NAT44
NAT64 could likely co-exist with NAT44 in a dual-stack network mostly NAT64 will likely co-exist with NAT44 in a dual-stack network where
because IPv4 private addresses are allocated to customers. The IPv4 private addresses are allocated to customers. The coexistence
coexistence has already appeared in mobile networks, in which dual has already been observed in mobile networks, in which dual stack
stack mobile phones normally initiate some dual-stack PDN/PDP mobile phones normally initiate some dual-stack PDN/PDP Type[RFC6459]
Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated to query both IPv4/IPv6 address and IPv4 allocated addresses are very
addresses are very often private ones. [RFC6724] always prioritizes often private ones. [RFC6724] always prioritizes IPv6 connections
IPv6 connections regardless of whether the end-to-end path is native regardless of whether the end-to-end path is native IPv6 or IPv6
IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy 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 potentially different, it may cause unstable user experience
degradation of Quality of Experience (QoE) when fallback to the other and some degradation of Quality of Experience (QoE) when falling back
protocol is not powerful enough. It's also difficult for operators to the other protocol. It's also difficult for operators to find a
to find a solution to make a stable network with optimal resource solution to make a stable network with optimal resource utilization.
utilization. In general, it's desirable to figure out the solution In general, it's desirable to figure out the solution that will
that will introduce IPv6/IPv4 translation service to IPv6-only hosts introduce IPv6/IPv4 translation service to IPv6-only hosts connecting
connecting to IPv4 servers while making sure dual-stack hosts to have to IPv4 servers while making sure dual-stack hosts to have at least
at least one address family accessible via native service if it's one address family accessible via native service if possible. With
possible. With the end-to-end native IPv6 environment is available, the end-to-end native IPv6 environment available, hosts should be
hosts should be upgraded aggressively to migrate to IPv6-only. There upgraded aggressively to migrate in favor of IPv6-only. There are
is an ongoing effort to detect host connectivity and propose new ongoing efforts to detect host connectivity and propose a new DHCPv6
DHCPv6 option[I-D.wing-dhc-dns-reconfigure] to convey appropriate option[I-D.wing-dhc-dns-reconfigure] to convey appropriate
configuration information to the hosts. 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 a load
balancing function. Load balancers are employed to connect different -balancing function. Load-balancers are employed to connect
IP family domains, meanwhile distribute workloads across multiple different IP family domains, and distribute workloads across multiple
domains or internal servers actually. In some cases, IPv4 addresses domains or internal servers. 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 internal networks.
for some applications may require some investments and workloads so IPv6 support for some applications may require some investments and
IPv6 support may not be a priority. The use of NAT64 may be served workloads so IPv6 support may not be a priority. The use of NAT64
to support widespread IPv6 adoption on the Internet while maintaining may be served to support widespread IPv6 adoption on the Internet
IPv4-only applications access. while maintaining IPv4-only applications access.
Different strategy has been described in [RFC6883] referred to as Different strategy has been described in [RFC6883] referred to as
"inside out" and "outside in". An IDC operator may implement the "inside out" and "outside in". An IDC operator may implement the
following practices in the NAT64-FE networking. following practices in the NAT64-FE networking scenario.
o Some ICPs who already have satisfactory operational experiences o Some ICPs who already have satisfactory operational experience
would adopt single stack IPv6 operations to build up their data might adopt single stack IPv6 operation in building data-center
center network, servers and applications since it allows new networks, servers and applications, as it allows new services
services delivery without having to integrate consideration of delivery without having to integrate consideration of IPv4 NAT and
IPv4 NAT and address limitations of IPv4 networks. Stateless address limitations of IPv4 networks. Stateless NAT64[RFC6145]
NAT64[RFC6145] is used to provide services for IPv4-only can used to provide services for IPv4-only enabled customers.
subscribers. [I-D.anderson-siit-dc] has provided further [I-D.anderson-siit-dc] has provided further descriptions and
descriptions and guidelines. guidelines.
o ICPs who attempt to offer customers IPv6 support in their o ICPs who attempt to offer customers IPv6 support in their
application farms at an early stage may likely run some proxies, application farms at an early stage may likely run proxies load-
which are configured to handle incoming IPv6 flows and proxy them balancers or translators, which are configured to handle incoming
to IPv4 back-end systems. Many load balancers have already IPv6 flows and proxy them to IPv4 back-end systems. Many load
integrated some proxy functionality. IPv4 addresses configured in balancers integrate proxy functionality. IPv4 addresses
the proxy can be multiplexed like a stateful NAT64 performs. A configured in the proxy may be multiplexed like a stateful NAT64
similar challenge exists once increasingly numerous users in IPv6 translator. A similar challenge exists once increasingly numerous
Internet access an IPv4 network. High loads on load-balancers may users in IPv6 Internet access an IPv4 network. High loads on
be apt to cause additional latency, IPv4 pool exhaustion, etc. load-balancers may be apt to cause additional latency, IPv4 pool
Therefore, this approach is only reasonable at an early stage. exhaustion, etc. Therefore, this approach is only reasonable at
ICPs may learn from the experiences and move on to dual-stack or an early stage. ICPs may employ dual-stack or IPv6 single stack
IPv6 single stack in a further stage, since the native IPv6 is in a further stage, since the native IPv6 is frequently more
always more desirable than transition solutions. desirable than any of the transition solutions.
[RFC6144] recommends that AAAA records of load-balancers or [RFC6144] recommends that AAAA records of load-balancers or
application servers can be directly registered in the authoritative application servers can be directly registered in the authoritative
DNS servers requiring to populate these servers with corresponding DNS servers. In this case, there is no need to deploy DNS64 name-
AAAA records. In this case, there is no need to deploy DNS64 servers. Those AAAA records can point to natively assigned IPv6
servers. Those AAAA records can be some native IPv6 addresses or addresses or IPv4-converted IPv6 addresses[RFC6052]. Hosts are not
some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6 aware of the NAT64 translator on communication path. For the testing
address does not give the possibility to nodes to get any information purpose, operators could employ an independent sub domain e.g.
about NAT64 presence on communication path and the possibility to
prefer IPv4 path or the IPv6 path in dual-stack networks. For the
testing purpose, operators could use an independent sub domain e.g.
ipv6exp.example.com to identify experimental ipv6 services to users. ipv6exp.example.com to identify experimental ipv6 services to users.
How to design the FQDN for the IPv6 service is out-of-scope of this How to design the FQDN for the IPv6 service is out-of-scope of this
document. 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 mechanisms is an
essential approach to avoid single-point failure and significantly essential approach to avoid failure and significantly increase the
increase the network reliability. It's not only useful to stateful network reliability. It's not only useful to stateful NAT64 cases,
NAT64 cases, but also to stateless NAT64 gateways. but also to stateless NAT64 gateways.
Three redundancy modes are mainly used hereafter: cold standby, warm Three redundancy modes are mainly used: cold standby, warm standby
standby and hot standby. and hot standby.
o Cold standby can't replicate the NAT64 states from the primary o Cold standby HA devices do not replicate the NAT64 states from the
equipment to the backup. Administrators switch on the backup primary equipment to the backup. Administrators switch on the
NAT64 only if the primary NAT64 fails. As the results, all the backup NAT64 only if the primary NAT64 fails. As a result, all
existing established sessions will be disconnected. The internal existing established sessions through a failed translator will be
hosts are required to re-establish sessions to the external hosts. disconnected. The translated flows will need to be recreated by
Since the backup NAT64 is manually configured to switch over to end-systems. Since the backup NAT64 is manually configured to
active NAT64, it may have unpredictable impacts to the ongoing switch over to active NAT64, it may have unpredictable impacts to
services. Normally, the handover would take several minutes so as the ongoing services.
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 Bases (BIBs) 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. Employing Bidirectional
Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay Forwarding Detection (BFD) [RFC5880] combined 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. Under ideal conditions hotstandby deployments could
for every service. In order to timely transmit session states, guarantee the session continuity for every service. In order to
operators may have to deploy extra transport links between primary timely transmit session states, operators may have to deploy extra
NAT64 and distant backup. The scale of synchronization data transport links between primary NAT64 and distant backup. The
instance is depending on the particular deployment. For example, scale of synchronization data instance is depending on the
If a NAT64-CGN is served for 200,000 users, the average amount of particular deployment. For example, If a NAT64-CGN is served for
800, 000 sessions per second is roughly estimated for new created 200,000 users, the average amount of 800, 000 sessions per second
and expired sessions. A physical 10Gbps transport link may have is roughly estimated for new created and expired sessions. A
to be deployed for the sync data transmission considering the physical 10Gbps transport link may have to be deployed for the
amount of sync sessions at the peak and capacity redundancy sync data transmission considering the amount of sync sessions at
the peak and capacity redundancy
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 increases resource's when a fail-over occurs. Hot standby increases resource consumption
consumption to synchronize the states, but it achieve seamless in order to synchronize state, but potentially achieves seamless
handover. The consideration of redundancy mode for stateless NAT64 handover. For stateless NAT64 considerations are simple, because
is simple, because state synchronization is unnecessary. In regards state synchronization is unnecessary. Regarding stateful NAT64, it
to stateful NAT64, it may be useful to investigate performance may be useful to investigate performance tolerance of applications
tolerance of applications and the traffic characteristics in a and the traffic characteristics in a particular network. Some
particular network. Some testing results are shown in the 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 of
of traffic is accounted by browsing services. Those services don't traffic is accounted by http/https services. These services
require session continuity. The handover time of warm standby is generally don't require session continuity. Hot-standby does not
qualified to the delay tolerance. Hot-standby does not offer much offer much benefit for those sessions on this point. In fixed
benefit for those sessions on this point. In a fixed network, HTTP networks, HTTP streaming, p2p and online games would be the major
streaming, p2p and online games would be the major traffic beneficiaries of hot-standby replication[Cisco-VNI].
traffic[Cisco-VNI]. Consideration should be given to the importance Consideration should be given to the importance of maintaining
of maintaining bindings for those sessions across failover. bindings for those sessions across failover. Operators may also
Operators may also consider the Average Revenue Per User (ARPU) consider the Average Revenue Per User (ARPU) factors to deploy
factors to deploy suitable redundancy mode. Warm standby may still suitable redundancy mode. Warm standby may still be adopted to cover
be adopted to cover most services while hot standby could be used to most services while hot standby could be used to upgrade Quality of
upgrade Quality of Experience (QoE) using DNS64 with different Experience (QoE) using DNS64 to generate different synthetic
synthetic responses for limited traffic. Further considerations are responses for limited traffic or destinations. Further
discussed at Section 6. considerations are discussed at Section 6.
4.2. Load Balancing 4.2. Load Balancing
Load balancing is used to accompany redundancy design so that better Load balancing is used to accompany redundancy design so that better
scalability and resiliency could be achieved. Stateless NAT64s allow scalability and resiliency 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 equipment doesn't implement load balancer functions on a o NAT64-CGN equipment doesn't typically implement load-balancing
board card. Therefore, the gateways have to resort to DNS64 or functions onboard. Therefore, the gateways have to resort to
internal host's behavior. Once DNS64 is deployed, the load DNS64 or internal host's behavior. Once DNS64 is deployed, the
balancing can be performed by synthesizing AAAA response with load 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 in[RFC7050] and then select one through the approaches defined in[RFC7050] 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,
skipping to change at page 9, line 48 skipping to change at page 9, line 46
5.1. Traceability 5.1. Traceability
Traceability is required in many cases such as identifying malicious Traceability is required in many cases such as identifying malicious
attacks sources and accounting requirements. Operators are asked to attacks sources and accounting requirements. Operators are asked to
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 in ASCII format. It has been
been verified that the rate of traffic flow is around 72 thousand verified that the rate of traffic flow is around 72 thousand flows
flows per second and the volume of recorded information reaches up to per second and the volume of recorded information reaches up to 42.5
42.5 terabytes in the raw format. The volume takes 29.07 terabytes terabytes in the raw format. The volume is 29.07 terabytes in a
in a compact format. Operators have to build up dedicated transport compact format. At scale, operators have to build up dedicated
links, storage system and servers for the purpose. transport links, storage system and servers for the purpose of
managing such logging.
There are also several implementations to mitigate the issue. For There are also several improvements that can be made to mitigate the
example, stateful NAT64 could configure with bulk port allocation issue. For example, stateful NAT64 could configure with bulk port
method. Once a subscriber creates the first session, a number of allocation method. Once a subscriber creates the first session, a
ports are pre-allocated. A bulk allocation message is logged number of ports are pre-allocated. A bulk allocation message is
indicating this allocation. Subsequent session creations will use logged indicating this allocation. Subsequent session creations will
one of the pre-allocated port and hence does not require logging. use one of the pre-allocated port and hence does not require logging.
The log volume in this case may be only one thousandth of dynamic The log volume in this case may be only one thousandth of dynamic
port allocation. Some implementations may adopt static port-range port allocation. Some implementations may adopt static port-range
allocations [I-D.donley-behave-deterministic-cgn] which eliminates allocations [I-D.donley-behave-deterministic-cgn] which eliminates
the need for per-subscriber logging. As a side effect, the IPv4 the need for per-subscriber logging. As a side effect, the IPv4
multiplexing efficiency is decreased regarding to those methods. For multiplexing efficiency is decreased regarding to those methods. For
example, the utilization ratio of public IPv4 address is dropped example, the utilization ratio of public IPv4 address is dropped
approximately to 75% when NAT64 gateway is configured with bulk port approximately to 75% when NAT64 gateway is configured with bulk port
allocation (The lab testing allocates each subscriber with 400 allocation (The lab testing allocates each subscriber with 400
ports). In addition, port-range based allocation should also ports). In addition, port-range based allocation should also
consider port randomization described in [RFC6056] . A trade-off consider port randomization described in [RFC6056] . A trade-off
among address multiplexing efficiency, logging storage compression among address multiplexing efficiency, logging storage compression
and port allocation complexity should be considered. More and port allocation complexity should be considered. More
discussions could be found in discussions could be found in [I-D.chen-sunset4-cgn-port-allocation].
[I-D.chen-sunset4-cgn-port-allocation].Basically, the decision The decision can balance usable IPv4 resources against investments in
depends on usable IPv4 resource and investments of log systems. 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 prevents these systems from resolving the
the location of a host based on IP address alone. Applications that location of a host based on IP address alone. Applications that
assume such geographic information may not work as intended. The assume such geographic information may not work as intended. The
possible solutions listed in [RFC6967] are intended to bridge the possible solutions listed in [RFC6967] are intended to bridge the
gap. However, those solutions can only provide a sub-optimal gap. However, those solutions can only provide a 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)
skipping to change at page 11, line 17 skipping to change at page 11, line 14
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
likely has their-own specific usage. For the geo-location systems likely has their-own specific usage. For the geo-location systems
relying on a Radius database[RFC5580], we have investigated to relying on a Radius database[RFC5580], we have investigated to
deliver NAT64 BIBs and Session Table Entrys (STEs) to a Radius deliver NAT64 BIBs and Session Table Entries (STEs) to a Radius
server[I-D.chen-behave-nat64-radius-extension]. This method could server[I-D.chen-behave-nat64-radius-extension]. This method could
provide geo-location system with an internal IPv6 address to provide geo-location system with an internal IPv6 address to
identify each user. It can get along with [RFC5580] to convey identify each user. It can get along with [RFC5580] to convey
original source address through same message bus. 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
skipping to change at page 13, line 30 skipping to change at page 13, line 25
helpful to minimize terminal battery consumption and reduce the helpful to minimize terminal battery consumption and reduce the
number of keep-alive messages to be sent by mobile terminal devices. number of keep-alive messages to be sent by mobile terminal devices.
Subscribers can also benefit from network reliability. It has been Subscribers can also benefit from network reliability. It has been
discussed that hot-standby offers satisfactory experience once outage discussed that hot-standby offers satisfactory experience once outage
of primary NAT64 is occurred. Operators may rightly be concerned of primary NAT64 is occurred. Operators may rightly be concerned
about the considerable investment required for NAT64 equipment about the considerable investment required for NAT64 equipment
relative to low ARPU income. For example, transport links may cost relative to low ARPU income. For example, transport links may cost
much, because primary NAT64 and backup are normally located at much, because primary NAT64 and backup are normally located at
different locations, separated by a relatively large distance. different locations, separated by a relatively large distance.
Additional maintenance has to be spent to ensure the connectivity Additional cost has to be assumed to ensure the connectivity quality.
quality. However, that may be necessary to some applications, which However, that may be necessary to some applications, which are delay-
are delay-sensitive and seek session continuity, for example on-line sensitive and seek session continuity, for example on-line games and
games and live-streaming. Operators may be able to get added-values live-streaming. Operators may be able to get added-values from those
from those services by offering first-class services. It can be pre- services by offering first-class services. It can be pre-configured
configured on the gateway to hot-standby modes depending on on the gateway to hot-standby modes depending on subscriber's
subscriber's profile. The rest of other sessions can be covered by profile. The rest of other sessions can be covered by cold/warm
cold/warm standby. standby.
7. MTU Considerations 7. MTU Considerations
IPv6 requires that every link in the internet have an Maximum IPv6 requires that every link in the internet have an Maximum
Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. However, Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. However,
in case of NAT64 translation deployment, some IPv4 MTU constrained in case of NAT64 translation deployment, some IPv4 MTU constrained
link will be used in some communication path and originating IPv6 link will be used in some communication path and originating IPv6
nodes may therefore receive an ICMP Packet Too Big (PTB) message, nodes may therefore receive an ICMP Packet Too Big (PTB) message,
reporting a Next-Hop MTU less than 1280 bytes. The result would be reporting a Next-Hop MTU less than 1280 bytes. The result would be
that IPv6 allows packets to contain a fragmentation header, without that IPv6 allows packets to contain a fragmentation header, without
skipping to change at page 19, line 11 skipping to change at page 19, line 6
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., Tsou, T., Donley, C., and T. Taylor, "Analysis
draft-chen-sunset4-cgn-port-allocation-02 (work in of NAT64 Port Allocation Method", draft-chen-sunset4-cgn-
progress), July 2013. port-allocation-03 (work in progress), February 2014.
[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-06 (work in progress), July 2013. behave-deterministic-cgn-07 (work in progress), January
2014.
[I-D.ietf-softwire-map-deployment] [I-D.ietf-softwire-map-deployment]
Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault,
"Mapping of Address and Port (MAP) - Deployment "Mapping of Address and Port (MAP) - Deployment
Considerations", draft-ietf-softwire-map-deployment-03 Considerations", draft-ietf-softwire-map-deployment-03
(work in progress), October 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-05 (work
in progress), September 2013. in progress), February 2014.
[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. and S. Jiang, "Recommendations of Using Unique
Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-01 (work in progress), October 2013. recommendations-02 (work in progress), February 2014.
[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.
[I-D.wing-dhc-dns-reconfigure] [I-D.wing-dhc-dns-reconfigure]
Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6 Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6
Dynamic Reconfiguration", draft-wing-dhc-dns- Dynamic Reconfiguration", draft-wing-dhc-dns-
reconfigure-02 (work in progress), September 2013. reconfigure-02 (work in progress), September 2013.
skipping to change at page 21, line 43 skipping to change at page 21, line 37
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Mail |30 seconds | No | |Mail |30 seconds | No |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
|Downloading |1 minutes | No | |Downloading |1 minutes | No |
+----------------+------------------------+-------------------------+ +----------------+------------------------+-------------------------+
Authors' Addresses Authors' Addresses
Gang Chen Gang Chen
China Mobile China Mobile
53A,Xibianmennei Ave., Xuanwumenxi Ave. No.32,
Xuanwu District, Xuanwu District,
Beijing 100053 Beijing 100053
China China
Email: phdgang@gmail.com Email: phdgang@gmail.com
Zhen Cao Zhen Cao
China Mobile China Mobile
53A,Xibianmennei Ave., Xuanwumenxi Ave. No.32,
Xuanwu District, Xuanwu District,
Beijing 100053 Beijing 100053
China China
Email: caozhen@chinamobile.com Email: caozhen@chinamobile.com, zehn.cao@gmail.com
Chongfeng Xie Chongfeng Xie
China Telecom China Telecom
Room 708 No.118, Xizhimenneidajie Room 708 No.118, Xizhimenneidajie
Beijing 100035 Beijing 100035
P.R.China P.R.China
Email: xiechf@ctbri.com.cn Email: xiechf@ctbri.com.cn
David Binet David Binet
 End of changes. 45 change blocks. 
244 lines changed or deleted 243 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/