This document discusses various strategies and technologies for integrating IPv6 into existing IPv4 networks during the transition period. It describes early transition mechanisms like IPv4-compatible addresses and 6bone. It also covers more advanced transition technologies like dual stack, tunneling protocols 6to4 and 6in4, and address translation methods like NAT-PT and SIIT. The document recommends using these technologies gradually over time and prioritizing their deployment on private networks before exposing services to the public internet. Overall, the integration of IPv6 is positioned as an inevitable increase in network complexity that will drive the internet towards more application-level abstractions.
This document discusses various strategies and technologies for integrating IPv6 into existing IPv4 networks during the transition period. It describes early transition mechanisms like IPv4-compatible addresses and 6bone. It also covers more advanced transition technologies like dual stack, tunneling protocols 6to4 and 6in4, and address translation methods like NAT-PT and SIIT. The document recommends using these technologies gradually over time and prioritizing their deployment on private networks before exposing services to the public internet. Overall, the integration of IPv6 is positioned as an inevitable increase in network complexity that will drive the internet towards more application-level abstractions.
This document discusses various strategies and technologies for integrating IPv6 into existing IPv4 networks during the transition period. It describes early transition mechanisms like IPv4-compatible addresses and 6bone. It also covers more advanced transition technologies like dual stack, tunneling protocols 6to4 and 6in4, and address translation methods like NAT-PT and SIIT. The document recommends using these technologies gradually over time and prioritizing their deployment on private networks before exposing services to the public internet. Overall, the integration of IPv6 is positioned as an inevitable increase in network complexity that will drive the internet towards more application-level abstractions.
This document discusses various strategies and technologies for integrating IPv6 into existing IPv4 networks during the transition period. It describes early transition mechanisms like IPv4-compatible addresses and 6bone. It also covers more advanced transition technologies like dual stack, tunneling protocols 6to4 and 6in4, and address translation methods like NAT-PT and SIIT. The document recommends using these technologies gradually over time and prioritizing their deployment on private networks before exposing services to the public internet. Overall, the integration of IPv6 is positioned as an inevitable increase in network complexity that will drive the internet towards more application-level abstractions.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online from Scribd
Download as pdf or txt
You are on page 1/ 9
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
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
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
