draft-ietf-v6ops-nat64-experience-07.txt   draft-ietf-v6ops-nat64-experience-08.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: June 26, 2014 C. Xie Expires: July 12, 2014 C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom-Orange France Telecom-Orange
December 23, 2013 January 8, 2014
NAT64 Operational Experience NAT64 Operational Experience
draft-ietf-v6ops-nat64-experience-07 draft-ietf-v6ops-nat64-experience-08
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 June 26, 2014. This Internet-Draft will expire on July 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
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
skipping to change at page 6, line 28 skipping to change at page 6, line 28
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
IPv6 support may not be a priority. The use of NAT64 may be served IPv6 support may not be a priority. The use of NAT64 may be served
to support widespread IPv6 adoption on the Internet while maintaining to support widespread IPv6 adoption on the Internet while maintaining
IPv4-only applications access. 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.
o Some ICPs who already have satisfactory operational experiences o Some ICPs who already have satisfactory operational experiences
would adopt single stack IPv6 operations to build up their data would adopt single stack IPv6 operations to build up their data
center network, servers and applications since it allows new center network, servers and applications since it allows new
services delivery without having to integrate consideration of services delivery without having to integrate consideration of
IPv4 NAT and address limitations of IPv4 networks. Stateless IPv4 NAT and address limitations of IPv4 networks. Stateless
NAT64[RFC6145]is used to provide services for IPv4-only NAT64[RFC6145] is used to provide services for IPv4-only
subscribers. [I-D.anderson-siit-dc]has provided further subscribers. [I-D.anderson-siit-dc] has provided further
descriptions and guidelines. descriptions and guidelines.
o ICPs who attempt to offer customers IPv6 support in their o ICPs who attempt to offer customers IPv6 support in their
application farms at an early stage may likely run some proxies, application farms at an early stage may likely run some proxies,
which are configured to handle incoming IPv6 flows and proxy them which are configured to handle incoming IPv6 flows and proxy them
to IPv4 back-end systems. Many load balancers have already to IPv4 back-end systems. Many load balancers have already
integrated some proxy functionality. IPv4 addresses configured in integrated some proxy functionality. IPv4 addresses configured in
the proxy can be multiplexed like a stateful NAT64 performs. A the proxy can be multiplexed like a stateful NAT64 performs. A
similar challenge exists once increasingly numerous users in IPv6 similar challenge exists once increasingly numerous users in IPv6
Internet access an IPv4 network. High loads on load-balancers may Internet access an IPv4 network. High loads on load-balancers may
skipping to change at page 7, line 17 skipping to change at page 7, line 17
[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. For the prefer IPv4 path or the IPv6 path in dual-stack networks. For the
testing purpose, operators could use an independent sub domain e.g. testing purpose, operators could use an independent sub domain e.g.
ipv6exp.xxx.xxx to identify experimental ipv6 services to users. How ipv6exp.example.com to identify experimental ipv6 services to users.
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 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
skipping to change at page 11, line 47 skipping to change at page 11, line 47
that ALGs may impact the performance on a NAT64 box to some extent. that ALGs may impact the performance on a NAT64 box to some extent.
ISPs as well as content providers might choose to avoid situations ISPs as well as content providers might choose to avoid situations
where the imposition of an ALG might be required. At the same time, where the imposition of an ALG might be required. At the same time,
it is also important to remind customers and application developers it is also important to remind customers and application developers
that IPv6 end-to-end usage does not require ALG imposition and that IPv6 end-to-end usage does not require ALG imposition and
therefore results in a better overall user experience. therefore results in a better overall user experience.
The service reachability is also subject to the IPv6 support in the The service reachability is also subject to the IPv6 support in the
client side. We tested several kinds of applications as shown in the client side. We tested several kinds of applications as shown in the
below table to verify the IPv6 supports. The experiences of some below table to verify the IPv6 supports. The experiences of some
applications are still align with [RFC6586]. It has been found there applications are still align with [RFC6586]. For example, we have
are some software issues to support IPv6 at this time. The software tested P2P file sharing and streaming applications including eMule
could benefit from 464xlat[RFC6877] to be able to get IPv4 v0.50a, Thunder v7.9 and PPS TV v3.2.0. It has been found there are
connectivity across an IPv6-only network without requiring software some software issues to support IPv6 at this time. The application
upgrades. A SIP based voice call has been tested in LTE mobile software would benefit from 464xlat[RFC6877] until the software adds
IPv6 support.. A SIP based voice call has been tested in LTE mobile
environment as specified in [IR.92]. The voice call is failed due to environment as specified in [IR.92]. The voice call is failed due to
the lack of NAT64 traversal when an IPv6 SIP user agent communicates the lack of NAT64 traversal when an IPv6 SIP user agent communicates
with an IPv4 SIP user agent. In order to address the failure, with an IPv4 SIP user agent. In order to address the failure,
Interactive Connectivity Establishment (ICE) described in [RFC5245]is Interactive Connectivity Establishment (ICE) described in [RFC5245]
recommended to be supported for the SIP IPv6 transition. [RFC6157] is recommended to be supported for the SIP IPv6 transition.
describes both signaling and media layer process, which should be [RFC6157] describes both signaling and media layer process, which
followed. In addition, it may be worth to notice that ICE is not should be followed. In addition, it may be worth to notice that ICE
only useful for NAT traversal, but also firewall[RFC6092] traversal is not only useful for NAT traversal, but also firewall[RFC6092]
in native IPv6 deployment. traversal in native IPv6 deployment.
Different IPsec modes for VPN services have been tested, including Different IPsec modes for VPN services have been tested, including
IPsec-AH and IPsec-ESP. It has been testified IPsec-AH can't survive IPsec-AH and IPsec-ESP. It has been testified IPsec-AH can't survive
since the destination host detects the IP header changes and since the destination host detects the IP header changes and
invalidate the packets. IPsec-ESP failed in our testing because the invalidate the packets. IPsec-ESP failed in our testing because the
NAT64 does not translate IPsec ESP (i.e. protocol 50) packets. It NAT64 does not translate IPsec ESP (i.e. protocol 50) packets. It
has been suggested that IPsec ESP should succeed if the IPSec client has been suggested that IPsec ESP should succeed if the IPSec client
supports NAT-Traversal in the IKE[RFC3947] and uses IPsec ESP over supports NAT-Traversal in the IKE[RFC3947] and uses IPsec ESP over
UDP[RFC3948]. UDP[RFC3948].
skipping to change at page 12, line 38 skipping to change at page 12, line 39
|Instant Message |Mostly fail, software can't support IPv6 | |Instant Message |Mostly fail, software can't support IPv6 |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| Games |Mostly pass for web-based games; mostly fail for | | Games |Mostly pass for web-based games; mostly fail for |
| |standalone games due to the lack of IPv6 support in | | |standalone games due to the lack of IPv6 support in |
| |software | | |software |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| SIP-VoIP |Fail, due to the lack of NAT64 traversal | | SIP-VoIP |Fail, due to the lack of NAT64 traversal |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| IPsec-VPN |Fail, the translated IPsec packets are invalidated | | IPsec-VPN |Fail, the translated IPsec packets are invalidated |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
|P2P streaming, |Mostly fail, software can't support IPv6, e.g. eMule| |P2P file sharing|Mostly fail, software can't support IPv6, e.g. eMule|
|file sharing |Thunder and PPS TV | |and streaming |Thunder and PPS TV |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| FTP |Pass | | FTP |Pass |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
| Email |Pass | | Email |Pass |
+----------------+----------------------------------------------------+ +----------------+----------------------------------------------------+
6.2. Resource Reservation 6.2. Resource Reservation
Session status normally is managed by a static timer. For example, Session status normally is managed by a static timer. For example,
the value of the "established connection idle-timeout" for TCP the value of the "established connection idle-timeout" for TCP
skipping to change at page 20, line 17 skipping to change at page 20, line 17
2011. 2011.
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in
Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing
Residential IPv6 Internet Service", RFC 6092, January Residential IPv6 Internet Service", RFC 6092, January
2011. 2011.
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation", RFC 6144, April 2011. IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269, June
2011.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011. IPv4 Address Shortage", RFC 6346, August 2011.
[RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
Partnership Project (3GPP) Evolved Packet System (EPS)", Partnership Project (3GPP) Evolved Packet System (EPS)",
RFC 6459, January 2012. RFC 6459, January 2012.
[RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only
Network", RFC 6586, April 2012. Network", RFC 6586, April 2012.
 End of changes. 12 change blocks. 
27 lines changed or deleted 24 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/