IPv6:&Transi-on&mechanisms& · Instead&of&working&around&NAT&like&other&traversal&techniques& ......

$: IPv6:&Transi-on&mechanisms& · Instead&of&working&around&NAT&like&other&traversal&techniques& ... &&&&&applicaon& custom_hip{&&&&&protocol&tcp; &&&&&des-naonSport80;& ...$
IPv6: Transi-on mechanisms Nicolai van der Smagt Network Design Engineer

Infradata Netherlands BV

[email protected]

The obligatory slide: IPv6 drivers

!   Internal driver: IPv4 address space exhaus-on !   Today there’s no more global (IANA) address space available !   RIPE and ARIN have just a couple of /8’s leP, APNIC is down to its last /8 !   Service providers are hoarding IPv4 addresses, but those will not last forever

!   External driver: Demand for IPv6 access and content !   End-‐users are asking for IPv6 access, and this growing demand

for IPv6 access forces content owners to be reachable over IPv6 !   World IPv6 day successful !   “World IPv6 launch” date approaching (6-‐6-‐2012)

!   Google, Facebook, YouTube, Yahoo, Bing and others start to announce AAAA records globally

!   Access providers such as XS4All extend IPv6 service !   “You’re the only one asking for it” will not suffice much longer

IPv6 migra6on: The hard part

!   Bear in mind that network migra-on may be the easy part of an IPv6 migra-on strategy…

!   DNS Servers !   Provisioning systems !   Metered billing systems !   Security systems and policies !   Address assignment systems (Radius/DHCP) !   Accoun-ng systems !   Lawful intercept !   Tracing/logging !   Support systems (fault, inventory, performance management) !   Tes-ng equipment and networks (lab) !   Test procedures !   Yellow s-ckies on the side of terminal in NOC

IPv6 migra6on: Strategies

!   Conserva-ve: !   Retain IPv4 paradigm as much and as long as possible:

!   …. !   …. !   ….

!   Progressive: !   Deploy IPv6 progressively and get rid of IPv4 as soon as commercially possible:

!   …. !   …. !   ….

IPv6 migra6on: Technologies

!   Help mi-gate IPv4 address exhaus-on !   NAT444/LSN (Large Scale NAT)

!   Help IPv6 deployment !   Dual stack !   6RD (IPv6 Rapid Deployment) and other tunneling techniques

!  Mi-gate IPv4 address exhaus-on and help IPv6 deployment !   DS-‐Lite (Dual stack Lite) !   NAT64

IPv4 address exhaus6on: NAT444 LSN -‐ Large-‐Scale NAT !   NAT444 LSN enables the SP to use private IPv4 space for customer assignment, thus reducing the need for public IPv4 addresses

!   NAT444 LSN adds a layer of NAT (Network Address Transla-on) on the edge of the SP network. Customer traffic is subject to this layer of NAT

!   NAT444 LSN doesn’t really help IPv6 adop-on, it only delays the inevitable !   Unfortunately, NAT444 LSN provides unique challenges:

!   RFC 1918 space (private IP space) collisions !   End-‐user internal space and SP space could collide !   End-‐user to end-‐user communica-ons need to be hairpinned through LSN box

!   Using NAT breaks applica-ons, dual-‐layer NAT exacerbates these problems: !   ALGs are necessary !   Even with ALGs applica-ons break

!   Forensic logging is more complex, geo-‐loca-on breaks, etc. !   NAT space is shared; policing required !   NAT layer is an extra point-‐of-‐failure in the network

(network state → vulnerable for DoS aiacks) !   End-‐user control over port-‐forwarding is limited, and complex from security point of view

(there’s the PCP draP)

IPv4 address exhaus6on: PCP -‐ Port Control Protocol

!   PCP is upcoming technology (IETF draP) designed to address the problem that end users have no control over LSN

!   PCP enables applica-ons to receive incoming connec-ons over a NAT444 connec-on

!   Instead of working around NAT like other traversal techniques (like STUN), PCP enables an explicit dialog between applica-ons and the NAT

!   PCP can be seen as a carrier-‐grade evolu-on of UPnP-‐IGD and NAT-‐PMP

IPv4 address exhaus6on: NAT444 LSN

ISP RFC1918 IPv4 network

Wireless device is provisioned with private IPv4

Two levels of NAT break applica-ons expec-ng incoming connec-ons

NAT

NAT

RFC1918 IPv4 in the customer networks

IPv4

Impact: !   Double NAT !   Applica-ons that cannot adapt will break !   Liile end user control over LSN (port forwards) !   NAT entails risk for scalability and availability

NAT444 LSN Junos config example -‐ topology

10.0.0.0/8

CPE

CPE

CPE

CPE

9.0.0.2

9.0.0.1 128.0.0.1/24

129.0.0.2/24

NAT pool: +-‐-‐-‐+ ; \129.0.0.0/24

CGN

● ●

NAT444 LSN Junos config example part 1 interfaces { ge-‐1/3/5 { descrip-on “*** inside ***”; unit 0 { family inet { service { input { service-‐set sset2; } output { service-‐set sset2; } } address 9.0.0.1/24; } } } ge-‐1/3/6 { descrip-on “*** outside ***”; unit 0 { family inet { address 128.0.0.1/24; } } } sp-‐5/0/0 { descrip-on “*** mul-service DPC ***”; unit 0 { family inet; } } }

Interfaces

NAT444 LSN Junos config example part 2 services { nat { pool p1 { address 129.0.0.0/24; port automa-c random-‐alloca-on; } rule r1 { match-‐direc-on input; term t1 { from { source-‐address { 10.0.0.0/16; 10.1.0.0/16; } } then { translated { source-‐pool p1; transla-on-‐type { source dynamic; } } } } } } service-‐set sset2 { nat-‐rules r1; interface-‐service { service-‐interface sp-‐5/0/0; } } }

NAT

NAT444 LSN Junos config example part 3 services { ids { rule r1 { match-‐direc-on input; term t1 { then { session-‐limit { by-‐source { maximum 1000; } } } } } } applica-ons { applica-on custom_hip { protocol tcp; des-na-on-‐port 80; inac-vity-‐-meout 300; } }

Protec6on

IPv6 deployment: 6RD

!  6rd enables an IPv6 host to reach an IPv6 server via an IPv4 only network !   Similar to many other tunneling mechanisms before it !   It doesn’t really help you with IPv4 to IPv6 migra-on

!  6rd doesn’t help an IPv4 host who cannot obtain a public IP address reach the IPv4 internet !   Either host s-ll needs to have a public IPv4 address

!   So where’s the value? !   6RD is useful only when Time-‐To-‐Market of IPv6 deployment is of cri-cal importance !   6RD enables IPv6 services before the edge network has been made IPv6 aware

!  6RD is moving towards the end of its lifecycle and new IPv6 deployments should use more structural solu-ons

IPv6 deployment: 6RD

IPv6 host

RG

Web server

IPv6 server

Impact: •  End users can buy IPv6 service without network changes •  A “quick fix” that may weaken focus on the real issues •  Customers will think you’re retarded for providing tunnelled service (it’s 2012!!)

Tunneled IPv6 Public

IPv6 internet

IPv4 internet

IPv6 deployment: Dual stack

!   Dual stack: Run IPv4 and IPv6 service simultaneously on the same network

!   Is the best way to deploy IPv6 service from technical point of view (na-ve, end-‐to-‐end connec-vity, DNS decides which stack to use)

!   But it doesn’t help against IPv4 address exhaus-on

!   CAPEX hungry: Network resources (memory), possible hardware upgrades

!  OPEX hungry: OA&M complexity

Dual stack

IPv6 deployment: Dual stack

IPv4 & IPv6 ISP network

Wireless device is provisioned with IPv4 & IPv6

CPE are provisioned with global IPv4 &IPv6

Requires: !   Full IPv6 access network !   IPv6 ready back office !   IPv6 CPE

IPv6

IPv4

IPv6 deployment: DS-‐lite LSN

!   DS-‐lite provides the end user with simultaneous v4 and v6 service

!   And it enables SP to use a single-‐stack IPv6 network

!   And it solves the problem of IPv4 address exhaus-on

!   .. So what’s the catch? !   Some of the disadvantages of NAT444 LSN apply to DS-‐lite LSN !   RG needs to be DS-‐lite aware (hopefully via firmware upgrade) !   Hardly any commercial deployment today, RG soPware can be immature

IPv6 deployment: DS-‐lite LSN

ISP IPv6 network

Dual stack wireless device provisioned only with IPv6

CPE are provisioned only with IPv6

IPv4 & IPv6

Requires: !   IPv6 access network !  DS-‐Lite aware IPv6 CPE

v4inv6 tunnel

IPv6 traffic flows directly

AFTR

The IPv4 NAT func-on is moved from CPE to SP network: Only one level of NAT

IPv6

IPv4

DS-‐Lite LSN Junos config example -‐ topology

Internet

AFTR concentrator

NAT

Home router

128.0.0.1 129.0.0.1 2001:0:0:2::1

10.0.0.2

10.0.0.1

IPv4 host

ISP IPv6 cloud network

B4

2001:0:0:1::1

IPv4-‐in-‐IPv6 soPwire

Host

DS-‐Lite LSN Junos config example part 1 interfaces { ge-‐3/1/0 { descrip-on “*** Outside ***”; unit 0 { family inet { address 128.0.0.2/24; } } } ge-‐3/1/5 { descrip-on “*** Inside ***”; unit 0 { family inet; family inet6 { service { input { service-‐set sset; } output { service-‐set sset; } } address 2001:0:0:2::1/48; } } } } sp-‐0/0/0 { unit 0 { family inet; family inet6; } } }

Interfaces

DS-‐Lite LSN Junos config example part 2 services { nat { pool p1 { address 129.0.0.1/32; port { automa-c; } } rule r1 { match-‐direc-on input; term t1 { from { source-‐address { 10.0.0.0/16; } } then { translated { source-‐pool p1; transla-on-‐type { napt-‐44; } } syslog; } } } } }

NAT

DS-‐Lite LSN Junos config example part 3 soPwire { soPwire-‐concentrator { ds-‐lite ds1 { soPwire-‐address 2001::1; mtu-‐v6 1460; } rule r1 { match-‐direc-on input; term t1 { then { ds-‐lite ds1; } } } } service-‐set sset { syslog { host local { services any; } } soPwire-‐rules r1; nat-‐rules r1; interface-‐service { service-‐interface sp-‐0/0/0.0; } }

SoXwires

IPv6 migra6on: What about content?

!  Most SPs see IPv6 content availability as a shared responsibility for access providers and content providers: !   Access providers should provide a means to get to IPv4-‐only content on

IPv6 networks !   Content providers should provide content owners the means to make content

v6 aware

!   NAT64 is a solu-on for access to the “long tail” of IPv4-‐only content, for content _and_ access providers !   Access providers can setup Address Family Transla-ng Routers (AFTR) using NAT64/

DNS64 to provide access to IPv4 content to their na-ve IPv6 speaking end users

!   Content providers can use NAT64 in front of their load balancing (basically you end up with IPv4 load balancers with IPv6 VIP) to enable IPv6 access to content in their network that is s-ll IPv4 only

IPv6 transla6on: NAT64/DNS64

!   NAT64/DNS64 is used, when the network is IPv6, but we s-ll need to access IPv4 content

!   Disadvantage: DNS64 won’t help with numerical IP address access like hip://66.102.13.99/

!   Transla-on, so ALGs are needed

!  Will need to be in place for a long -me (decades? -‐ IPv4 long tail)

!   Assumes that no IPv4 service to end users is available anymore

!   Today, would need to be applied to lion’s share of traffic

!   Hardly any commercial deployment today

!   “Endgame”

IPv6 only service


ISP IPv6 network

Wireless device provisioned only with IPv6


NAT64

!   No IPv4 devices !   No IPv4 applica-ons !   No IPv4 roaming

IPv4

IPv6

Requires: !   IPv6 access network !  All customers devices and applica-ons MUST support IPv6


!   DNS64 maps “real” IPv4 addresses to IPv6 addresses from a specific NAT64 range !   This NAT64 range is routed to the NAT64 AFTR (Address Family transla-ng Router)

!   DNS64 needs to run on DNS server, or host, or network element

Network DNS

Where’s www.infradata.pl ?

Network IPv4

Network IPv6

Internet IPv6

Internet DNS

It’s at N/w IPv6

Network IPv4

IPv6 only service

IPv6 transla6on: NAT64 load balancing

Wireless device provisioned only with IPv6


NAT64

IPv4

IPv6

Requires: !   IPv6 access network !   All customers devices and

applica-ons MUST support IPv6

ISP IPv6 network

Content IPv6 network

!   No IPv4 devices !   No IPv4 applica-ons !   No IPv4 roaming

NAT64 Junos config example -‐ topology

IPv6 network

Host 1

2001: DB8::1

IPv4 network

Host 2

192.0.2.1

Name server (with DNS64)

NAT64 ge-‐1/3/5 ge-‐1/3/6

R2

NAT64 Junos config example part 1 interfaces { ge-‐1/3/5 { descrip-on "*** Inside ***"; unit0 { family inet; family inet6 { service { input { service-‐set sset3; } output { service-‐set sset3; } } address 2001:DB8::1/64; } } } ge-‐1/3/6 { descrip-on "**** Outside ****"; unit 0 { family inet { address 192.0.1.1/16; } } }

Interfaces

NAT64 Junos config example part 1 -‐-‐ CONTINUED -‐-‐

sp-‐5/0/0 { services-‐op-ons { syslog { host local { services any; log-‐prefix XXXXXXXX; } } unit 0 { family inet; family inet6; } }

Interfaces

NAT64 Junos config example part 2 services { nat { pool src-‐pool-‐nat64 { address 203.0.113.0/24; port automa-c; } rule nat64 { match-‐direc-on input; term t1 { from { source-‐address { 2001:DB8::0/96; } des-na-on-‐address { 64:FF9B::/96; } } then { translated { source-‐pool src-‐pool-‐nat64; des-na-on-‐prefix 64:FF9B::/96; transla-on-‐type { source dynamic; des-na-on sta-c; } } } } } } }

NAT

NAT64 Junos config example part 3 services { service-‐set sset3 { syslog { host local { services any; log prefix XXXSVC-‐SETYYY; } } nat-‐rules nat64; interface-‐service { service-‐interface sp-‐5/0/0; } } }

Service set

IPv6 migra6on: Strategies

!   Conserva-ve: !   Retain IPv4 paradigm as much and as long as possible:

!   NAT 444 LSN to baile IPv4 exhaus-on !   When na-ve IPv6 becomes a must-‐have, deploy IPv6 in dual stack fashion, core

to edge to ensure a gradual introduc-on !   Finally transi-on to na-ve IPv6, and deploy NAT64 for access to legacy v4 content

!   Progressive: !   Deploy IPv6 progressively and get rid of IPv4 as soon as commercially possible:

!   Deploy IPv6 network, in edge-‐to-‐core fashion to speed up IPv6 service delivery !   Deploy DS-‐lite LSN IPv4 service over na-ve v6 network, phasing out na-ve IPv4

service and figh-ng v4 exhaus-on at the same -me !   Eventually transi-on to IPv6 only, with NAT64 for access to legacy v4 content !   Preferred approach:

!   Future-‐proof early on !   Less NAT to worry about (single versus double NAT) !   Sa6sfy IPv6 service demand early on !   Avoids dual stack scalability and OA&M complexi6es

IPv6 migra6on: Product offerings

!   Juniper provides support for LSN, DS-‐LITE and NAT64 on their MX product line (needs MS-‐DPC card, some inline MPC support is roadmap item)

!   A10 networks has support for LSN, DS-‐lite and NAT64 (-‐load balancing) in their AX product line

!   Cisco supports LSN on their CRS product line (requires CGSE card)

!   Alcatel Lucent support LSN and DS-‐lite on the 7750 SR product line (requires MS-‐ISA card)

IPv6 migra6on: Juniper

!  MX-‐series routers support inline transla-on technologies via MS-‐DPC card (capable of providing many other services as well)

!   These are numbers for NAT64, NAT44 numbers are marginally beier

!  Max. throughput 18 Gb/s per MS-‐DPC on Junos 11.2

!  Max. 8M concurrent sessions per MS-‐DPC on Junos 11.2

!   Up to 250k new NAT sessions per second (“ramp-‐up rate”) per MS-‐DPC on Junos 11.2

!   Industry leader in ALG support: !   BOOTP, DCE RPC and DCE RPC portmap, Exec, FTP, H.323, ICMP, IIOP, Login, NetBIOS,

NetShow, RealAudio, RPC and RPC portmap, RTSP, Shell, SNMP, SQLNet, TFTP, Traceroute, WinFrame and SIP

IPv6 migra6on: A10 Networks

AX-‐series:

!   64-‐bit SMP capable, linear scaling

!   128M concurrent sessions max. on AX5200 (up to 3 NAT sessions per single-‐port L4 session may be required)*

!   Up to 1.5M new NAT sessions per second on AX5200

!   Supports LSN with Full-‐cone NAT, hairpinning for P2P reachability, ALGs for FTP, RTSP, IPSEC, PPTP/GRE

!   High-‐end model AX5200 = $200k list price

!   All AX models provide full transla-on features

* Full-‐cone NAT and P2P hairpinning require 1 extra session

IPv6 migra6on: Cisco

!   CRS-‐series routers support inline transla-on technologies (LSN) via CGSE card on CRS-‐1 and CRS-‐3

!   ASR 9000 not yet supported, supposedly roadmap / same with NAT64 and DS-‐Lite

!  Max. throughput 10 Gb/s per CGSE on IOS-‐XR 3.9.1

!  Max. 20M concurrent sessions per CGSE on IOS-‐XR 3.9.1

!   Up to 1M new NAT sessions per second (“ramp-‐up rate”) per CGSE on IOS-‐XR 3.9.1

!   List price = $120k / CGSE + MSC (Modular Services Card, required)

IPv6 migra6on: Alcatel Lucent

To support inline transla-on and other services, a MS-‐ISA card is required

The following numbers are for NAT44 (NAT64 not available):

!  Max. throughput 10 Gb/s per MS-‐ISA on R9.0 soPware

!  Max. 6M concurrent sessions per MS-‐ISA on R9.0 soPware

!   Up to 64k new NAT sessions per second (“ramp-‐up rate”) per MS-‐ISA on R9.0 soPware

!  Max. 128k DS-‐Lite endpoints per MS-‐ISA on R9.0 soPware

!   List price = $???k / MS-‐ISA (+ requires an IOM mothercard, takes up 1 MDA slot)

IPv6 migra6on: Conclusions

!   IPv6 is a networking technology, but the biggest challenges may not be in the networking department

!   If you can, go dual stack!

!   If you can’t go dual stack (because of IPv4 or infrastructure resource shortage), DS-‐lite is an airac-ve alterna-ve (but, those firmware upgrades L)

!   NAT444 has many caveats and is only interes-ng if DS-‐lite or true dual stack is unaiainable due to opera-onal issues (usually large carriers)

!   NAT64 looks like the “endgame” technology that will unlock IPv4 long-‐tail content on IPv6 only networks

IPv6:&Transi-on&mechanisms& · Instead&of&working&around&NAT&like&other&traversal&techniques& ......

Documents

Transcript of IPv6:&Transi-on&mechanisms& · Instead&of&working&around&NAT&like&other&traversal&techniques& ......