IPv6 Overview
& Status Report
Autumn, 2001
Steve Deering
Tony Hain
Cisco Fellow
deering@cisco.com
Technical Leader
ahain@cisco.com
+1 408 527-8213
+1 425 468-1061
1
Background
Technology Overview
Deployment Strategies
Current Status
2
Why IPv6?
(Theoretical Reasons)
only compelling reason:
more IP addresses!
• for billions of new users (Japan, China, India,…)
• for billions of new devices (mobile phones, cars, appliances,…)
• for always-on access (cable, xDSL, ethernet-to-the-home,…)
• for applications that are difficult, expensive, or impossible to operate
through NATs (IP telephony, peer-to-peer gaming, home servers,…)
• to phase out NATs to improve the robustness, security, performance,
and manageability of the Internet
3
Would increased use of
NATs be adequate?
NO!
• NAT enforces a ‘client-server’ application model where the
server has topological constraints
– NAT blocks peer-to-peer or devices that are “called” by others
(e.g., IP phones)
– NAT inhibits deployment of new applications and services
• NAT increases complexity and reduces manageability of
the local network
– especially when we end up moving to nested NATs!
4
IP Address Allocation History
1981
1985
1990
1995
2000
- IPv4 protocol published
~ 1/16 of total space
~ 1/8 of total space
~ 1/4 of total space
~ 1/2 of total space
• this despite increasingly intense conservation efforts
–
–
–
–
PPP / DHCP address sharing
CIDR (classless inter-domain routing)
NAT (network address translation)
plus some address reclamation
• theoretical limit of 32-bit space: ~4 billion devices
practical limit of 32-bit space: ~250 million devices
(see draft-durand-huitema-h-density-ratio)
5
Other Benefits of IPv6
• server-less plug-and-play possible
• end-to-end, IP-layer authentication & encryption possible
• elimination of “triangle routing” for mobile IP
• other minor improvements
NON-benefits:
• quality of service (same features as IPv4)
• routing (same routing protocols as IPv4)
– except larger address allows more levels of hierarchy
• except customer multihoming is defeating hierarchy
6
Why IPv6?
(Current Business Reasons)
• demand from particular regions
– Asia, EU
– technical, geo-political, and business reasons
– demand is now
• demand for particular services
– cellular wireless (especially 3GPP[2] standards)
– Internet gaming (e.g., Sony Playstation 2)
– use is >= 1.5 years away (but testbeds needed now)
• potential move to IPv6 by Microsoft?
– IPv6 included in Windows XP, but not enabled by default
– to be enabled by default in next major release of Windows
– use is >= 1.5 years away
7
Background
Technology Overview
Deployment Strategies
Current Status
8
IPv4 Header compared to IPv6 Header
Hdr Type of
Ver. Len
Service
Identification
Time to
Live
Protocol
Total Length
Flg
Fragment
Offset
Header
Checksum
Ver.
Traffic
Class
Payload Length
Flow Label
Next
Header
Hop
Limit
Source Address
Source Address
Destination Address
Options...
Padding
shaded fields are absent from IPv6
Destination Address
9
Summary of Header Changes
• Revised
–
–
–
–
Addresses increased 32 bits -> 128 bits
Time to Live -> Hop Limit
Protocol -> Next Header
Type of Service -> Traffic Class
• Streamlined
–
–
–
–
–
–
Fragmentation fields moved out of base header
IP options moved out of base header
Header Checksum eliminated
Header Length field eliminated
Length field excludes IPv6 header
Alignment changed from 32 to 64 bits
• Extended
– Flow Label field added
10
How Was IPv6 Address Size Chosen?
• some wanted fixed-length, 64-bit addresses
– easily good for 1012 sites, 1015 nodes, at .0001 allocation efficiency
(3 orders of mag. more than IPng requirement)
– minimizes growth of per-packet header overhead
– efficient for software processing
• some wanted variable-length, up to 160 bits
– compatible with OSI NSAP addressing plans
– big enough for auto-configuration using IEEE 802 addresses
– could start with addresses shorter than 64 bits & grow later
• settled on fixed-length, 128-bit addresses
(340,282,366,920,938,463,463,374,607,431,768,211,456 in all!)
11
Text Representation of Addresses
“preferred” form: 1080:0:FF:0:8:800:200C:417A
compressed form:
FF01:0:0:0:0:0:0:43
becomes
IPv4-embedded:
FF01::43
0:0:0:0:0:FFFF:13.1.68.3
or
::FFFF:13.1.68.3
12
Text Representation of Addresses (cont.)
address prefix:
2002:43c:476b::/48
(note: no masks in IPv6!)
zone qualifiers:
FE80::800:200C:417A%3
in URLs: http://[3FFE::1:800:200C:417A]:8000
(square-bracket convention also used anywhere else
there’s a conflict with address syntax)
13
Basic Address Types
unicast:
for one-to-one
communication
U
M
multicast:
for one-to-many
communication
M
M
A
anycast:
for one-to-nearest
communication
A
A
14
General Format of Unicast Addresses
global routing prefix
n bits
subnet ID
interface ID
m bits
128-n-m bits
• unicast addresses are hierarchical, just like IPv4
• the global routing prefix is itself hierarchically structured,
usually
• a “subnet” is usually the same as a link, but:
– may have more than one subnet ID for the same link
– (proposed) a subnet ID may span multiple links
15
IPv6 - Addressing Model
• addresses are assigned to interfaces
– No change from IPv4 Model
• interface ‘expected’ to have multiple addresses
• addresses have scope
– Link Local
– Site Local
– Global
Global
Site-Local
Link-Local
• addresses have lifetime
– Valid and Preferred lifetime
16
Global Unicast Addresses
001
global routing prefix
public
topology
(45 bits)
subnet
site
topology
(16 bits)
interface ID
interface
identifier
(64 bits)
• only 1/8th of total space (binary 001 prefix) used initially
• global routing prefix is hierarchically structured, using
CIDR-type allocation and routing (at least for now!)
• agreed policy is for all end-customer sites to be assigned
a 48-bit prefix => 16 bits of subnet space
17
Non-Global Unicast Addresses
• site-local unicast addresses are meaningful only in a
single site zone, and may be re-used in other sites
1111111011
0
subnet ID
interface ID
10 bits
38 bits
16 bits
64 bits
• link-local unicast addresses are meaningful only in a
single link zone, and may be re-used on other links
1111111010
10 bits
0
interface ID
54 bits
64 bits
18
Interface Address Set
• Loopback
(only assigned to a single virtual interface per node)
• Link-Local
• Site-Local
• Auto-configured IPv4-compatible (operationally discouraged)
• Auto-configured 6to4
(if IPv4 public is address available)
• Solicited-Node Multicast
• All-Nodes Multicast
• Global anonymous
• Global published
19
Neighbor Discovery
ICMP message types:
- router solicitation
- neighbor solicitation
- redirect
- router advertisement
- neighbor advertisement
functions performed:
- router discovery
- prefix discovery
- autoconfiguration of address & other parameters
- duplicate address detection (DAD)
- neighbor unreachability detection (NUD)
- link-layer address resolution
- first-hop redirect
20
Serverless Autoconfiguration
(“Plug-n-Play”)
• hosts can construct their own addresses:
– subnet prefix(es) learned from periodic multicast advertisements
from neighboring router(s)
– interface IDs generated locally, e.g., using MAC addresses
• other IP-layer parameters also learned from router adverts
(e.g., router addresses, recommended hop limit, etc.)
• higher-layer info (e.g., DNS server and NTP server addresses)
discovered by multicast / anycast-based service-location
protocol [details still to be decided]
• DHCP also available for those who want more control
21
Auto-Reconfiguration
(“Renumbering”)
• new address prefixes can be introduced, and old ones
withdrawn
– we assume some overlap period between old and new,
i.e., no “flash cut-over”
– hosts learn prefix lifetimes and preferability from router
advertisements
– old TCP connections can survive until end of overlap;
new TCP connections can survive beyond overlap
• router renumbering protocol, to allow domain-interior
routers to learn of prefix introduction / withdrawal
22
Routing
• uses same “longest-prefix match” routing as IPv4 CIDR
• straightforward changes to existing IPv4 routing protocols
to handle bigger addresses
unicast: OSPF, RIP-II, IS-IS, BGP4+, …
multicast: MOSPF, PIM, …
• can use Routing header with anycast addresses to route
packets through particular regions
e.g., for provider selection, policy, performance, etc.
23
Mobile IP (v4 version)
mobile host
correspondent
host
foreign agent
home agent
home location of mobile host
24
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
25
Background
Technology Overview
Deployment Strategies
Current Status
26
IPv4-IPv6 Transition / Co-Existence
Techniques
a wide range of techniques have been identified and
implemented, basically falling into three categories:
(1)dual-stack techniques, to allow IPv4 and IPv6 to coexist in the same devices and networks
(2)tunneling techniques, to avoid order dependencies
when upgrading hosts, routers, or regions
(3)translation techniques, to allow IPv6-only devices to
communicate with IPv4-only devices
expect all of these to be used, in combination
27
IPv6 Deployment Phases
Phases
IPv6 Tunnels
over IPv4
Dedicated Data
Link layers for
Native IPv6
MPLS 6PE
Dual stack
IPv6-Only
Benefits
Low cost, low risk to offer IPv6 services.
No infrastructure change. Has to evolve
when many IPv6 clients get connected
Natural evolution when connecting many
IPv6 customers. Require a physical
infrastructure to share between IPv4 and
IPv6 but allow separate operations
Low cost, low risk; requires MPLS & MPBGP4. No need to upgrade the Core devices,
keep all MPLS features (TE, IPv4-VPN)
Requires a major upgrade. Valid on Campus
or Access networks as IPv6 hosts may be
located anywhere
Requires upgrading all devices. Valid when
IPv6 traffic will become preponderant
31
Background
Technology Overview
Deployment Strategies
Current Status
32
Standards
• core IPv6 specifications are IETF Draft Standards
=> well-tested & stable
– IPv6 base spec, ICMPv6, Neighbor Discovery, PMTU Discovery,
IPv6-over-Ethernet, IPv6-over-PPP,...
• other important specs are further behind on the standards
track, but in good shape
– mobile IPv6, header compression,...
– for up-to-date status: playground.sun.com/ipng
• 3GPP UMTS Release 5 cellular wireless standards
mandate IPv6; also being considered by 3GPP2
33
Implementations
• most IP stack vendors have an implementation at some
stage of completeness
– some are shipping supported product today,
e.g., 3Com, *BSD(KAME), Cisco, Compaq, Epilogue, Ericsson/Telebit,
IBM, Hitachi, Nortel, Sun, Trumpet, …
– others have beta releases now, supported products “soon”,
e.g., HP, Linux community, Microsoft, …
– others rumored to be implementing, but status unkown (to me),
e.g., Apple, Bull, Juniper, Mentat, Novell, SGI, …
(see playground.sun.com/ipng for most recent status reports)
• good attendance at frequent testing events
34
Deployment
• experimental infrastructure: the 6bone
– for testing and debugging IPv6 protocols and operations
(see www.6bone.net)
• production infrastructure in support of education and
research: the 6ren
– CAIRN, Canarie, CERNET, Chunahwa Telecom, Dante, ESnet,
Internet 2, IPFNET, NTT, Renater, Singren, Sprint, SURFnet, vBNS,
WIDE,…
(see www.6ren.net, www.6tap.net)
• commercial infrastructure
– a few ISPs (IIJ, NTT,…) have announced commercial IPv6 service or
service trials
35
Deployment (cont.)
• IPv6 address allocation
– 6bone procedure for test address space
– regional IP address registries (APNIC, ARIN, RIPE-NCC)
for production address space
• deployment advocacy (a.k.a. marketing)
– IPv6 Forum: www.ipv6forum.com
36
IPv6 Timeline
(A pragmatic projection)
2000
2001
2002
2003
2004
2005
2006
2007
Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Early adopter
Appl. Porting <= Duration 3+ yrs.
=>
ISP adoption <= Dur. 3+ yrs. =>
Consumer adoption <= Dur. 5+ yrs. =>
Enterprise adopt. <= 3+ yrs. =>
37
IPv6 Timeline
(A pragmatic projection)
2000
2001
2002
2003
2004
2005
2006
2007
Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Early adopter
Appl. Porting <= Duration 3+ yrs.
=>
ISP adoption <= Dur. 3+ yrs. =>
Consumer adoption <= Dur. 5+ yrs. =>
Enterprise adopt. <= 3+ yrs. =>
Asia
38
IPv6 Timeline
(A pragmatic projection)
2000
2001
2002
2003
2004
2005
2006
2007
Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Early adopter
Appl. Porting <= Duration 3+ yrs.
=>
ISP adoption <= Dur. 3+ yrs. =>
Consumer adoption <= Dur. 5+ yrs. =>
Enterprise adopt. <= 3+ yrs. =>
Asia
Europe
39
IPv6 Timeline
(A pragmatic projection)
2000
2001
2002
2003
2004
2005
2006
2007
Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q Q
1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4 1 2 3 4
Early adopter
Appl. Porting <= Duration 3+ yrs.
=>
ISP adoption <= Dur. 3+ yrs. =>
Consumer adoption <= Dur. 5+ yrs. =>
Enterprise adopt. <= 3+ yrs. =>
Asia
Europe
Americas
40
Cisco IOS Roadmap:
The Confluence of IPv4/IPv6
IOS
Release
IOS
Phase I
upgrade IOS
=
12.2(2)T
Free IPv6
Market Target
Early Adopter Deployment
Done
Phase II
H2 CY 2001
Phase III
CY 2002
Production Backbone
Deployment
Enhanced IPv6 Services
41
Cisco IOS Roadmap
IOS
Release
IPv6 Features
Supported
Basic IPv6 specifications support
Multi-protocol Extensions for BGP4,
RIPv6. Manual, Automatic & 6to4
Tunnel Support. Tools such as Ping,
Traceroute,etc.
Done
Enhanced Performance (CEF/dCEFv6),
Phase II
Link State IGP (I/IS-ISv6), IPv6 Edge
H2 CY 2001 router (6PE) over MPLS, Dial, NAT-PT,
Enhanced tools (SSH, DNS client, MIB,
etc.)
IOS
Phase I
upgrade IOS
=
12.2(2)T
Free IPv6
Phase III
CY 2002
Hardware Acceleration, OSPFv3,
Mobility, Multicast, Security, QoS…
42
Much Still To Do
though IPv6 today has all the functional capability of IPv4,
• implementations are not as advanced
(e.g., with respect to performance, multicast support, compactness,
instrumentation, etc.)
• deployment has only just begun
• much work to be done moving application, middleware,
and management software to IPv6
• much training work to be done
(application developers, network administrators, sales staff,…)
• many of the advanced features of IPv6 still need
specification, implementation, and deployment work
43
Recent IPv6 “Hot Topics” in the IETF
•
multihoming
•
enhanced router-to-host info
•
address selection
•
site renumbering procedures
•
address allocation
•
inter-domain multicast routing
•
DNS discovery
•
•
3GPP usage of IPv6
address propagation and AAA
issues of different access scenarios
•
anycast addressing
•
end-to-end security vs. firewalls
•
scoped address architecture
•
•
flow-label semantics
•
API issues
(flow label, traffic class, PMTU
discovery, scoping,…)
and, of course, transition /
co-existence / interoperability
with IPv4
(a bewildering array of transition
tools and techniques)
Note: this indicates vitality, not incompleteness, of IPv6!
44
Impediments to IPv6 Deployment
• Applications
• Applications
• Applications
45
Information
• http://www.cisco.com/ipv6
46
Questions?
2213
1313_06_2000_c2
© 2000, Cisco Systems, Inc.
47