--- 1/draft-ietf-v6ops-nat64-experience-05.txt 2013-12-17 21:14:33.372638267 -0800 +++ 2/draft-ietf-v6ops-nat64-experience-06.txt 2013-12-17 21:14:33.424639594 -0800 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Chen Internet-Draft Z. Cao Intended status: Informational China Mobile -Expires: June 12, 2014 C. Xie +Expires: June 21, 2014 C. Xie China Telecom D. Binet France Telecom-Orange - December 9, 2013 + December 18, 2013 NAT64 Operational Experience - draft-ietf-v6ops-nat64-experience-05 + draft-ietf-v6ops-nat64-experience-06 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,21 +25,21 @@ 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 12, 2014. + This Internet-Draft will expire on June 21, 2014. Copyright Notice Copyright (c) 2013 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 @@ -63,30 +63,30 @@ 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 - 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 12. Additional Author List . . . . . . . . . . . . . . . . . . . 15 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 - 13.2. Informative References . . . . . . . . . . . . . . . . . 17 - Appendix A. Testing Results of Application Behavior . . . . . . 19 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 + 13.2. Informative References . . . . . . . . . . . . . . . . . 18 + Appendix A. Testing Results of Application Behavior . . . . . . 20 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction IPv6 is the only sustainable solution for numbering nodes on Internet due to the IPv4 depletion. Network operators have to deploy IPv6-only networks in order to meet the needs of the expanding internet without available IPv4 addresses. Single stack IPv6 network deployment can simplify network's provisioning. Some justifications have been described in 464xlat @@ -497,66 +497,81 @@ 6.1. Service Reachability NAT64 is providing a translation capability between IPv6 and IPv4 end-nodes. In order to provide the reachability between two IP address families, NAT64-CGN has to implement appropriate application aware functions, i.e. Application Layer Gateway (ALG), where address translation is not itself sufficient and security mechanisms do not render it infeasible. Most NAT64-CGNs mainly provide FTP- ALG[RFC6384]. NAT64-FEs may have functional richness on Load Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have - been supported. It should be noted 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. + been supported. Those application protocols exchange IP address and + port parameters within control session, for example the "Via" filed + in a HTTP header, "Transport" field in a RTSP SETUP message and + "Received: " header in a SMTP message. ALG functions will detect + those fields and make IP address translations. It should be noted + 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. + 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 access IPv6 + networks without requiring software upgrades. 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. + + 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. For the IPsec-ESP mode, the failure happens + because the function of NAT-Traversal in the IKE[RFC3947] is missed + on the NAT64 gateway. NAT64 can't update the TCP/UDP checksum, which + is encrypted. The destination host is failed to validate the + received packets. Table 1: The tested applications +----------------+----------------------------------------------------+ - | APPs | Results and Found Issues | +| APPs | Results and Found Issues |. +----------------+----------------------------------------------------+ - | Webservices |Mostly pass, some failure cases due to IPv4 Literals| +| Webservice |Mostly pass, some failure cases due to IPv4 Literals| +----------------+----------------------------------------------------+ - |Instance Message|Mostly fail, softwares don't support IPv6 | +|Instant Message |Mostly fail, software can't support IPv6 | +----------------+----------------------------------------------------+ - | Games |Mostly pass for web-based games and mostly fail for | - | |standalone games due to software supports | +| Games |Mostly pass for web-based games; mostly fail for | +| |standalone games due to the lack of IPv6 support in | +| |software | +----------------+----------------------------------------------------+ - | P2P |Mostly fail, tracker is unable to support IPv6 peer | - | |or some software can't use IPv6 connections | +| SIP-VoIP |Fail, due to the lack of NAT64 traversal | +----------------+----------------------------------------------------+ - | FTP | Pass | +| IPsec-VPN |Fail, the translated IPsec packets are invalidated | +----------------+----------------------------------------------------+ - | Email | Pass | +| P2P |Mostly fail, software can't support IPv6 | +----------------+----------------------------------------------------+ - | VoIP | Fail, due to the lack of SIP-ALG support on NAT64 | +| FTP |Pass | +----------------+----------------------------------------------------+ - | VPN | Fail, due to incapability of IPsec verification | +| Email |Pass | +----------------+----------------------------------------------------+ - 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 Session status normally is managed by a static timer. For example, the value of the "established connection idle-timeout" for TCP sessions must not be less than 2 hours 4 minutes[RFC5382] and 5 minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe significantly consumed by largely inactive users. The NAT translator and other customers would suffer from service degradation due to port consummation by other subscribers using the same NAT64 device. A flexible NAT session control is desirable to resolve the issues. @@ -613,28 +628,29 @@ IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB smaller than 1280 bytes. Such an operational consideration is hard to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged. However, it's a feasible approach in NAT64-FE cases, since a IPv4 network NAT64-FE connected is rather well-organized and operated by a IDC operator or content provider. Therefore, the MTU of IPv4 network in NAT64-FE case are strongly recommended to set to more than 1260 bytes. 8. ULA Usages + Unique Local Addresses (ULAs) are defined in [RFC4193] to be renumbered within a network site for local communications. Operators may use ULAs as NAT64 prefixes to provide site-local IPv6 connectivity. Those ULA prefixes are stripped when the packets going to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site. The use of ULAs could help in identifying the translation - traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided - further guidance for the ULAs usages. + traffic.[I-D.ietf-v6ops-ula-usage-recommendations] provides further + guidance for the ULAs usages. We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is only assigned with an IPv6 address and connected to NAT64-CGN, when connect to an IPv4 service, it would receive AAAA record generated by the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will be selected as the source address to the ULA destination address. When the host has both IPv4 and IPv6 address, it would initiate both A and AAAA record lookup, then both original A record and DNS64-generated AAAA record would be received. A host, which is compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4 @@ -707,45 +723,50 @@ QiBo Niu ZTE 50,RuanJian Road. YuHua District, Nan Jing 210012 P.R.China Email: niu.qibo@zte.com.cn 13. References + 13.1. Normative References [I-D.ietf-appsawg-http-forwarded] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", draft-ietf-appsawg-http-forwarded-10 (work in progress), October 2012. - [I-D.wing-dhc-dns-reconfigure] - Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6 - Dynamic Reconfiguration", draft-wing-dhc-dns- - reconfigure-02 (work in progress), September 2013. - [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. + [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, + "Negotiation of NAT-Traversal in the IKE", RFC 3947, + January 2005. + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, April + 2010. + [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009. @@ -767,20 +788,24 @@ [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. + [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 + Transition in the Session Initiation Protocol (SIP)", RFC + 6157, April 2011. + [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. @@ -853,31 +878,41 @@ [I-D.ietf-v6ops-ula-usage-recommendations] Liu, B., Jiang, S., and C. Byrne, "Recommendations of Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- recommendations-01 (work in progress), October 2013. [I-D.kaliwoda-sunset4-dual-ipv6-coexist] Kaliwoda, A. and D. Binet, "Co-existence of both dual- stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual- ipv6-coexist-01 (work in progress), October 2012. + [I-D.wing-dhc-dns-reconfigure] + Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6 + Dynamic Reconfiguration", draft-wing-dhc-dns- + reconfigure-02 (work in progress), September 2013. + [IR.92] Global System for Mobile Communications Association (GSMA), , "IMS Profile for Voice and SMS Version 7.0", March 2013. [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010. [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, January 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.