IPv6 Transition Mechanisms

IPv6 Transition Mechanisms Petr Grygárek © 2009 Petr Grygarek, Advanced Computer Networks Technologies 1 IPv6 and IPv4 Coexistence • Expected to ...
Author: Coral Wilkerson
1 downloads 0 Views 1MB Size
IPv6 Transition Mechanisms Petr Grygárek

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

1

IPv6 and IPv4 Coexistence

• Expected to co-exist together for many years • Some IPv4 devices may exist forever

• Slow(?) transition of (part of?) networks to IPv6 • depends on “tangible” benefits for users

• IPv4 address range may be treated as a subset of IPv6 range • but payload has to be translated somehow

• includes both 6/4 address and DNS record translation

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

2

Motivation for IPv6 transition (1) •

Large address space • IPv4 address pool is depleted in some RIRs • Anybody can have (almost) as many GLOBAL UNIQUE addresses as he wants • Interesting for mobile devices manafacturers, telco operators and last mile Internet access providers • Should eliminate overlapping private networks forever • Potential for various attractive address mapping schemes (e.g. embbedded RPs) • BUT: is current address allocation scheme effective ? • remember beginnings of IPv4 ;-)

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

3

Motivation for IPv6 transition (2) * Avoidance of NAT ●



universal connectivity, no need of provider's NAT44-like solutions etc. BUT: Some customers love their NAT

• New attractive features

• Mobility, multiple-address support, ...

• Enhanced security

• Built-in directly into protocol specification

• BUT: Not supported by all IPv6 protocol stack implementations

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

4

Demotivation for IPv6 transition (1)

• From customer's applications point of view, no direct benefit for users

• but implementation may bring problems and network outages ;-)

• Many “new” mechanisms developed for IPv6 are available in IPv4 also now ●

IPSec, IP Mobile, …

• Transition is not easy for ISP, but is much

complicated for service hosting company • Many different platforms involved © 2009 Petr Grygarek, Advanced Computer Networks Technologies

5

Demotivation for IPv6 transition (2)

• IPv6 tries to solve many IPv4 problems (both existing and hypotetical) => complicated

• Not all security risks of rather complicated

technologies are guaranteed to be be well understood now

• IPv6 specifications and address assignment policies are still changing

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

6

Typical IPv4 and IPv6 interactions

• IPv4 and IPv6 in parallel ●

Dual stack, no “true“ interoperability

• “Overlaying” over other protocol domains • 6 islands over 4 backbone • 6 hosts over 4 networknteroperability • Full application connectivity between 6 and 4 hosts (6-4 payload translation) © 2009 Petr Grygarek, Advanced Computer Networks Technologies

7

Interoperability Options

• Dual-stack hosts

• Applications and DNS resolver have to support both protocols also

• Tunneling

• Network-to-network, Host-to-network,

Host-to-host • Does not bring universal interoperability

• Protocol translation (NAT-PT, NAT64+DNS64) • includes DNS manipulation • Promising but most problematic (dynamic state, security)

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

8

Basic Interoperability Tools

• Dual stack

• most commonly one hybrid stack

• Tunnelling • Protocol translator • AFT – address-family translator • formerly referred as NAT-PT © 2009 Petr Grygarek, Advanced Computer Networks Technologies

9

• 6 in 4

Tunnelling mechanisms

• protocol 41 in IPv4 header

• 4 in 6 • •

attractive for ISPs (saves IPv4 addresses, limits multiple NATting) traditional IPv4 data over IPv6 infra

• Static tunneling

• manual configuration • virtual interfaces and virtual links

• Dynamic tunneling

• Stateful – tunnel interface created • Stateless – per-packet encapsulation • 6to4, Teredo, ...

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

10

Tunnel Servers • • •



Automated explicit tunnel interface configuration Tunnel server is a router connected to both IPv4 and IPv6 network • platform has to support lot of tunnel interfaces Creates tunnel interfaces on IPv4 side according to previous registrations • WWW interface • Tunnel Setup Protocol (TSP) – experimental, www.freenet6.net • protocol messages in XML • SASL authentication Commonly separate Tunnel Broker that controls multiple Tunnel Servers • Tunnel broker generates config script for remote client

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

11

6 to 4 (RFC 3056)

•communication of IPv6 islands over IPv4 backbone •Most used automatic tunneling mechanism •Islands’ IPv6 address ranges are derived from gateway’s IPv4 address

•2002::/16 + 32 bit of 6to4 router’s IPv4 address

•6to4 router advertises 2002://16 prefix to IPv6 island •Automatic (stateless) packet tunneling •encapsulation to IPv4 packet with address obtained from

6to4 destination address •Reverse DNS has to be solved •Registrations may be accomplished on https://6to4.nro.net •Verification by client’s source address © 2009 Petr Grygarek, Advanced Computer Networks Technologies

12

6to4 to native-IPv6 communication •Relay router •One native IPv6 interface •One 6to4 interface •IPv6->6to4 •Relay router(s) advertise 2002://16 prefix to IPv6 world •6to4->IPv6

•Address of gateway to IPv6 native world needed •in 6to4 format so that it can pass packets to it using 6to4 tunnel

•BGP •Dedicated anycast prefix for all 6to4 relay routers © 2009 Petr Grygarek, Advanced Computer Networks Technologies

13

6over4 (RFC 2529)

•Allows separate computers with IPv4 connectivity to participate on IPv6

•Computers have to support both IPv4 and IPv6

•Utilizes IPv4 as virtual link layer •Packets are tunneled to 6over4 gateway (router) connected to both IPv4 and native IPv6 •Neighbor discovery used for mapping of IPv6 addresses to IPv4

•Because of ND procedures, IPv4 infrastructure has

to support multicast •IPv6 multicast group *.X.Y mapped to 239.192.X.Y © 2009 Petr Grygarek, Advanced Computer Networks Technologies

14

Inter-Site Automatic Tunnel Addressing Protocol (ISATAP) – (1)

•Similar to 6over4 but does not require multicasting in IPv4 infrastructure •Used in IPv4 customer networks

•Utilizes 6to4 to communicate with other IPv6 islands

•Device’s IPv6 address contains its IPv4 address

•:0000:5efe: •Automatic stateless encapsulation/tunneling

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

15

Inter-Site Automatic Tunnel Addressing Protocol (ISATAP) – (2)

•Neighbor discovery

does not use multicasting

•IPv4 address encapsulated in IPv6 address

•Autoconfiguration and obtaining of default gateway has to be solved

•Explicit configuration of Potential Router List •Manual configuration, DHCPv4, DNS

•Unicast Router Solicitations/ Advertisements

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

16

Teredo

•For IPv6 clients connected to IPv4 network

through NAT •Provides mechanism to communicate in both directions over NAT

•Communication has to be initiated from NAT inside and NAT table entry maintained

•Supports only cone and restricted NAT, not symmetric NAT •Uses UDP-IPv4 encapsulation © 2009 Petr Grygarek, Advanced Computer Networks Technologies

17

NAT Implementations

•Cone NAT

•Assigns single address/port to client •Any packet from outside to client’s address/port is passed to the client (regardless of the source)

•Restricted NAT

•Only packets from addresses/ports contacted previously by client are allowed to pass in

•Symmetric NAT

•Assigns various addresses/ports to client for communication with different destinations •Behaves as Restricted NAT in other aspects

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

18

Teredo IPv6 Addressess

•Network prefix (assigned by server) •2001::/32 – Teredo prefix •Teredo server IPv4 address (32b)

•Interface ID (constructed by client) •Flags – type of NAT

•type of NAT is tested during client registration (“qualification procedure”)

•Client’s NAT outside address + port

•Obtained from Teredo server during qualification procedure

•Unicasted router solicitation/advertisement

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

19

Teredo servers

•Located in public Internet •Connections to both IPv4 and IPv6 world •Addresses configured manually on Teredo clients •Serves as relays between Teredo clients behind NATs

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

20

Communication between Teredo clients

•Cone NAT: direct communication •Restricted NAT:

•“bubbles” (empty messages) used to create translation entries in source’s and destination’s NATs •Source->destination

•=> (bidirectional) entry in source’s NAT

•Source->Teredo server->Destination

•Instruct destination to send bubble to source •=> (bidirectional) entry in destination’s NAT

•Direct communication may follow © 2009 Petr Grygarek, Advanced Computer Networks Technologies

21

Relaying from Teredo client to non-Teredo address

•Procedure defined to obtain Relay server address from Teredo server •Advertises Teredo prefix (2001::/32) to native IPv6 world

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

22

NAT-Protocol Translation

•Client 4 → server 6: •Uses DNS reply manipulation •AAAA → A •Pool of inside (private) IPv4 addresses on NAT/PT box used to replace AAAA destination IPv6 address

•Assigned inside address translated to selected address from pool of outside (global) IPv6 addresses on NAT-PT box

•Single global IPv6 address may be also PAT-ted for L4 protocols

•IP Packet payload translated on NAT-PT box

•Client 6 → server 4 •IPv4 address space may be considered subset of IPv6 address space

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

23

NAT64+DNS64

•Connections may be established only from IPv6

to IPv4 •In local IPv6 network it uses local dedicated 96b prefix for all IPv4 (destination) addresses •Routed to translator

•Appended with IPv4 address (96+32=128b)

•Stateless unique address mapping •IPv4 (outside) NAT/PAT address is dynamically

allocated for 1st sender’s packet •Static entries may be used to allow 4->6 access to local servers © 2009 Petr Grygarek, Advanced Computer Networks Technologies

24

DNS64

DNS manipulation for NAT64 (stateless only) Handled by local DNS64-aware DNS server •Client asks for AAAA •For IPv4 servers, only A is present •Has to be mapped to AAAA •IPv6 address concatenated from as prefix that directs to translator and respective IPv4 address

•Manipulated DNS replies are marked (CD flag) •to prevent client to reject DNSSec-protected reply as forged

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

25

6rd (RFC 5569)

•IPv6 Rapid Deployment •IPv6 over ISP's IPv4 environment •Derived from 6to4 •ISP uses some of his prefixes instead of 2002::/16, so that all 6rd hosts are reachable behind this prefix

•No problem with 6to4 GW selection, asymmetric routing, propagation of 2002::/16 prefix to IPv6-only world, ...

•IPv4 address encoded in IPv6 address

•6rd prefix (N, max 32)| IPv4 address (32) | subnet (32-N)| host (64) •Common IPv4-prefix may be omitted •without it, only /64s can be assigned as LIRs normally obtain /32 from RIR

•Customer addresses are provider-dependent © 2009 Petr Grygarek, Advanced Computer Networks Technologies

26

Dual Stack (DS) Lite – RFC 6333

•IPv4 tunneled over native IPv6-only last-mile infra •DS Lite implemented in CPE routers

•Only private IP addresses on CPE insides

•ISP IPv4 NAT on packets decapsulated from

IPv6 •public IPv4 addresses only on translator box

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

27

Other Migration Issues

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

28



Other 4-to-6 transition problems (1) Many older routers are NOT IPv6-enabled

• IPv6 support is often suboptimal

• Partial implementation • Not hardware-accelerated => CPU load

• Many existing user devices are NOT IPv6-enabled nor upgradable to IPv6

• IP phones, industry automation, ... • Some of them will NEVER be

• IPv6 support required even in switches

• MLD snooping, DHCP snooping, ARP snooping • Reasonable multicast processing is now a MUST © 2009 Petr Grygarek, Advanced Computer Networks Technologies

29

Other 4-to-6 transition problems (2)

• Not complete IPv6 implementation in supporting infrastructure • AAA

• RADIUS implementations etc.

• Some DNS/DDNS server implementations • Management infrastructure implementation • SNMP, Netconf, Syslog, ...

• Firewalls, VPN gateways

• Often only partial L7 inspection support on IPv6

• IP Telephony devices • Special devices

• Content filters, load balancers, WLAN controllers, ...

© 2009 Petr Grygarek, Advanced Computer Networks Technologies

30