NAT64 Operational Experiencesdraft-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 observati

on 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 operati

onal 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 efficie

ncy & 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 servic

es in large scale– Operators have limited or n

o 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

IPv4 Internet

IPv6 network

NAT64

DNS64DNS64

IPv6 internet /network

NAT64

IPv4 Network

• NAT64-CE features– IPv6-enable for IPv4 servic

es in small/medium scale– Operators have full control

over on IPv4 side– Leverage IPv6 infrastructur

es– ISP running particular servi

ces

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

P

+NAT64

P

NAT64

NAT64

+ NAT64

P

+NAT64

+NAT64

Standalone NAT64 centralized deployment

Embedded NAT64 centralized deployment

Standalone NAT64 distributed deployment

Embedded NAT64 distributed deployment

NAT64

NAT64

More Considerations

• NAT64-CGN– High Availability

• cold-standby (VRRP) vs hot-standby (BIB sync)

– Traceability• Online(XFF) vs Offline(syslo

g)

– Lawful Interception• Integrated with IAP(RFC392

4) and conformance with draft-ietf-behave-lsn-requirements

– Quality of Experience• Service richness• Deterministic behaviors for dif

ferentiated 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 inform

ation 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