IPv6 Integration

Grenoble, April 2001

Building the infrastructure

LT/BT

IPv4 Compatible Addresses

96 32

IPv4 Compatible Addresses

V4->V4 ::V4 -> ::V4

00

IPv4

Used at the beginning for transition with IPv4 Allows encapsulation of IPv6 packet into IPv6 packets Dynamic tunneling
LT/BT

V4->V4 ::V4 -> ::V4 IPv4

LT/BT

IPv4 compatible addresses

6-bone

Like IPv4 addresses with 96 bits to 0

Used when few IPv6 hosts where on the net Dont learn how to manage a IPv6 network

Need more sophisticated networks

E.g the 6-bone mainly use static tunnels between routers
LT/BT

Create a virtual topology other the IPv4 network with configured tunnels
LT/BT

6-bone

6bone

First IPv6 network Started the 15th of July 1996 between 3 sites :
WIDE/JP UNI-C/DK G6/FR

Clouds of equipments connected with IPv6 Mainly IPv4 tunnels to interconnect IPv6 clouds. Some native links (e.g. connection to the 6TAP) Routing Protocol:
static, at the beginning Now dynamic (RIPng, OSPFv6, BGP4+, ...)

Today: 150 sites & 30 countries

IETF Working Group: NGtrans

LT/BT

http://www.6bone.net

LT/BT

IPv6 Traffic Exchange

6 to 4

6TAP is a joint project between Canarie and Esnet:

Located in Star TAP (Chicago, IL)

Amsterdam Internet Exchange (AMS-IX) NSPIXP-6, IPv6-based Internet Exchange in Tokyo

Another way to build a tunneled infrastructure Simpler configuration (no need to configure static tunnels) Use a special address plan
Prefix: 2002::/16
13
0x0002

32

16

64

001
LT/BT

V4ADDR

SLA

Interface ID
10

LT/BT

6 to 4 : Address Allocation

6 to 4 : Tunneling
DNS

Site prefix is derived from the v4 address of the border router

1.2.3.4

AAA for B A ? B=2 002 :010 2:03 04:: 1

1.2.3.4

Prefix: 2002:C001:0203::/48

2002:0102:0304::/48 2002:8001:0203::/48

192.1.2.3

128.1.2.3

A
11
LT/BT

192.1.2.3

128.1.2.3

LT/BT

12

6 to 4 : Interaction with the 6bone

6 to 4: Interaction with the 6bone

6-Bone

If one has as a 6to4 and the other a 6to4 and global IPv6 addresses
Select 6to4 address

If both have 6to4 and global IPv6 addresses

Global IPv6 should be selected

relay relay

relay

A
LT/BT

192.1.2.3

128.1.2.3

13

LT/BT

14

6 to 4: Interaction with the 6bone

6 to 4: Interaction with the 6bone

BGP 4+ NLRI for 2002::/16 AS AS Native IPv6 AS

Relay are just routers with one interface on the native IPv6 network and one on the 6to4 network. If the relay can be announced trough a interior gateway protocol:
Doesnt change anything

relay Default route relay

relay

More complex, when a exterior protocol is used.

15

BGP peering 128.1.2.3

A
LT/BT

192.1.2.3
16

LT/BT

IPv6 pilot : targeted core backbone

Tunnel brokers
FT R&D
Caen

Lille

Sfinx
Nancy Paris Loria
Belfort Colmar

Simplify/Allow the construction of IPv4 tunnels. Use of a web page

information configuration web configuration

Strasbourg

Brest

Rennes

Other IPv6 Networks

INRIA
Nantes

Euro-IPv6

6TAP 6bone

G6bone
Grenoble

Sophia

tunnel
LT/BT

17

LT/BT

18

Renater IPv6 : addressing

Allocated sTLA = 2001:0660::/35
3 13 13 6 13 16 64

Some explanations

001 TLA
35

sTLA Res NLA-ID

SLA

Interface ID

2001:0660:xxx- ---- ---- ----::/48

Reserved by RIPE
2001:0660::/41 2001:0660:0080::/41 2001:0660:0100::/41 2001:0660:0180::/41 2001:0660:0200::/41 2001:0660:0280::/41 2001:0660:0300::/41
LT/BT

Core BB 6bits

Sites 7 bits

NCC allocated : 2001:0660::/35 Derived : 2001:0660::/41 Derived : 2001:0660::/48

13 13 6 13 16 64

RIs Sites

pNLAs
NIO Renater-2 Ile de France Grenoble Strasbourg Rennes Nancy
19

001 TLA
2 bytes

sTLA Res NLA-ID

4 bytes

SLA

Interface ID
10 bytes

LT/BT

20

IPv6 Addressing scheme

Lille

NLA-ID allocation procedures

Nancy

2001:0660:1080::/41

2001:0660:0300::/41

Caen
Brest 2001:0660:0280::/41 Nantes

Strasbourg
2001:0660:0200::/41 Colmar

Paris

NLA-ID Reservation within the /41 prefix allocated by GIP

Agreement with Renater check + DataBase update

Rennes

2001:0660:0100::/41 Belfort

R.I
NLA-ID allocation Reverse zone delegation Site connection set up

2 3 1 4

GIP Renater

2001:0660:1000::/41

Montbonnot Grenoble
2001:0660:0180::/41

Site
NLA-ID request to be connected to IPv6 pilot

Renater = 2001:0660::/35
LT/BT

Sophia

21

LT/BT

22

Implementation of IPv6 stacks

FreeBSD:
4.x : included 3.x : INRIA, KAME

Microsoft:
Windows 2000 9x : Trumpet stack

IPv4 / IPv6 Integration

NetBSD:
-current : included 1.4.2; INRIA, KAME

Solaris 8 AIX 4.3: included Compaq:

True64 : included

Linux:
2.2 : included

Cisco IOS 12.1

Beta, Supported: Q3

Apple
MacOS X : included
LT/BT

LT/BT

23

24 See http://playground.sun.com/ipng/

RFC 1933 (April 1996)

IPv4 Mapped Addresses

client IPv6 application IPv6
3ffe:305:1002::2

Used to v6fy applications Recompile applications to use IPv6 API Stay compatible with IPv4 applications Configuration of a dual stack
use of IPv4 mapped addresses

server IPv6 application IPv6

3ffe:305:1002::1

Generate IPv6 traffic when possible

LT/BT

3ffe:305:1002::1->3ffe:305:1002::2

25

LT/BT

26

IPv4 Mapped Addresses (continued)

client IPv4 application IPv4
128.1.2.3 128.1.2.4

Cohabitation Mechanisms

server IPv6 application

Different approaches
Application Level Gateways

Applications IPv4
::FFFF:128.1.2.3 ->::FFFF.128.1.2.4

Kernel

Dual Stack Transition Mechanism

128.1.2.3 ->128.1.2.4

LT/BT

27

LT/BT

Packets translation: SIIT NAT-PT

28

Application Level Gateways

Application Level Gateway

For example : an old printer without a IPv6 stack

May be used for a large majority of common applications:

E-mail (POP3, IMAP, SMTP) Web (proxies) Printer (spoolers) DNS : relay (may change the RR type)

Client

Spooler

Printer

IPv6

IPv4

Reduce IPv4 traffic inside a domain

May use tunnels
29
LT/BT

LT/BT

30

Dual Stack Transition Mechanism

Dynamic Tunnelling Interface

IPv4 and IPv6 stack IPv4 stack is configured only when one or more application need it Three scenarios
Outcoming session (v6 -> v4) Incoming session (v4 -> v6) v4 applications (inside a v6 cloud):
Combination of scenario 1 & 2 Used to generate v6 traffic from v4 applications

Daemon (scenario 2 & 3)

V4-only application

Ethernet

Routing Table

dti

IPv4 IPv6

LT/BT

31

LT/BT

32

Scenario 1: v6 host to v4 host

dns dstm dns

Scenario 1: v6 host to v4 host

dns dstm dns

The v4 address of Z is used by the application, which sends v4 packet to the kernel The interface asks DSTM Server for a v4 source address The address X4 is returned with a tunnel end-point Y6
LT/BT

X6 tunnels to Y6 IPv4 packet X4 -> Z4 Y decapsulates the v4 packet and send it to Z4 Y keeps the mapping between the v4 and v6 LT/BT address in the routing table

33

34

DSTM

RFC 2765: Stateless IP/ICMP Translation

Invisible

to applications

those dealing with v4 addresses in payload

Network is only configured for v6 V4 address allocation is simple Fails if not enough v4 addresses Subject to deny of service
Scenario 2 & 3 should be limited to Intranet
35

Suppress the v4 stack Translate the v6 header into a v4 header on some point of the network
Routing can direct packet to those translation points.

Translate ICMP from both worlds No State in translators ( NAT)

36

LT/BT

LT/BT

SIIT

SIIT
::FFFF:0:X4 ::FFFF:Z4 X4Z4

V6 header contains:
IPv4 mapped addresses
80

16 FFFF

32

00

IPv4

IPv4 translated addresses

64

16 FFFF

16 0000

32

Network routes IPv4-mapped packets to a translation point Have a IPv4-translated address assigned from a pool

00

IPv4

FFFF doesnt modify TCP/UDP checksum

37

LT/BT

LT/BT

38

SIIT
::FFFF:0:X4 ::FFFF:Z4 X4Z4

NAT-PT (RFC 2766)

Network routes IPv4-translated to the destination Have a IPv4-translated address assigned from a pool

Translate addresses and headers A pool of routable addresses is assigned to the translator Out coming session translation is easy Incoming translation must intercept DNS requests

LT/BT

39

LT/BT

40

NAT-PT: v6 to v4
dns dns

Migration strategies

Technical factors
IPv6 availability

2001::1 Prefix::Z4

@v4Z4

Y
2001::1 @v4

Psychological factors
skill to configure IPv6 risk to modify something working

Pool of official IPv4 addresses

Avoid blocking situations

chicken and egg problem

Prefix is routed to the NAT box May change port numbers to allow more translations
LT/BT

Choose a side (either v4 or v6)

To manage both routing plan
LT/BT

41

42

Migration scenarios

Private Networks

End to end approach is already broken

Private addresses and firewalls Limited and controlled type of flows Outcoming connexion only

Private Network
V6 instead of prefix 10/8

New networks (e.g. mobile phone)

Home usage Mobile telephony

100% Interoperability is not necessary

Private IPv6

Proxies NAT RSIP

LT/BT

ALG NAT-PT DSTM

44

43

LT/BT

Why ?

Private Networks
Public address space
Web Proxy Mail

Simply the network management:

Only router will have to be managed

IPv6 address space Private address space

Can ease the merging of two networks

VPN
VPN

DNS

Dont need to have a IPv6 provider:

Outside of the network IPv4 will be used

Internet
45
LT/BT

DNS

Company

File server

LT/BT

46

MPLS

Conclusion

Forwarding is not changed:

Edge routers must be able to tag IPv6 packets Core routers forward using this tag

Complexity will increase in the IPv4 world

New applications New paradigms End of End to end

Possible with route pinning:

Every router must implement IPv6 routing protocol. LDP, CR-LDP, RSVP must handle IPv6 addresses

Toward a layer 7 network

More costs Difficulty to introduce new applications

LT/BT

47

LT/BT

48

Conclusion
complexity

Conclusion

IPv6 migration will be trigged by sites:

Sites can move to IPv6:
Product availability

IPv6

ISP must be prepared for native interconnection

Smooth migration areas by areas:

interoperability between v4 and v6 areas must be maintained for some applications and equipments different approaches to maintain interoperability complexity will decrease with time

IPv4 Time
LT/BT

49

LT/BT

50

To go on

http://playground.sun.com/IPng
RFCs, IDs, implementations,

http://www.6bone.net http://www.ripe.net http://www.ipv6forum.com

LT/BT

51