--- 1/draft-ietf-v6ops-nat64-experience-09.txt 2014-03-10 20:14:35.287397827 -0700 +++ 2/draft-ietf-v6ops-nat64-experience-10.txt 2014-03-10 20:14:35.335398990 -0700 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Chen Internet-Draft Z. Cao Intended status: Informational China Mobile -Expires: July 17, 2014 C. Xie +Expires: September 11, 2014 C. Xie China Telecom D. Binet France Telecom-Orange - January 13, 2014 + March 10, 2014 - NAT64 Operational Experience - draft-ietf-v6ops-nat64-experience-09 + NAT64 Deployment Options and Experience + draft-ietf-v6ops-nat64-experience-10 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 17, 2014. + This Internet-Draft will expire on September 11, 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,350 +61,347 @@ 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 . . . . . . . . . . . . . . . . . . 13 + 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 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 . . . . . . 21 + 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 networks - provisioning. Some justifications have been described in 464xlat - [RFC6877]. As an example, IPv6-only connectivity confers some - benefits to mobile operators. In such mobile context, it enables the - use of a single IPv6 Packet Data Protocol(PDP) context or Evolved - Packet System (EPS) bearer if Long Term Evolution (LTE) network is - considered, which eliminates significant network costs caused by - doubling the number of PDP contexts in some cases and the need of - IPv4 addresses to be assigned to customers. In broadband networks - overall, it can allow for the scaling of edge-network growth - decoupled from IPv4 numbering limitations. + Single-stack IPv6 network deployment can simplify networks + provisioning, some justification was provided in 464xlat [RFC6877]. + IPv6-only connectivity confers some benefits to mobile operators as + an example. In the mobile context, IPv6-only usage enables the use + of a single IPv6 Packet Data Protocol(PDP) context or Evolved Packet + System (EPS) bearer on Long Term Evolution (LTE) networks. This + eliminates significant network costs caused by employing two PDP + contexts in some cases, and the need for IPv4 addresses to be + assigned to customers. In broadband networks overall, it can allow + for the scaling of edge-network growth to be decoupled from IPv4 + numbering limitations. - In a transition scenario, some existing networks are likely to be - IPv4-only configured for quite a long time. IPv6 networks and hosts - will need to coexist with IPv4 numbered resources. Widespread dual- - stack deployments have not materialized at the anticipated rate over - the last 10 years, one possible conclusion being that legacy networks - will not make the jump quickly. The Internet will include nodes that - are dual-stack, nodes that remain IPv4-only, and nodes that can be - deployed as IPv6-only nodes. A translation mechanism based on a - NAT64[RFC6146] [RFC6145]function is likely to be a key element of the - Internet for IPv6-IPv4 interoperability. + In transition scenarios, some existing networks are likely to be + IPv4-only for quite a long time. IPv6 networks and hosts IPv6-only + hosts will need to coexist with IPv4 numbered resources. Widespread + dual-stack deployments have not materialized at the anticipated rate + over the last 10 years, one possible conclusion being that legacy + networks will not make the jump quickly. The Internet will include + nodes that are dual-stack, nodes that remain IPv4-only, and nodes + that can be deployed as IPv6-only nodes. A translation mechanism + based on a NAT64[RFC6146] [RFC6145]function is likely to be a key + element of Internet connectivity for IPv6-IPv4 interoperability. [RFC6036] reports at least 30% of operators plan to run some kind of translator (presumably NAT64/DNS64). Advice on NAT64 deployment and operations are therefore of some importance. [RFC6586] documents the implications for IPv6 only networks. This document intends to be specific to NAT64 network planning. 2. Terminology - In regards to IPv4/IPv6 translation, [RFC6144] has described a - framework of enabling networks to make interworking possible between - IPv4 and IPv6 networks. This document has further categorized - different NAT64 function locations and use cases. The principle - distinction of location is if the NAT64 is located in a Carrier Grade - NAT or server Front End. The terms of NAT-CGN/FE are understood to be - a topological distinction indicating different features employed in a + Regarding IPv4/IPv6 translation, [RFC6144] has described a framework + for enabling networks to make interworking possible between IPv4 and + IPv6 networks. This document has further categorized different NAT64 + functions, locations and use-cases. The principle distinction of + location is whether the NAT64 is located in a Carrier Grade NAT or + server Front End. The terms of NAT-CGN/FE are understood to be a + topological distinction indicating different features employed in a NAT64 deployment. NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP - network. IPv6 subscribers leverage the NAT64-CGN to access - existing IPv4 internet services. The ISP as an administrative - entity takes full control on the IPv6 side, but has limited or no - control on the IPv4 side. NAT64-CGN may have to consider the IPv4 - Internet environment and services to make appropriate - configurations. + network. IPv6 enabled subscribers leverage the NAT64-CGN to + access existing IPv4 internet services. The ISP as an + administrative entity takes full control of the IPv6 side, but has + limited or no control on the IPv4 internet side. NAT64-CGN + deployments may have to consider the IPv4 Internet environment and + services, and make appropriate configuration choices accordingly. NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device with NAT64 functionality in a content provider or data center network. It could be for example a traffic load balancer or a firewall. The operator of the NAT64-FE has full control over the IPv4 network within the data center, but only limited influence or - control over the external IPv6 network. + control over the external Internet IPv6 network. 3. NAT64 Networking Experience 3.1. NAT64-CGN Consideration 3.1.1. NAT64-CGN Usages - Fixed network operators and mobile operators may locate NAT64 in - access networks or in mobile core networks. It can be built into - various devices, including routers, gateways or firewalls in order to - connect IPv6 users to the IPv4 Internet. With regard to the numbers - of users and the shortage of public IPv4 addresses, stateful - NAT64[RFC6146] is more adapted to perform some maximal sharing of - public IPv4 addresses. The usage of stateless NAT64 can be seen with - better transparency features - [I-D.ietf-softwire-stateless-4v6-motivation], while it has to be - coordinated with A+P[RFC6346] processes as specified in - [I-D.ietf-softwire-map-t] in order to cope with IPv4 shortage. + Fixed network operators and mobile operators may locate NAT64 + translators in access networks or in mobile core networks. It can be + built into various devices, including routers, gateways or firewalls + in order to connect IPv6 users to the IPv4 Internet. With regard to + the numbers of users and the shortage of public IPv4 addresses, + stateful NAT64[RFC6146] is more suited to maximize sharing of public + IPv4 addresses. The usage of stateless NAT64 can provide better + transparency features [I-D.ietf-softwire-stateless-4v6-motivation], + but has to be coordinated with A+P[RFC6346] processes as specified in + [I-D.ietf-softwire-map-t] in order to address an IPv4 address + shortage. 3.1.2. DNS64 Deployment DNS64[RFC6147] is recommended for use in combination with stateful NAT64, and will likely be an essential part of an IPv6 single-stack - network that couples to the IPv4 Internet. 464xlat[RFC6877] is - proposed to enable access of IPv4 only applications or applications - that call IPv4 literal addresses. Using DNS64 will help 464xlat to + network that couples to the IPv4 Internet. 464xlat[RFC6877] can + enable access of IPv4 only applications or applications that call + IPv4 literal addresses. Using DNS64 will help 464xlat to automatically discover NAT64 prefix through [RFC7050]. Berkeley Internet Name Daemon (BIND) software supports the function. It's important to note that DNS64 generates the synthetic AAAA reply when - services only register A records. Operators should not expect to + services only provide A records. Operators should not expect to access IPv4 parts of a dual-stack server using NAT64/DNS64. The traffic is forwarded on IPv6 paths if dual-stack servers are - targeted. IPv6 traffic may be routed not going through NAT64. Only - the traffic going to IPv4-only service would traverse NAT64. In some - sense, it encourages IPv6 transmission and restrains NAT uses - 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 + targeted. IPv6 traffic may be routed around rather than going + through NAT64. Only the traffic going to IPv4-only service would + traverse the NAT64 translator. In some sense, it encourages IPv6 + usage and limits NAT translation compared to employing NAT44, where + all traffic flows have to be translated. In some cases, NAT64-CGNs + may serve double roles, i.e. as a translator and IPv6 forwarder. In + mobile networks, NAT64 may be deployed as the default gateway serving + 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. 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. + support, the translation process on NAT64 will likely become less- + important over time. It should be noted the DNS64-DNSSEC + Interaction[RFC6147] may impact validation of Resource Records + retrieved from the the DNS64 process. In particular, DNSSEC + validation will fail when DNS64 synthesizes AAAA records 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 - Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway - (PDN-GW) in mobile networks or directly in the gateway itself in some - situations. This allows consistent attribution and traceability - within the service provider network. It has been observed that the - process of correlating log information is problematic from multiple- - vendor's equipment due to inconsistent formats of log records. - Placing NAT64 in a centralized location may reduce diversity of log - format and simplify the network provisioning. Moreover, since NAT64 - is only targeted at serving traffic flows from IPv6 to IPv4-only - services, the user traffic volume should not be as high as in a NAT44 - scenario, and therefore, the gateway's capacity in such location may - not be as much of a concern or a hurdle to deployment. On the other - hand, the placement in a centralized way would require more strict - high availability (HA) design. It would also make geo-location based - on IPv4 addresses rather inaccurate as it is currently the case for - NAT44 CGN already deployed in ISP networks. More considerations or - workarounds on HA and traceability could be found at Section 4 and - Section 5. + translate packets only at or near the network egress. NAT64 may be a + feature of the Autonomous System (AS) border in fixed networks. It + may be deployed in an IP node beyond the Gateway GPRS Support Node + (GGSN) or Public Data Network- Gateway (PDN-GW) in mobile networks or + directly as part of the gateway itself in some situations. This + allows consistent attribution and traceability within the service + provider network. It has been observed that the process of + correlating log information is problematic from multiple-vendor's + equipment due to inconsistent formats of log records. Placing NAT64 + in a centralized location may reduce diversity of log format and + simplify the network provisioning. Moreover, since NAT64 is only + targeted at serving traffic flows from IPv6 to IPv4-only services, + the user traffic volume should not be as high as in a NAT44 scenario, + and therefore, the gateway's capacity in such location may be less of + a concern or a hurdle to deployment. On the other-hand, placement in + a centralized fashion would require more strict high availability + (HA) design. It would also make geo-location based on IPv4 addresses + rather inaccurate as is currently the case for NAT44 CGN already + deployed in ISP networks. More considerations or workarounds on HA + and traceability could be found at Section 4 and Section 5. 3.1.4. Co-existence of NAT64 and NAT44 - NAT64 could likely co-exist with NAT44 in a dual-stack network mostly - because IPv4 private addresses are allocated to customers. The - coexistence has already appeared in mobile networks, in which dual - stack mobile phones normally initiate some dual-stack PDN/PDP - Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated - addresses are very often private ones. [RFC6724] always prioritizes - IPv6 connections regardless of whether the end-to-end path is native - IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy + NAT64 will likely co-exist with NAT44 in a dual-stack network where + IPv4 private addresses are allocated to customers. The coexistence + has already been observed in mobile networks, in which dual stack + mobile phones normally initiate some dual-stack PDN/PDP Type[RFC6459] + to query both IPv4/IPv6 address and IPv4 allocated addresses are very + often private ones. [RFC6724] always prioritizes IPv6 connections + regardless of whether the end-to-end path is native IPv6 or IPv6 + translated to IPv4 via NAT64/DNS64. Conversely, Happy Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The selection of IPv4/IPv6 paths may depend on particular implementation choices or settings on a host-by-host basis, and may differ from an operator's deterministic scheme. Our tests verified that hosts may find themselves switching between IPv4 and IPv6 paths as they access identical service, but at different times [I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each - path is different, it may cause unstable user experiences and some - degradation of Quality of Experience (QoE) when fallback to the other - protocol is not powerful enough. It's also difficult for operators - to find a solution to make a stable network with optimal resource - utilization. In general, it's desirable to figure out the solution - that will introduce IPv6/IPv4 translation service to IPv6-only hosts - connecting to IPv4 servers while making sure dual-stack hosts to have - at least one address family accessible via native service if it's - possible. With the end-to-end native IPv6 environment is available, - hosts should be upgraded aggressively to migrate to IPv6-only. There - is an ongoing effort to detect host connectivity and propose new - DHCPv6 option[I-D.wing-dhc-dns-reconfigure] to convey appropriate + path is potentially different, it may cause unstable user experience + and some degradation of Quality of Experience (QoE) when falling back + to the other protocol. It's also difficult for operators to find a + solution to make a stable network with optimal resource utilization. + In general, it's desirable to figure out the solution that will + introduce IPv6/IPv4 translation service to IPv6-only hosts connecting + to IPv4 servers while making sure dual-stack hosts to have at least + one address family accessible via native service if possible. With + the end-to-end native IPv6 environment available, hosts should be + upgraded aggressively to migrate in favor of IPv6-only. There are + ongoing efforts to detect host connectivity and propose a new DHCPv6 + option[I-D.wing-dhc-dns-reconfigure] to convey appropriate configuration information to the hosts. 3.2. NAT64-FE Consideration Some Internet Content Providers (ICPs) may locate NAT64 in front of - an Internet Data Center (IDC), for example co-located with load - balancing function. Load balancers are employed to connect different - IP family domains, meanwhile distribute workloads across multiple - domains or internal servers actually. In some cases, IPv4 addresses - exhaustion may not be a problem in some IDC's networks. IPv6 support - for some applications may require some investments and workloads so - IPv6 support may not be a priority. The use of NAT64 may be served - to support widespread IPv6 adoption on the Internet while maintaining - IPv4-only applications access. + an Internet Data Center (IDC), for example co-located with a load + -balancing function. Load-balancers are employed to connect + different IP family domains, and distribute workloads across multiple + domains or internal servers. In some cases, IPv4 addresses + exhaustion may not be a problem in some IDC's internal networks. + IPv6 support for some applications may require some investments and + workloads so IPv6 support may not be a priority. The use of NAT64 + may be served to support widespread IPv6 adoption on the Internet + while maintaining IPv4-only applications access. Different strategy has been described in [RFC6883] referred to as "inside out" and "outside in". An IDC operator may implement the - following practices in the NAT64-FE networking. + following practices in the NAT64-FE networking scenario. - o Some ICPs who already have satisfactory operational experiences - would adopt single stack IPv6 operations to build up their data - center network, servers and applications since it allows new - services delivery without having to integrate consideration of - IPv4 NAT and address limitations of IPv4 networks. Stateless - NAT64[RFC6145] is used to provide services for IPv4-only - subscribers. [I-D.anderson-siit-dc] has provided further - descriptions and guidelines. + o Some ICPs who already have satisfactory operational experience + might adopt single stack IPv6 operation in building data-center + networks, servers and applications, as it allows new services + delivery without having to integrate consideration of IPv4 NAT and + address limitations of IPv4 networks. Stateless NAT64[RFC6145] + can used to provide services for IPv4-only enabled customers. + [I-D.anderson-siit-dc] has provided further descriptions and + guidelines. o ICPs who attempt to offer customers IPv6 support in their - application farms at an early stage may likely run some proxies, - which are configured to handle incoming IPv6 flows and proxy them - to IPv4 back-end systems. Many load balancers have already - integrated some proxy functionality. IPv4 addresses configured in - the proxy can be multiplexed like a stateful NAT64 performs. A - similar challenge exists once increasingly numerous users in IPv6 - Internet access an IPv4 network. High loads on load-balancers may - be apt to cause additional latency, IPv4 pool exhaustion, etc. - Therefore, this approach is only reasonable at an early stage. - ICPs may learn from the experiences and move on to dual-stack or - IPv6 single stack in a further stage, since the native IPv6 is - always more desirable than transition solutions. + application farms at an early stage may likely run proxies load- + balancers or translators, which are configured to handle incoming + IPv6 flows and proxy them to IPv4 back-end systems. Many load + balancers integrate proxy functionality. IPv4 addresses + configured in the proxy may be multiplexed like a stateful NAT64 + translator. A similar challenge exists once increasingly numerous + users in IPv6 Internet access an IPv4 network. High loads on + load-balancers may be apt to cause additional latency, IPv4 pool + exhaustion, etc. Therefore, this approach is only reasonable at + an early stage. ICPs may employ dual-stack or IPv6 single stack + in a further stage, since the native IPv6 is frequently more + desirable than any of the transition solutions. [RFC6144] recommends that AAAA records of load-balancers or application servers can be directly registered in the authoritative - DNS servers requiring to populate these servers with corresponding - AAAA records. In this case, there is no need to deploy DNS64 - servers. Those AAAA records can be some native IPv6 addresses or - some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6 - address does not give the possibility to nodes to get any information - about NAT64 presence on communication path and the possibility to - prefer IPv4 path or the IPv6 path in dual-stack networks. For the - testing purpose, operators could use an independent sub domain e.g. + DNS servers. In this case, there is no need to deploy DNS64 name- + servers. Those AAAA records can point to natively assigned IPv6 + addresses or IPv4-converted IPv6 addresses[RFC6052]. Hosts are not + aware of the NAT64 translator on communication path. For the testing + purpose, operators could employ an independent sub domain e.g. ipv6exp.example.com to identify experimental ipv6 services to users. How to design the FQDN for the IPv6 service is out-of-scope of this document. 4. High Availability 4.1. Redundancy Design High Availability (HA) is a major requirement for every service and - network services. The deployment of redundancy mechanism is an - essential approach to avoid single-point failure and significantly - increase the network reliability. It's not only useful to stateful - NAT64 cases, but also to stateless NAT64 gateways. + network services. The deployment of redundancy mechanisms is an + essential approach to avoid failure and significantly increase the + network reliability. It's not only useful to stateful NAT64 cases, + but also to stateless NAT64 gateways. - Three redundancy modes are mainly used hereafter: cold standby, warm - standby and hot standby. + Three redundancy modes are mainly used: cold standby, warm standby + and hot standby. - o Cold standby can't replicate the NAT64 states from the primary - equipment to the backup. Administrators switch on the backup - NAT64 only if the primary NAT64 fails. As the results, all the - existing established sessions will be disconnected. The internal - hosts are required to re-establish sessions to the external hosts. - Since the backup NAT64 is manually configured to switch over to - active NAT64, it may have unpredictable impacts to the ongoing - services. Normally, the handover would take several minutes so as - to wait for the whole process of NAT64 bootstrap loader. + o Cold standby HA devices do not replicate the NAT64 states from the + primary equipment to the backup. Administrators switch on the + backup NAT64 only if the primary NAT64 fails. As a result, all + existing established sessions through a failed translator will be + disconnected. The translated flows will need to be recreated by + end-systems. Since the backup NAT64 is manually configured to + switch over to active NAT64, it may have unpredictable impacts to + the ongoing services. o Warm standby is a flavor of the cold standby mode. Backup NAT64 would keep running once the primary NAT64 is working. This makes warm standby less time consuming during the traffic failover. Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a solution to enable automatic handover in the warm standby. It was tested that the handover takes as maximum as 1 minute if the backup NAT64 needs to take over routing and re-construct the Binding Information Bases (BIBs) for 30 million sessions. In deployment phase, operators could balance loads on distinct NAT64s devices. Those NAT64s make a warm backup of each other. o Hot standby must synchronize the BIBs between the primary NAT64 and backup. When the primary NAT64 fails, backup NAT64 would take over and maintain the state of all existing sessions. The internal hosts don't have to re-connect the external hosts. The - handover time has been extremely reduced. Thanks to Bidirectional - Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay + handover time has been extremely reduced. Employing Bidirectional + Forwarding Detection (BFD) [RFC5880] combined with VRRP, a delay of only 35ms for 30 million sessions handover was observed during - testing. In some sense, it could guarantee the session continuity - for every service. In order to timely transmit session states, - operators may have to deploy extra transport links between primary - NAT64 and distant backup. The scale of synchronization data - instance is depending on the particular deployment. For example, - If a NAT64-CGN is served for 200,000 users, the average amount of - 800, 000 sessions per second is roughly estimated for new created - and expired sessions. A physical 10Gbps transport link may have - to be deployed for the sync data transmission considering the - amount of sync sessions at the peak and capacity redundancy + testing. Under ideal conditions hotstandby deployments could + guarantee the session continuity for every service. In order to + timely transmit session states, operators may have to deploy extra + transport links between primary NAT64 and distant backup. The + scale of synchronization data instance is depending on the + particular deployment. For example, If a NAT64-CGN is served for + 200,000 users, the average amount of 800, 000 sessions per second + is roughly estimated for new created and expired sessions. A + physical 10Gbps transport link may have to be deployed for the + sync data transmission considering the amount of sync sessions at + the peak and capacity redundancy In general, cold-standby and warm-standby is simpler and less resource intensive, but it requires clients to re-establish sessions - when a fail-over occurs. Hot standby increases resource's - consumption to synchronize the states, but it achieve seamless - handover. The consideration of redundancy mode for stateless NAT64 - is simple, because state synchronization is unnecessary. In regards - to stateful NAT64, it may be useful to investigate performance - tolerance of applications and the traffic characteristics in a - particular network. Some testing results are shown in the - Appendix A. + when a fail-over occurs. Hot standby increases resource consumption + in order to synchronize state, but potentially achieves seamless + handover. For stateless NAT64 considerations are simple, because + state synchronization is unnecessary. Regarding stateful NAT64, it + may be useful to investigate performance tolerance of applications + and the traffic characteristics in a particular network. Some + testing results are shown in the Appendix A. - Our statistics in a mobile network shown that almost 91.21% of amount - of traffic is accounted by browsing services. Those services don't - require session continuity. The handover time of warm standby is - qualified to the delay tolerance. Hot-standby does not offer much - benefit for those sessions on this point. In a fixed network, HTTP - streaming, p2p and online games would be the major - traffic[Cisco-VNI]. Consideration should be given to the importance - of maintaining bindings for those sessions across failover. - Operators may also consider the Average Revenue Per User (ARPU) - factors to deploy suitable redundancy mode. Warm standby may still - be adopted to cover most services while hot standby could be used to - upgrade Quality of Experience (QoE) using DNS64 with different - synthetic responses for limited traffic. Further considerations are - discussed at Section 6. + Our statistics in a mobile network shown that almost 91.21% of of + traffic is accounted by http/https services. These services + generally don't require session continuity. Hot-standby does not + offer much benefit for those sessions on this point. In fixed + networks, HTTP streaming, p2p and online games would be the major + traffic beneficiaries of hot-standby replication[Cisco-VNI]. + Consideration should be given to the importance of maintaining + bindings for those sessions across failover. Operators may also + consider the Average Revenue Per User (ARPU) factors to deploy + suitable redundancy mode. Warm standby may still be adopted to cover + most services while hot standby could be used to upgrade Quality of + Experience (QoE) using DNS64 to generate different synthetic + responses for limited traffic or destinations. Further + considerations are discussed at Section 6. 4.2. Load Balancing Load balancing is used to accompany redundancy design so that better scalability and resiliency could be achieved. Stateless NAT64s allow asymmetric routing while anycast-based solutions are recommended in [I-D.ietf-softwire-map-deployment]. The deployment of load balancing may make more sense to stateful NAT64s for the sake of single-point failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct facilities, the following lists the considerations for each case. - o NAT64-CGN equipment doesn't implement load balancer functions on a - board card. Therefore, the gateways have to resort to DNS64 or - internal host's behavior. Once DNS64 is deployed, the load - balancing can be performed by synthesizing AAAA response with + o NAT64-CGN equipment doesn't typically implement load-balancing + functions onboard. Therefore, the gateways have to resort to + DNS64 or internal host's behavior. Once DNS64 is deployed, the + load balancing can be performed by synthesizing AAAA response with different IPv6 prefixes. For the applications not requiring DNS resolver, internal hosts could learn multiple IPv6 prefixes through the approaches defined in[RFC7050] and then select one based on a given prefix selection policy. o A dedicated Load Balancer could be deployed at front of a NAT64-FE farm. Load Balancer uses proxy mode to redirect the flows to the appropriate NAT64 instance. Stateful NAT64s require a deterministic pattern to arrange the traffic in order to ensure outbound/inbound flows traverse the identical NAT64. Therefore, @@ -418,54 +415,55 @@ 5.1. Traceability 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 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. + timestamp. It takes almost 125 bytes in ASCII format. It has 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 is 29.07 terabytes in a + compact format. At scale, operators have to build up dedicated + transport links, storage system and servers for the purpose of + managing such logging. - 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. + There are also several improvements that can be made 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 the need for per-subscriber logging. As a side effect, the IPv4 multiplexing efficiency is decreased regarding to those methods. For example, the utilization ratio of public IPv4 address is dropped approximately to 75% when NAT64 gateway is configured with bulk port allocation (The lab testing allocates each subscriber with 400 ports). In addition, port-range based allocation should also consider port randomization described in [RFC6056] . A trade-off among address multiplexing efficiency, logging storage compression and port allocation complexity should be considered. More - discussions could be found in - [I-D.chen-sunset4-cgn-port-allocation].Basically, the decision - depends on usable IPv4 resource and investments of log systems. + discussions could be found in [I-D.chen-sunset4-cgn-port-allocation]. + The decision can balance usable IPv4 resources against investments in + log systems. 5.2. Geo-location IP addresses are usually used as inputs 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 + The use of address sharing prevents 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 in [RFC6967] are intended to bridge the gap. However, those solutions can only provide a sub-optimal substitution to solve the problem of host identification, in particular it may not today solve problems with source identification through translation. The following lists current practices to mitigate the issue. o Operators who adopt NAT64-FE may leverage the application layer proxies, e.g. X-Forwarded-For (XFF) @@ -483,21 +481,21 @@ o The NAT64-CGN equipment may not implement XFF. Geo-location based on shared IPv4 address is rather inaccurate in that case. Operators could subdivide the outside IPv4 address pool so an IPv6 address can be translated depending on their geographical locations. As consequence, location information can be identified from a certain IPv4 address range. [RFC6967] also enumerates several options to reveal the host identifier. Each solution likely has their-own specific usage. For the geo-location systems relying on a Radius database[RFC5580], we have investigated to - deliver NAT64 BIBs and Session Table Entrys (STEs) to a Radius + deliver NAT64 BIBs and Session Table Entries (STEs) to a Radius server[I-D.chen-behave-nat64-radius-extension]. This method could provide geo-location system with an internal IPv6 address to identify each user. It can get along with [RFC5580] to convey original source address through same message bus. 6. Quality of Experience 6.1. Service Reachability NAT64 is providing a translation capability between IPv6 and IPv4 @@ -590,28 +589,28 @@ helpful to minimize terminal battery consumption and reduce the number of keep-alive messages to be sent by mobile terminal devices. Subscribers can also benefit from network reliability. It has been discussed that hot-standby offers satisfactory experience once outage of primary NAT64 is occurred. Operators may rightly be concerned about the considerable investment required for NAT64 equipment relative to low ARPU income. For example, transport links may cost much, because primary NAT64 and backup are normally located at different locations, separated by a relatively large distance. - Additional maintenance has to be spent to ensure the connectivity - quality. However, that may be necessary to some applications, which - are delay-sensitive and seek session continuity, for example on-line - games and live-streaming. Operators may be able to get added-values - from those services by offering first-class services. It can be pre- - configured on the gateway to hot-standby modes depending on - subscriber's profile. The rest of other sessions can be covered by - cold/warm standby. + Additional cost has to be assumed to ensure the connectivity quality. + However, that may be necessary to some applications, which are delay- + sensitive and seek session continuity, for example on-line games and + live-streaming. Operators may be able to get added-values from those + services by offering first-class services. It can be pre-configured + on the gateway to hot-standby modes depending on subscriber's + profile. The rest of other sessions can be covered by cold/warm + standby. 7. MTU Considerations IPv6 requires that every link in the internet have an Maximum Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. However, in case of NAT64 translation deployment, some IPv4 MTU constrained link will be used in some communication path and originating IPv6 nodes may therefore receive an ICMP Packet Too Big (PTB) message, reporting a Next-Hop MTU less than 1280 bytes. The result would be that IPv6 allows packets to contain a fragmentation header, without @@ -853,53 +852,54 @@ Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data Centre Environments", draft-anderson-siit-dc-00 (work in progress), November 2012. [I-D.chen-behave-nat64-radius-extension] Chen, G. and D. Binet, "Radius Attributes for Stateful NAT64", draft-chen-behave-nat64-radius-extension-00 (work in progress), July 2013. [I-D.chen-sunset4-cgn-port-allocation] - Chen, G., "Analysis of NAT64 Port Allocation Method", - draft-chen-sunset4-cgn-port-allocation-02 (work in - progress), July 2013. + Chen, G., Tsou, T., Donley, C., and T. Taylor, "Analysis + of NAT64 Port Allocation Method", draft-chen-sunset4-cgn- + port-allocation-03 (work in progress), February 2014. [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-06 (work in progress), July 2013. + behave-deterministic-cgn-07 (work in progress), January + 2014. [I-D.ietf-softwire-map-deployment] Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, "Mapping of Address and Port (MAP) - Deployment Considerations", draft-ietf-softwire-map-deployment-03 (work in progress), October 2013. [I-D.ietf-softwire-map-t] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using - Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work - in progress), September 2013. + Translation (MAP-T)", draft-ietf-softwire-map-t-05 (work + in progress), February 2014. [I-D.ietf-softwire-stateless-4v6-motivation] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- softwire-stateless-4v6-motivation-05 (work in progress), November 2012. [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. + Liu, B. and S. Jiang, "Recommendations of Using Unique + Local Addresses", draft-ietf-v6ops-ula-usage- + recommendations-02 (work in progress), February 2014. [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. @@ -978,34 +978,34 @@ +----------------+------------------------+-------------------------+ |Mail |30 seconds | No | +----------------+------------------------+-------------------------+ |Downloading |1 minutes | No | +----------------+------------------------+-------------------------+ Authors' Addresses Gang Chen China Mobile - 53A,Xibianmennei Ave., + Xuanwumenxi Ave. No.32, Xuanwu District, Beijing 100053 China Email: phdgang@gmail.com Zhen Cao China Mobile - 53A,Xibianmennei Ave., + Xuanwumenxi Ave. No.32, Xuanwu District, Beijing 100053 China - Email: caozhen@chinamobile.com + Email: caozhen@chinamobile.com, zehn.cao@gmail.com Chongfeng Xie China Telecom Room 708 No.118, Xizhimenneidajie Beijing 100035 P.R.China Email: xiechf@ctbri.com.cn David Binet