NAT64 Deployment Considerations
draft-ietf-v6ops-nat64-experience-01
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 7269.
|
|
---|---|---|---|
Authors | Gang Chen , Zhen Cao , Cameron Byrne , Chongfeng Xie , David Binet | ||
Last updated | 2013-01-31 | ||
Replaces | draft-chen-v6ops-nat64-experience | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 7269 (Informational) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-v6ops-nat64-experience-01
gt; Figure 2: NAT64-FE Scenario: IPv6 Internet/Network to IPv4 Network 4.1. NAT64-FE Networking There are plenty of practices to equip load balancer with NAT64 at front of servers. Two different cases appeared in the NAT64-FE networking. o Some content providers who has a wealth of IPv6 experiences consider IPv6-only strategy to serve customers since it allows new services delivery without having to integrate consideration of IPv4 NAT and address limitations of IPv4 networks. Whereas they have to provide some IPv4 service continuity to their customers, stateless IP/ICMP Translation (SIIT) [RFC6145]has been used to continue provide services for IPv4 subscribers. o ICPs who have insufficient IPv6 incentive likely prefer short-term alternatives to provide IPv6 connectivity due to the widespread impact of supporting IPv6 within a ICP environment. A stateful NAT64 has been located at front of servers. It could simultaneously facilitate the IPv6 accessibility and conservation of IPv4 servers. [I-D.ietf-v6ops-icp-guidance]has described the cases, in which an HTTP proxy can readily be configured to handle incoming connections over IPv6 and to proxy them to a server over IPv4. For first case, [I-D.anderson-siit-dc]has provided further descriptions and guidelines. This document is addressed to second Chen, et al. Expires August 4, 2013 [Page 9] Internet-Draft NAT64 Deployment January 2013 case. An administrator of the IPv4 network needs to be cautious and aware of the operational issues in the case since the native IPv6 is always more desirable than transition solutions. One potential challenge is stateful NAT64-FE facing IPv6 Internet, in which a significant number of IPv6 users may initiate connections. When increasingly numerous users in IPv6 Internet access an IPv4 network, scalability concerns(e.g. additional latency, a single point of failure, IPv4 pool exhaustion, etc) are apt to be applied. For a given off-the-shelf NAT64-FE, those challenges should be seriously assessed. Potential issues should be properly identified. Following subsections described several considerations to stateful NAT64-FE case. For operators who seek a clear precedent for operating reliable IPv6-only services, it should be well noted that the usage is problematic. 4.2. Source Address Traceability IP addresses are usually used as input to geo-location services. The use of address sharing will prevent these systems from resolving the location of a host based on IP address alone. Applications that assume such geographic information may not work as intended. The possible solutions listed at section 3.3 intended to bridge the gap. However, the analysis reveals those solutions can't be a optimal substitution to solve the problem of host identification, in particular it does not today mitigate problems with source identification through translation. That makes NAT64-FE usage becoming a unappealing approach, if customers require source address tracking. For the operators, who already deployed NAT64-FE approach, the source address of the request is obscured without the source address mapping information previously obtained. It's superior to present mapping information directly to applications. Some application layer proxies e.g. XFF (X-Forwarded-For) , can convey this information in-band. Another approach is to ask application coordinating the information with NAT logging. But that is not sufficient, since the applications itself wants to know the original source address from an application message bus. The logging information may be used by administrators offline to inspect use behavior and preference analysis, and accurate advertisement delivery. 4.3. DNS Resolving In the case of NAT64-FE, it is recommended to follow the recommendations in [RFC6144]. There is no need for the DNS to synthesize AAAA from A records, since static AAAA records can be Chen, et al. Expires August 4, 2013 [Page 10] Internet-Draft NAT64 Deployment January 2013 registered in the authoritative DNS for a given domain to represent these IPv4-only hosts. How to design the FQDN for the IPv6 service is out-of-scope of this document. 4.4. Load Balancer Load balancing on NAT64-FE has a couple of considerations. If dictated by scale or availability requirements traffic should be balanced among multiple NAT64-CE devices. One point to be noted is that synthetic AAAA records may be added directly in authoritative DNS. load balancing based on DNS64 synthetic resource records may not work in those cases. Secondly, NAT64-FE could also serve as the load balancer for IPv4 backend servers. There are also some ways of load balance for the cases, where load balancer is placed in front of NAT64-FE. 4.5. MTU Consideration As compared to the MTU consideration in NAT64-CGN, the MTU of IPv4 network are strongly recommended to set to more than 1260. Since a IPv4 network is normally operated by a particular administrative entity, it should take steps to prevent the risk of fragmentation discussed in [I-D.ietf-6man-ipv6-atomic-fragments]. 4.6. Anti-DDoS/SYN Flood For every incoming new connection from the IPv6 Internet, 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. With service provisioning, attacks have the potential could also deteriorate service quality. One consideration in internet content providers is place a L3 load balancer with capable of line rate DDOS defense, such as the employment of SYN PROXY-COOKIE. Security domain division is necessary in this case. Load Balancers could not only serve for optimization of traffic distribution, but also serve as a DOS mitigation device. 5. Security Considerations This document presents the deployment experiences of NAT64 in CGN and FE scenario, some security considerations are described in detail regarding to specific NAT64 mode in section 3 and 4. In general, RFC 6146[RFC6146] provides TCP-tracking, address-dependent filtering mechanisms to protect NAT64 from DDOS. In NAT64-CGN cases, ISP also Chen, et al. Expires August 4, 2013 [Page 11] Internet-Draft NAT64 Deployment January 2013 could adopt uRPF 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 (Strict or Loose mode) check does not pass or whose source IPv6 address is associated to black-lists. 6. IANA Considerations This memo includes no request to IANA. 7. Acknowledgements The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum and Philip Matthews for their helpful comments. Many thanks to Wesley George and Satoru Matsushima for their reviews. The authors especially thank Joel Jaeggli for his efforts and contributions on editing which substantially improves the legibility of the document. 8. Additional Author List The following are extended authors who contributed to the effort: Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100035 P.R.China Phone: +86-10-58552936 Email: sunqiong@ctbri.com.cn QiBo Niu ZTE 50,RuanJian Road. YuHua District, Nan Jing 210012 P.R.China Email: niu.qibo@zte.com.cn 9. References Chen, et al. Expires August 4, 2013 [Page 12] Internet-Draft NAT64 Deployment January 2013 9.1. Normative References [I-D.ietf-pcp-base] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", draft-ietf-pcp-base-29 (work in progress), November 2012. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [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. [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 9.2. Informative References [I-D.anderson-siit-dc] Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data Centre Environments", draft-anderson-siit-dc-00 (work in progress), November 2012. [I-D.donley-behave-deterministic-cgn] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", draft-donley-behave-deterministic-cgn-05 (work in progress), January 2013. [I-D.ietf-6man-ipv6-atomic-fragments] Gont, F., "Processing of IPv6 "atomic" fragments", draft-ietf-6man-ipv6-atomic-fragments-03 (work in progress), December 2012. [I-D.ietf-appsawg-http-forwarded] Chen, et al. Expires August 4, 2013 [Page 13] Internet-Draft NAT64 Deployment January 2013 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", draft-ietf-appsawg-http-forwarded-10 (work in progress), October 2012. [I-D.ietf-behave-nat64-learn-analysis] Korhonen, J. and T. Savolainen, "Analysis of solution proposals for hosts to learn NAT64 prefix", draft-ietf-behave-nat64-learn-analysis-03 (work in progress), March 2012. [I-D.ietf-intarea-nat-reveal-analysis] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments", draft-ietf-intarea-nat-reveal-analysis-04 (work in progress), August 2012. [I-D.ietf-v6ops-464xlat] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", draft-ietf-v6ops-464xlat-09 (work in progress), January 2013. [I-D.ietf-v6ops-icp-guidance] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content and Application Service Providers", draft-ietf-v6ops-icp-guidance-05 (work in progress), January 2013. [I-D.zhang-behave-nat64-load-balancing] Zhang, D., Xu, X., and M. Boucadair, "Considerations on NAT64 Load-Balancing", draft-zhang-behave-nat64-load-balancing-03 (work in progress), July 2011. [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. [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. Chen, et al. Expires August 4, 2013 [Page 14] Internet-Draft NAT64 Deployment January 2013 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012. Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: phdgang@gmail.com Zhen Cao China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: caozhen@chinamobile.com Cameron Byrne T-Mobile USA Bellevue Washington 98105 USA Email: cameron.byrne@t-mobile.com Chongfeng Xie China Telecom Room 708 No.118, Xizhimenneidajie Beijing 100035 P.R.China Email: xiechf@ctbri.com.cn Chen, et al. Expires August 4, 2013 [Page 15] Internet-Draft NAT64 Deployment January 2013 David Binet France Telecom Rennes 35000 France Email: david.binet@orange.com Chen, et al. Expires August 4, 2013 [Page 16]