draft-ietf-v6ops-nat64-experience-08.txt   draft-ietf-v6ops-nat64-experience-09.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: July 12, 2014 C. Xie Expires: July 17, 2014 C. Xie
China Telecom China Telecom
D. Binet D. Binet
France Telecom-Orange France Telecom-Orange
January 8, 2014 January 13, 2014
NAT64 Operational Experience NAT64 Operational Experience
draft-ietf-v6ops-nat64-experience-08 draft-ietf-v6ops-nat64-experience-09
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 July 12, 2014. This Internet-Draft will expire on July 17, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5 3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5
3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6
4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7
4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9
5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9
5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 13
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
12. Additional Author List . . . . . . . . . . . . . . . . . . . 16 12. Additional Author List . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . 18 13.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Testing Results of Application Behavior . . . . . . 20 Appendix A. Testing Results of Application Behavior . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
IPv6 is the only sustainable solution for numbering nodes on Internet IPv6 is the only sustainable solution for numbering nodes on Internet
due to the IPv4 depletion. Network operators have to deploy due to the IPv4 depletion. Network operators have to deploy
IPv6-only networks in order to meet the needs of the expanding IPv6-only networks in order to meet the needs of the expanding
internet without available IPv4 addresses. internet without available IPv4 addresses.
Single stack IPv6 network deployment can simplify networks Single stack IPv6 network deployment can simplify networks
skipping to change at page 4, line 49 skipping to change at page 4, line 49
compared to NAT44(if used), on which all traffic flows have to be compared to NAT44(if used), on which all traffic flows have to be
traversed and translated. In some cases, NAT64-CGN may serve double traversed and translated. In some cases, NAT64-CGN may serve double
roles, i.e. a translator and IPv6 forwarder. In mobile networks, roles, i.e. a translator and IPv6 forwarder. In mobile networks,
NAT64 is likely deployed as the default gateway serving for all the NAT64 is likely deployed as the default gateway serving for all the
IPv6 traffic. The traffic heading to a dual-stack server is only IPv6 traffic. The traffic heading to a dual-stack server is only
forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested
to be configured on the Internet faced interfaces of NAT64. We to be configured on the Internet faced interfaces of NAT64. We
tested on Top100 websites (referring to [Alexa] statistics). 43% of tested on Top100 websites (referring to [Alexa] statistics). 43% of
websites are connected and forwarded on the NAT64 since those websites are connected and forwarded on the NAT64 since those
websites have both AAAA and A records. With expansion of IPv6 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 3.1.3. NAT64 Placement
All connections to IPv4 services from IPv6-only clients must traverse All connections to IPv4 services from IPv6-only clients must traverse
the NAT64-CGN. It can be advantageous from the vantage-point of the NAT64-CGN. It can be advantageous from the vantage-point of
troubleshooting and traffic engineering to carry the IPv6 traffic troubleshooting and traffic engineering to carry the IPv6 traffic
natively for as long as possible within an access network and natively for as long as possible within an access network and
translate packets only at or near the network egress. NAT64 can be translate packets only at or near the network egress. NAT64 can be
considered as a feature of the Autonomous System (AS) border in fixed 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 networks. And, it is likely to be deployed in an IP node beyond the
skipping to change at page 9, line 47 skipping to change at page 9, line 49
Traceability is required in many cases such as identifying malicious Traceability is required in many cases such as identifying malicious
attacks sources and accounting requirements. Operators are asked to attacks sources and accounting requirements. Operators are asked to
record the NAT64 log information for specific periods of time. In record the NAT64 log information for specific periods of time. In
our lab testing, the log information from 200,000 subscribers have our lab testing, the log information from 200,000 subscribers have
been collected from a stateful NAT64 gateway for 60 days. been collected from a stateful NAT64 gateway for 60 days.
Syslog[RFC5424] has been adopted to transmit log message from NAT64 Syslog[RFC5424] has been adopted to transmit log message from NAT64
to a log station. Each log message contains transport protocol, to a log station. Each log message contains transport protocol,
source IPv6 address:port, translated IPv4 address: port and source IPv6 address:port, translated IPv4 address: port and
timestamp. It takes almost 125 bytes long in ASCII format. It has timestamp. It takes almost 125 bytes long in ASCII format. It has
been verified that the volume of recorded information reach up to been verified that the rate of traffic flow is around 72 thousand
42.5 terabytes in the raw format and 29.07 terabytes in a compact flows per second and the volume of recorded information reaches up to
format. Operators have to build up dedicated transport links, 42.5 terabytes in the raw format. The volume takes 29.07 terabytes
storage system and servers for the purpose. 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 There are also several implementations to mitigate the issue. For
example, stateful NAT64 could configure with bulk port allocation example, stateful NAT64 could configure with bulk port allocation
method. Once a subscriber creates the first session, a number of method. Once a subscriber creates the first session, a number of
ports are pre-allocated. A bulk allocation message is logged ports are pre-allocated. A bulk allocation message is logged
indicating this allocation. Subsequent session creations will use indicating this allocation. Subsequent session creations will use
one of the pre-allocated port and hence does not require logging. 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 The log volume in this case may be only one thousandth of dynamic
port allocation. Some implementations may adopt static port-range port allocation. Some implementations may adopt static port-range
allocations [I-D.donley-behave-deterministic-cgn] which eliminates allocations [I-D.donley-behave-deterministic-cgn] which eliminates
skipping to change at page 15, line 7 skipping to change at page 15, line 10
address selection in order to steer traffic flows going through address selection in order to steer traffic flows going through
NAT64-CGN. However, it involves significant costs to change NAT64-CGN. However, it involves significant costs to change
terminal's behavior. Therefore, operators are not suggested to terminal's behavior. Therefore, operators are not suggested to
configure ULAs on a NAT64-CGN. configure ULAs on a NAT64-CGN.
ULAs can't work when hosts transit the Internet to connect with ULAs can't work when hosts transit the Internet to connect with
NAT64. Therefore, ULAs are inapplicable to the case of NAT64-FE. NAT64. Therefore, ULAs are inapplicable to the case of NAT64-FE.
9. Security Considerations 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, FE scenarios. In general, RFC 6146[RFC6146] provides TCP-tracking,
address-dependent filtering mechanisms to protect NAT64 from address-dependent filtering mechanisms to protect NAT64 from
Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators
also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and
black/white-list to enhance the security by specifying access black/white-list to enhance the security by specifying access
policies. For example, NAT64-CGN should forbid establish NAT64 BIB policies. For example, NAT64-CGN should forbid establish NAT64 BIB
for incoming IPv6 packets if uRPF in Strict or Loose mode check does 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. not pass or whose source IPv6 address is associated to black-lists.
The stateful NAT64-FE creates state and maps that connection to an The stateful NAT64-FE creates state and maps that connection to an
internally-facing IPv4 address and port. An attacker can consume the internally-facing IPv4 address and port. An attacker can consume the
resources of the NAT64-FE device by sending an excessive number of resources of the NAT64-FE device by sending an excessive number of
connection attempts. Without a DDoS limitation mechanism, the connection attempts. Without a DDoS limitation mechanism, the
NAT64-FE is exposed to attacks. Load Balancer is recommended to NAT64-FE is exposed to attacks. Load Balancer is recommended to
enable the capabilities of line rate DDOS defense, such as the enable the capabilities of line rate DDOS defense, such as the
employment of SYN PROXY-COOKIE. Security domain division is employment of SYN PROXY-COOKIE. Security domain division is
necessary as well in this case. Therefore, Load Balancers could not necessary as well in this case. Therefore, Load Balancers could not
only serve for optimization of traffic distribution, but also prevent only serve for optimization of traffic distribution, but also prevent
service from quality deterioration due to security attacks. 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 10. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
11. Acknowledgements 11. Acknowledgements
The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, The authors would like to thank Jari Arkko, Dan Wing, Remi Despres,
Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy
Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley, Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley,
Tim Chown, Gert Doering and Simon Perreault for their helpful Tim Chown, Gert Doering and Simon Perreault for their helpful
skipping to change at page 16, line 48 skipping to change at page 17, line 9
Networks", BCP 84, RFC 3704, March 2004. Networks", BCP 84, RFC 3704, March 2004.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005. January 2005.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC
3948, January 2005. 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 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April Traversal for Offer/Answer Protocols", RFC 5245, April
 End of changes. 11 change blocks. 
12 lines changed or deleted 26 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/