draft-ietf-v6ops-nat64-experience-03.txt | draft-ietf-v6ops-nat64-experience-04.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: April 05, 2014 C. Xie | Expires: April 17, 2014 C. Xie | |||
China Telecom | China Telecom | |||
D. Binet | D. Binet | |||
France Telecom-Orange | France Telecom-Orange | |||
October 02, 2013 | October 14, 2013 | |||
NAT64 Operational Experiences | NAT64 Operational Experiences | |||
draft-ietf-v6ops-nat64-experience-03 | draft-ietf-v6ops-nat64-experience-04 | |||
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 April 05, 2014. | This Internet-Draft will expire on April 17, 2014. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 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 33 | skipping to change at page 2, line 33 | |||
5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 | 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 | |||
6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 10 | 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 10 | |||
6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 | 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 | |||
6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11 | 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11 | |||
7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12 | 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12 | |||
8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 | |||
12. Additional Author List . . . . . . . . . . . . . . . . . . . 14 | 12. Additional Author List . . . . . . . . . . . . . . . . . . . 14 | |||
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
13.1. Normative References . . . . . . . . . . . . . . . . . . 15 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 | |||
13.2. Informative References . . . . . . . . . . . . . . . . . 16 | 13.2. Informative References . . . . . . . . . . . . . . . . . 16 | |||
Appendix A. Testing Results of Application Behavior . . . . . . 18 | Appendix A. Testing Results of Application Behavior . . . . . . 18 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
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 | |||
skipping to change at page 13, line 19 | skipping to change at page 13, line 19 | |||
The use of ULAs could help in identifying the translation | The use of ULAs could help in identifying the translation | |||
traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided | traffic.[I-D.ietf-v6ops-ula-usage-recommendations] has provided | |||
further guidance for the ULAs usages. | further guidance for the ULAs usages. | |||
We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is | 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 | only assigned with an IPv6 address and connected to NAT64-CGN, when | |||
connect to an IPv4 service, it would receive AAAA record generated by | connect to an IPv4 service, it would receive AAAA record generated by | |||
the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will | the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will | |||
be selected as the source address to the ULA destination address. | be selected as the source address to the ULA destination address. | |||
When the host has both IPv4 and IPv6 address, it would initiate both | When the host has both IPv4 and IPv6 address, it would initiate both | |||
A and AAAA record lookup may due to Happy Eyeballs [RFC6555], then | A and AAAA record lookup, then both original A record and | |||
both original A record and DNS64-generated AAAA record would be | DNS64-generated AAAA record would be received. A host, which is | |||
received. The host would prefer the AAAA record as the destination, | compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4 | |||
if the address selection process still follows the recommendation of | path will be always selected. It may be undesirable because the | |||
[RFC3484]. While, if the host implements the default policy table as | NAT64-CGN will never be used. Operators may consider to add | |||
defined in [RFC6724], since the IPv4 takes the precedence over ULA | additional site-specific rows to the default table to steer traffic | |||
(which is difference than [RFC3484]), an IPv4 path will be always | flows going through NAT64-CGN. However, it involves significant | |||
preferred. It may be undesirable because the traffic path is | costs to change terminal's behavior. Therefore, operators are not | |||
unexpected due to vary implementations on hosts. Operators have to | suggested to configure ULAs on a NAT64-CGN. | |||
make site-specific rules to gauge the host's behaviors, which may | ||||
likely add the operational complexity. | ||||
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 | his 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 | |||
skipping to change at page 17, line 22 | skipping to change at page 17, line 19 | |||
[I-D.donley-behave-deterministic-cgn] | [I-D.donley-behave-deterministic-cgn] | |||
Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., | Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., | |||
and O. Vautrin, "Deterministic Address Mapping to Reduce | and O. Vautrin, "Deterministic Address Mapping to Reduce | |||
Logging in Carrier Grade NAT Deployments", draft-donley- | Logging in Carrier Grade NAT Deployments", draft-donley- | |||
behave-deterministic-cgn-06 (work in progress), July 2013. | behave-deterministic-cgn-06 (work in progress), July 2013. | |||
[I-D.ietf-softwire-4rd] | [I-D.ietf-softwire-4rd] | |||
Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and | Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and | |||
M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless | M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless | |||
Solution (4rd)", draft-ietf-softwire-4rd-06 (work in | Solution (4rd)", draft-ietf-softwire-4rd-07 (work in | |||
progress), July 2013. | progress), October 2013. | |||
[I-D.ietf-softwire-map-deployment] | [I-D.ietf-softwire-map-deployment] | |||
Sun, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, | Sun, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, | |||
"Mapping of Address and Port (MAP) - Deployment | "Mapping of Address and Port (MAP) - Deployment | |||
Considerations", draft-ietf-softwire-map-deployment-02 | Considerations", draft-ietf-softwire-map-deployment-02 | |||
(work in progress), July 2013. | (work in progress), July 2013. | |||
[I-D.ietf-softwire-map-t] | [I-D.ietf-softwire-map-t] | |||
Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and | Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and | |||
T. Murakami, "Mapping of Address and Port using | T. Murakami, "Mapping of Address and Port using | |||
End of changes. 7 change blocks. | ||||
18 lines changed or deleted | 16 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/ |