1 / 13

NAT64 Operational Experiences draft-chen-v6ops-nat64-experience-01 IETF 83- Paris, Mar 2012

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

calvin
Download Presentation

NAT64 Operational Experiences draft-chen-v6ops-nat64-experience-01 IETF 83- Paris, Mar 2012

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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

  7. 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 Topics we covered See Backup for More Details

  8. Next Step • Ready for WG adoption? • Welcome more contributors

  9. Backup

  10. 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 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 Rationale: different locations have different stories • Different scenarios link to RFC6144 • The terms (CGN/CE) is to be understood as a topological qualifier

  11. 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 NAT64 Networking

  12. 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 More Considerations

  13. 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 MTU consideration (new added) • 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

More Related