NAT64 Operational Experiences draft-chen-v6ops-nat64-experience-01 IETF 83- Paris, Mar 2012 Gang Chen, China Mobile Zhen Cao, China Mobile Cameron Byrne, T-Mobile USA QiBo Niu, ZTE

Introductions Scope and audiences –Not targeted to enhance stateful NAT64 protocol –Intended to help operators whom may just starting out planning stateful NAT64 in the near future Motivations –RFC6136 reported at least 30% operators plan to run some kind of translator (presumably NAT64/DNS64) –Operators expected to get more NAT64 deployment experiences –A good example is draft-arkko-ipv6-only-experience (RFC Ed Queue); Link to it was suggested This draft is more specific on NAT64 network planning

Received Comments (1) What’s the rule about this draft? –Provided operational views about IETF technology, i.e. NAT64 –Documented operational experience (Thanks for Jari’s observation and guidance) What problem/issue is this draft discussing? –Identify what’s the problem that operators have met and will met when they deploy NAT64 –How it operates and how to troubleshoot it Where does this draft or presentation fits into v6ops current charter? –Solicit input from network operators and users to identify operational issues..., and determine solutions or workarounds to those issues

Received Comments (2) Rename the title indicating objective –Starting with a title "NAT64 Operational Experiences" Clearly separate consideration into the various scenarios for a NAT64 device –Summarizes stateful NAT64 deployment scenarios and operational experiences for NAT64-CGN and NAT64-CE Suggested adding MTU statement in IPv4&IPv6 coexisting network –MTU consideration is added both in NAT64-CGN and NAT64-CE cases Some concerns about IPv6-only naming support –Identifying such practices is only for testing purpose and removed related recommendations

Received Comments (3) Suggested adding discussions on the concern of logging amount –Characterize the amount of logging in typical usages –Discuss tradeoff between address multiplexing efficiency & logging storage compression Lawful interception –Consolidate LI statements –Compliant with draft-ietf-behave-lsn-requirements

Changes since IETF#82 Updated all information from presentation of draft- chen-v6ops-nat64-cpe-03 in IETF#82, and retired nat64-cpe Clarifying MTU consideration both in NAT64-CGN and NAT64-CE Removing the consideration on IPv6-only support via a specific DNS name Added more informational references

Topics we covered NAT64-CGN –NAT64-CGN Networking –High Availability Consideration –Traceability and Lawful Interception –Quality of Experience –Load Balance –MTU Consideration NAT64-CE –NAT64-CE Networking –Anti-DDoS/SYN Flood –User Behavior Analysis –DNS Resolving –Load Balance –MTU Consideration See Backup for More Details

Next Step Ready for WG adoption? Welcome more contributors

Backup

Rationale: different locations have different stories NAT64-CGN features –IPv6-enable for IPv4 services in large scale –Operators have limited or no control on IPv4 sides –retro-fitting to predominate IPv4 networks –Should support services in the wild Different scenarios link to RFC6144 The terms (CGN/CE) is to be understood as a topological qualifier NAT64-CE features –IPv6-enable for IPv4 services in small/medium scale –Operators have full control over on IPv4 side –Leverage IPv6 infrastructures –ISP running particular services

NAT64 Networking NAT64-CGN –located NAT64-CGN to be close to IPv4 peers to reduce unnecessary backhaul costs and latency –Located NAT64 at the network border NAT64-CE –Distributed NAT64-CE at separated CE domain to cope with significant IPv6 connections –Subsided NAT64 to a customer edge, e.g. Enterprise-GW or Home- GW

More Considerations NAT64-CGN –High Availability cold-standby (VRRP) vs hot- standby (BIB sync) –Traceability Online(XFF) vs Offline(syslog) –Lawful Interception Integrated with IAP(RFC3924) and conformance with draft- ietf-behave-lsn-requirements –Quality of Experience Service richness Deterministic behaviors for differentiated services –Load Balance I-D.zhang-behave-nat64-load- balancing NAT64-CE –Anti-DDoS/SYN Flood Compliant with RFC6092 Use of L3 load balancer with capable of DDoS defense, like SYN Flood with SYN PROXY-COOKIE –User Behavior Analysis Leverage the mapping information for accurate advertisement delivering –DNS Resolving Follow RFC6144 –Load Balance Placed L3 load balancer on a IPv6 side

MTU consideration (new added) NAT64 CGN –Eliminated the issues from operational aspects and seek a solution on protocol enhancement NAT64 CE –Recommended configure IPv4 MTU>=1260 from operational aspects PS –The coexistence with IPv4 link would result IPv6 packets to contain a fragment header, without being actually fragmented –[I-D.gont-6man-ipv6-atomic-fragments] discussed the fragmentation- based attacks risks