--- 1/draft-ietf-v6ops-nat64-experience-08.txt 2014-01-13 02:14:38.832865314 -0800 +++ 2/draft-ietf-v6ops-nat64-experience-09.txt 2014-01-13 02:14:38.880866503 -0800 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Chen Internet-Draft Z. Cao Intended status: Informational China Mobile -Expires: July 12, 2014 C. Xie +Expires: July 17, 2014 C. Xie China Telecom D. Binet France Telecom-Orange - January 8, 2014 + January 13, 2014 NAT64 Operational Experience - draft-ietf-v6ops-nat64-experience-08 + draft-ietf-v6ops-nat64-experience-09 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 July 12, 2014. + This Internet-Draft will expire on July 17, 2014. Copyright Notice 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 @@ -61,31 +61,31 @@ 3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6 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 + 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 13 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 12. Additional Author List . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 18 - Appendix A. Testing Results of Application Behavior . . . . . . 20 + Appendix A. Testing Results of Application Behavior . . . . . . 21 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 networks @@ -180,21 +180,25 @@ compared to NAT44(if used), on which all traffic flows have to be traversed and translated. In some cases, NAT64-CGN may serve double roles, i.e. a translator and IPv6 forwarder. In mobile networks, NAT64 is likely deployed as the default gateway serving for all the IPv6 traffic. The traffic heading to a dual-stack server is only forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested to be configured on the Internet faced interfaces of NAT64. We tested on Top100 websites (referring to [Alexa] statistics). 43% of websites are connected and forwarded on the NAT64 since those websites have both AAAA and A records. With expansion of IPv6 - supports, the translation process on NAT64 will likely be faded. + supports, the translation process on NAT64 will likely be faded. In + addition, it should be noted the DNS64-DNSSEC Interaction[RFC6147] + may impact the DNS64 process. For example, DNS64 will not work with + the case, 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 All connections to IPv4 services from IPv6-only clients must traverse the NAT64-CGN. It can be advantageous from the vantage-point of troubleshooting and traffic engineering to carry the IPv6 traffic natively for as long as possible within an access network and translate packets only at or near the network egress. NAT64 can be considered as a feature of the Autonomous System (AS) border in fixed networks. And, it is likely to be deployed in an IP node beyond the @@ -415,24 +419,25 @@ Traceability is required in many cases such as identifying malicious attacks sources and accounting requirements. Operators are asked to record the NAT64 log information for specific periods of time. In our lab testing, the log information from 200,000 subscribers have been collected from a stateful NAT64 gateway for 60 days. Syslog[RFC5424] has been adopted to transmit log message from NAT64 to a log station. Each log message contains transport protocol, source IPv6 address:port, translated IPv4 address: port and timestamp. It takes almost 125 bytes long in ASCII format. It has - been verified that the volume of recorded information reach up to - 42.5 terabytes in the raw format and 29.07 terabytes in a compact - format. Operators have to build up dedicated transport links, - storage system and servers for the purpose. + been verified that the rate of traffic flow is around 72 thousand + flows per second and the volume of recorded information reaches up to + 42.5 terabytes in the raw format. The volume takes 29.07 terabytes + in a compact format. Operators have to build up dedicated transport + links, storage system and servers for the purpose. There are also several implementations to mitigate the issue. For example, stateful NAT64 could configure with bulk port allocation method. Once a subscriber creates the first session, a number of ports are pre-allocated. A bulk allocation message is logged indicating this allocation. Subsequent session creations will 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 port allocation. Some implementations may adopt static port-range allocations [I-D.donley-behave-deterministic-cgn] which eliminates @@ -662,41 +666,46 @@ address selection in order to steer traffic flows going through NAT64-CGN. However, it involves significant costs to change terminal's behavior. Therefore, operators are not suggested to configure ULAs on a NAT64-CGN. ULAs can't work when hosts transit the Internet to connect with NAT64. Therefore, ULAs are inapplicable to the case of NAT64-FE. 9. Security Considerations - his document presents the deployment experiences of NAT64 in CGN and + This document presents the deployment experiences of NAT64 in CGN and FE scenarios. In general, RFC 6146[RFC6146] provides TCP-tracking, address-dependent filtering mechanisms to protect NAT64 from Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and black/white-list to enhance the security by specifying access policies. For example, NAT64-CGN should forbid establish NAT64 BIB for incoming IPv6 packets if uRPF in Strict or Loose mode check does not pass or whose source IPv6 address is associated to black-lists. The stateful NAT64-FE creates state and maps that connection to an internally-facing IPv4 address and port. An attacker can consume the resources of the NAT64-FE device by sending an excessive number of connection attempts. Without a DDoS limitation mechanism, the NAT64-FE is exposed to attacks. Load Balancer is recommended to enable the capabilities of line rate DDOS defense, such as the employment of SYN PROXY-COOKIE. Security domain division is necessary as well in this case. Therefore, Load Balancers could not only serve for optimization of traffic distribution, but also prevent service from quality deterioration due to security attacks. + The DNS64 process will potentially interfere with the DNSSEC + functions[RFC4035], since DNS response is modified and DNSSEC intends + to prevent such changes. More detailed discussions can be found in + [RFC6147]. + 10. IANA Considerations This memo includes no request to IANA. 11. Acknowledgements The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley, Tim Chown, Gert Doering and Simon Perreault for their helpful @@ -748,20 +757,24 @@ 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. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005. + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 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