--- 1/draft-ietf-v6ops-nat64-experience-07.txt 2014-01-07 19:14:38.585733056 -0800 +++ 2/draft-ietf-v6ops-nat64-experience-08.txt 2014-01-07 19:14:38.637734380 -0800 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Chen Internet-Draft Z. Cao Intended status: Informational China Mobile -Expires: June 26, 2014 C. Xie +Expires: July 12, 2014 C. Xie China Telecom D. Binet France Telecom-Orange - December 23, 2013 + January 8, 2014 NAT64 Operational Experience - draft-ietf-v6ops-nat64-experience-07 + draft-ietf-v6ops-nat64-experience-08 Abstract This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -25,25 +25,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -291,22 +291,22 @@ [RFC6144] recommends that AAAA records of load-balancers or application servers can be directly registered in the authoritative DNS servers requiring to populate these servers with corresponding AAAA records. In this case, there is no need to deploy DNS64 servers. Those AAAA records can be some native IPv6 addresses or some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6 address does not give the possibility to nodes to get any information 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.xxx.xxx to identify experimental ipv6 services to users. How - to design the FQDN for the IPv6 service is out-of-scope of this + 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 document. 4. High Availability 4.1. Redundancy Design High Availability (HA) is a major requirement for every service and network services. The deployment of redundancy mechanism is an essential approach to avoid single-point failure and significantly increase the network reliability. It's not only useful to stateful @@ -511,34 +511,35 @@ that ALGs may impact the performance on a NAT64 box to some extent. ISPs as well as content providers might choose to avoid situations where the imposition of an ALG might be required. At the same time, it is also important to remind customers and application developers that IPv6 end-to-end usage does not require ALG imposition and therefore results in a 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. The experiences of some - applications are still align with [RFC6586]. It has been found there - are some software issues to support IPv6 at this time. The software - could benefit from 464xlat[RFC6877] to be able to get IPv4 - connectivity across an IPv6-only network without requiring software - upgrades. A SIP based voice call has been tested in LTE mobile + applications are still align with [RFC6586]. For example, we have + tested P2P file sharing and streaming applications including eMule + v0.50a, Thunder v7.9 and PPS TV v3.2.0. It has been found there are + some software issues to support IPv6 at this time. The application + 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 the lack of NAT64 traversal when an IPv6 SIP user agent communicates with an IPv4 SIP user agent. In order to address the failure, - Interactive Connectivity Establishment (ICE) described in [RFC5245]is - recommended to be supported for the SIP IPv6 transition. [RFC6157] - describes both signaling and media layer process, which should be - followed. In addition, it may be worth to notice that ICE is not - only useful for NAT traversal, but also firewall[RFC6092] traversal - in native IPv6 deployment. + Interactive Connectivity Establishment (ICE) described in [RFC5245] + is recommended to be supported for the SIP IPv6 transition. + [RFC6157] describes both signaling and media layer process, which + should be followed. In addition, it may be worth to notice that ICE + is not only useful for NAT traversal, but also firewall[RFC6092] + traversal in native IPv6 deployment. Different IPsec modes for VPN services have been tested, including IPsec-AH and IPsec-ESP. It has been testified IPsec-AH can't survive since the destination host detects the IP header changes and invalidate the packets. IPsec-ESP failed in our testing because the NAT64 does not translate IPsec ESP (i.e. protocol 50) packets. It has been suggested that IPsec ESP should succeed if the IPSec client supports NAT-Traversal in the IKE[RFC3947] and uses IPsec ESP over UDP[RFC3948]. @@ -551,22 +552,22 @@ |Instant Message |Mostly fail, software can't support IPv6 | +----------------+----------------------------------------------------+ | Games |Mostly pass for web-based games; mostly fail for | | |standalone games due to the lack of IPv6 support in | | |software | +----------------+----------------------------------------------------+ | SIP-VoIP |Fail, due to the lack of NAT64 traversal | +----------------+----------------------------------------------------+ | IPsec-VPN |Fail, the translated IPsec packets are invalidated | +----------------+----------------------------------------------------+ -|P2P streaming, |Mostly fail, software can't support IPv6, e.g. eMule| -|file sharing |Thunder and PPS TV | +|P2P file sharing|Mostly fail, software can't support IPv6, e.g. eMule| +|and streaming |Thunder and PPS TV | +----------------+----------------------------------------------------+ | FTP |Pass | +----------------+----------------------------------------------------+ | Email |Pass | +----------------+----------------------------------------------------+ 6.2. Resource Reservation Session status normally is managed by a static timer. For example, the value of the "established connection idle-timeout" for TCP @@ -902,24 +903,20 @@ 2011. [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011. [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 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 IPv4 Address Shortage", RFC 6346, August 2011. [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012. [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012.