Introduction to IPv6
Outline





Protocol Background
Technology Highlights
Enhanced Capabilities
Transition Issues
Next Steps
Background
Why a New IP?

1991 – ALE WG studied projections about
address consumption rate showed exhaustion
by 2008.

Bake-off in mid-1994 selected approach of a
new protocol over multiple layers of
encapsulation.
What Ever Happened to IPv5?
0
IP
(deprecated)
IP
IP
IP
IPv4
ST
March 1977 version
1
January 1978 version
(deprecated)
2
February 1978 version A
(deprecated)
3
February 1978 version B
(deprecated)
4
September 1981 version (current widespread)
5
Stream Transport
(not a new IP, little
use)
6
IPv6
December 1998 version (formerly SIP, SIPP)
7
CATNIP IPng evaluation (formerly TP/IX; deprecated)
8
Pip
IPng evaluation
(deprecated)
9
TUBA
IPng evaluation
(deprecated)
10-15
unassigned
What about technologies & efforts
to slow the consumption rate?

Dial-access / PPP / DHCP


Strict allocation policies


Reduced allocation rates by policy of ‘current-need’ vs. previous
policy based on ‘projected-maximum-size’.
CIDR


Provides temporary allocation aligned with actual endpoint use.
Aligns routing table size with needs-based address allocation policy.
Additional enforced aggregation actually lowered routing table
growth rate to linear for a few years.
NAT

Hides many nodes behind limited set of public addresses.
What did intense conservation efforts
of the last 5 years buy us?

Actual allocation history






1981 – IPv4 protocol published
1985 ~ 1/16 total space
1990 ~ 1/8 total space
1995 ~ 1/4 total space
2000 ~ 1/2 total space
The lifetime-extending efforts & technologies
delivered the ability to absorb the dramatic
growth in consumer demand during the late
90’s.
In short they bought – TIME –
Would increased use of
NATs be adequate?


NAT enforces a ‘client-server’ application model where the server has
topological constraints.





NO!
They won’t work for peer-to-peer or devices that are “called” by
others (e.g., IP phones)
They inhibit deployment of new applications and services, because all
NATs in the path have to be upgraded BEFORE the application can be
deployed.
NAT compromises the performance, robustness, and security of the
Internet.
NAT increases complexity and reduces manageability of the local
network.
Public address consumption is still rising even with current NAT
deployments.
What were the goals of a
new IP design?

Expectation of a resurgence of “always-on”
technologies


xDSL, cable, Ethernet-to-the-home, Cell-phones, etc.
Expectation of new users with multiple devices.


China, India, etc. as new growth
Consumer appliances as network devices


(1015 endpoints)
Expectation of millions of new networks.

Expanded competition and structured delegation.

(1012 sites)
Return to an End-to-End
Architecture
New Technologies/Applications for Home Users
‘Always-on’—Cable, DSL, Ethernet@home, Wireless,…
Always-on Devices
Need an Address
When You Call Them
Global
Addressing
Realm
Why is a larger address space
needed?

Overall Internet is still growing its user base


:
~550 million users by 2005
Users expanding their connected device count







~320 million users in 2000
405 million mobile phones in 2000, over 1 billion by 2005
UMTS Release 5 is Internet Mobility, ~ 300M new Internet connected
~1 Billion cars in 2010
15% likely to use GPS and locality based Yellow Page services
Billions of new Internet appliances for Home users
Always-On ; Consumer simplicity required
Emerging population/geopolitical & economic drivers


MIT, Xerox, & Apple each have more address space than all of China
Moving to an e-Economy requires Global Internet accessibility
Why Was 128 Bits Chosen
as the IPv6 Address Size?
Proposals for fixed-length, 64-bit addresses



Accommodates 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 on current CPU hardware
Proposals for variable-length, up to 160 bits



Compatible with deployed OSI NSAP addressing plans
Accommodates auto-configuration using IEEE 802 addresses
Sufficient structure for projected number of service providers
Settled on fixed-length, 128-bit addresses

(340,282,366,920,938,463,463,374,607,431,768,211,456 in all!)
Benefits of
128 bit Addresses




Room for many levels of structured hierarchy
and routing aggregation
Easy address auto-configuration
Easier address management and delegation
than IPv4
Ability to deploy end-to-end IPsec
(NATs removed as unnecessary)
Incidental Benefits of
New Deployment

Chance to eliminate some complexity in IP
header


Chance to upgrade functionality


improve per-hop processing
multicast, QoS, mobility
Chance to include new features

binding updates
Summary of Main IPv6 Benefits





Expanded addressing capabilities
Structured hierarchy to manage routing table growth
Serverless autoconfiguration and reconfiguration
Streamlined header format and flow identification
Improved support for options / extensions
IPv6 Advanced Features





Source address selection
Mobility - More efficient and robust mechanisms
Security - Built-in, strong IP-layer encryption and
authentication
Quality of Service
Privacy Extensions for Stateless Address
Autoconfiguration (RFC 3041)
IPv6 Markets

Home Networking



Gaming (10B$ market)





Sony, Sega, Nintendo, Microsoft
Mobile devices
Consumer PC
Consumer Devices


Set-top box/Cable/xDSL/Ether@Home
Residential Voice over IP gateway
Sony (Mar/01 - …energetically introducing IPv6 technology into hardware products …)
Enterprise PC
Service Providers

Regional ISP, Carriers, Mobile ISP, and Greenfield ISP’s
IPv6 Markets

Academic NRN:


Geographies & Politics:




Internet-II (Abilene, vBNS+), Canarie*3, Renater-II, Surfnet, DFN,
CERNET,… 6REN/6TAP
Prime Minister of Japan called for IPv6 (taxes reduction)
EEC summit PR advertised IPv6 as the way to go for Europe
China Vice minister of MII deploying IPv6 with the intent to take a
leadership position and create a market force
Wireless (PDA, Mobile, Car,...):



Multiple phases before deployment
RFP -> Integration -> trial -> commercial
Requires ‘client devices’, eg. IPv6 handset ?
Outline





Protocol Background
Technology Highlights
Enhanced Capabilities
Transition Issues
Next Steps
A new Header
The IPv6 Header
40 Octets, 8 fields
0
4
Version
12
Class
16
24
31
Flow Label
Payload Length
Next Header
128 bit Source Address
128 bit Destination Address
Hop Limit
The IPv4 Header
20 octets + options : 13 fields, including 3 flag bits
0
4
Ver
8
IHL
16
Service Type
Identifier
Time to Live
24
Total Length
Flags
Protocol
Fragment Offset
Header Checksum
32 bit Source Address
32 bit Destination Address
Options and Padding
shaded fields are absent from IPv6 header
31
Summary of Header Changes
between
IPv4 & IPv6
Streamlined








Revised





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
Time to Live  Hop Limit
Protocol  Next Header
Precedence & TOS  Traffic Class
Addresses increased 32 bits  128 bits
Extended

Flow Label field added
Extension Headers
IPv6 header
TCP header + data
next header =
TCP
IPv6 header
Routing header
TCP header + data
next header =
Routing
next header =
TCP
IPv6 header
Routing header
Fragment header
next header =
Routing
next header =
Fragment
next header =
TCP
fragment of TCP
header + data
Extension Headers (cont.)

Generally processed only by node identified in
IPv6 Destination Address field => much lower
overhead than IPv4 options processing


Eliminated IPv4’s 40-byte limit on options


exception: Hop-by-Hop Options header
in IPv6, limit is total packet size,
or Path MTU in some cases
Currently defined extension headers:

Hop-by-Hop Options, Routing, Fragment,
Authentication, Encryption, Destination Options
Fragment Header
Next Header


Reserved
Fragment Offset
Original Packet Identifier
00M
though discouraged, can use IPv6 Fragment
header to support upper layers that do not (yet)
do path MTU discovery
IPv6 frag. & reasm. is an end-to-end function;
routers do not fragment packets en-route if too
big—they send ICMP “packet too big” instead
Routing Header
Routing


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, …
Use of Routing header with anycast addresses
allows routing packets through particular regions

e.g., for provider selection, policy, performance, etc.
Routing Header
Next Header
Hdr Ext Len
Routing Type
Reserved
Address[0]
Address[1]
•
•
•
Segments Left
Example of Using the Routing
Header
S
A
B
D
Addressing
Some Terminology
node
router
host
link
neighbors
interface
address
a protocol module that implements IPv6
a node that forwards IPv6 packets not explicitly
addressed to itself
any node that is not a router
a communication facility or medium over which
nodes can communicate at the link layer,
i.e., the layer immediately below IPv6
nodes attached to the same link
a node’s attachment to a link
an IPv6-layer identifier for an interface or a set
of interfaces
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 FF01::43
IPv4-compatible: 0:0:0:0:0:0:13.1.68.3
or ::13.1.68.3
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

Addresses have lifetime
Valid and Preferred lifetime
Site-Local
Link-Local
Types of IPv6 Addresses

Unicast



Multicast



Address of a set of interfaces
Delivery to all interfaces in the set
Anycast



Address of a single interface
Delivery to single interface
Address of a set of interfaces
Delivery to a single interface in the set
No more broadcast addresses
Interface Address set

Loopback




Link local
Site local
Auto-configured 6to4





(if IPv4 public is address available)
Auto-configured IPv4 compatible


(only assigned to a single virtual interface per node)
(operationally discouraged)
Solicited node Multicast
All node multicast
Global anonymous
Global published
Source Address Selection Rules


Rule 1: Prefer same address
Rule 2: Prefer appropriate scope





Rule 3: Avoid deprecated addresses
Rule 4: Prefer home addresses
Rule 5: Prefer outgoing interface
Rule 6: Prefer matching label from policy table

Native IPv6 source > native IPv6 destination
6to4 source > 6to4 destination
IPv4-compatible source > IPv4-compatible destination
IPv4-mapped source> IPv4-mapped destination

Local policy may override





Smallest matching scope
Rule 7: Prefer temporary addresses
Rule 8: Use longest matching prefix
Destination Address Selection
Rules





Rule 1: Avoid unusable destinations
Rule 2: Prefer matching scope
Rule 3: Avoid dst with matching deprecated src address
Rule 4: Prefer home addresses
Rule 5: Prefer matching label from policy table

Native IPv6 source > native IPv6 destination
6to4 source > 6to4 destination
IPv4-compatible source > IPv4-compatible destination
IPv4-mapped source> IPv4-mapped destination

Local policy may override







Rule 6: Prefer higher precedence
Rule 7: Prefer smaller scope
Rule 8: Use longest matching prefix
Rule 9: Order returned by DNS
Address Type Prefixes
Address type
IPv4-compatible
global unicast
link-local unicast
site-local unicast
multicast


Binary prefix
0000...0 (96 zero bits)
001
1111 1110 10
1111 1110 11
1111 1111
all other prefixes reserved (approx. 7/8ths of total)
anycast addresses allocated from unicast prefixes
Global Unicast Addresses
001
TLA
NLA*
public
topology
(45 bits)



SLA*
site
topology
(16 bits)
interface ID
interface
identifier
(64 bits)
TLA = Top-Level Aggregator
NLA* = Next-Level Aggregator(s)
SLA* = Site-Level Aggregator(s)
all subfields variable-length, non-self-encoding (like
CIDR)
TLAs may be assigned to providers or exchanges
Link-Local & Site-Local Unicast
Addresses
Link-local addresses for use during auto-configuration
and when no routers are present:
0
1111111010
interface ID
Site-local addresses for independence from changes
of TLA / NLA*:
1111111011
0
SLA*
interface ID
Interface IDs
Lowest-order 64-bit field of unicast address
may be assigned in several different ways:





auto-configured from a 64-bit EUI-64, or expanded
from a 48-bit MAC address (e.g., Ethernet address)
auto-generated pseudo-random number
(to address privacy concerns)
assigned via DHCP
manually configured
possibly other methods in the future
Some Special-Purpose Unicast
Addresses

The unspecified address, used as a placeholder when
no address is available:
0:0:0:0:0:0:0:0

The loopback address, for sending packets to self:
0:0:0:0:0:0:0:1
Multicast Address Format
FP (8bits)
Flags (4bits)
Scope (4bits)
RESERVED (80bits)
Group ID (32bits)
11111111
000T
Lcl/Sit/Gbl
MUST be 0
Locally administered

flag field



scope field:





low-order bit indicates permanent/transient group
(three other flags reserved)
1 - node local
2 - link-local
5 - site-local
(all other values reserved)
8 - organization-local
B - community-local
E - global
map IPv6 multicast addresses directly into low order
32 bits of the IEEE 802 MAC
Multicast Address Format
Unicast-Prefix based



FP (8bits)
Flags (4bits)
Scope (4bits)
reserved (8bits)
plen (8bits)
Network Prefix
(64bits)
Group ID (32bits)
11111111
00PT
Lcl/Sit/Gbl
MUST be 0
Locally
administered
Unicast prefix
Auto configured
P = 1 indicates a multicast address that is assigned based on the
network prefix
plen indicates the actual length of the network prefix
Source-specific multicast addresses is accomplished by setting



P=1
plen = 0
network prefix = 0

draft-ietf-ipngwg-uni-based-mcast-01.txt
Outline





Protocol Background
Technology Highlights
Enhanced Capabilities
Transition Issues
Next Steps
Security
IPv6 Security




All implementations required to support
authentication and encryption headers (“IPsec”)
Authentication separate from encryption for use
in situations where encryption is prohibited or
prohibitively expensive
Key distribution protocols are under
development (independent of IP v4/v6)
Support for manual key configuration required
Authentication Header
Next Header
Hdr Ext Len
Reserved
Security Parameters Index (SPI)
Sequence Number
Authentication Data



Destination Address + SPI identifies security
association state (key, lifetime, algorithm, etc.)
Provides authentication and data integrity for all fields
of IPv6 packet that do not change en-route
Default algorithm is Keyed MD5
Encapsulating Security Payload
(ESP)
Security Parameters Index (SPI)
Sequence Number
Payload
Padding
Padding Length
Authentication Data
Next Header
Quality of Service
IP Quality of Service Approaches
Two basic approaches developed by IETF:
 “Integrated Service” (int-serv)


fine-grain (per-flow), quantitative promises
(e.g., x bits per second), uses RSVP signaling
“Differentiated Service” (diff-serv)

coarse-grain (per-class), qualitative promises
(e.g., higher priority), no explicit signaling
IPv6 Support for Int-Serv
20-bit Flow Label field to identify specific
flows needing special QoS



each source chooses its own Flow Label
values; routers use Source Addr + Flow
Label to identify distinct flows
Flow Label value of 0 used when no special
QoS requested (the common case today)
this part of IPv6 is not standardized yet, and
may well change semantics in the future
IPv6 Support for Diff-Serv
8-bit Traffic Class field to identify specific
classes of packets needing special QoS



same as new definition of IPv4 Type-ofService byte
may be initialized by source or by router
enroute; may be rewritten by routers enroute
traffic Class value of 0 used when no special
QoS requested (the common case today)
Compromise

Signaled diff-serv (RFC 2998)


uses RSVP for signaling with course-grained
qualitative aggregate markings
allows for policy control without requiring per-router
state overhead
Mobility
IPv6 Mobility

Mobile hosts have one or more home address


A Host will acquire a foreign address when it discovers it
is in a foreign subnet (i.e., not its home subnet)




relatively stable; associated with host name in DNS
uses auto-configuration to get the address
registers the foreign address with a home agent,
i.e, a router on its home subnet
Packets sent to the mobile’s home address(es) are
intercepted by home agent and forwarded to the foreign
address, using encapsulation
Mobile IPv6 hosts will send binding-updates to
correspondent to remove home agent from flow
Mobile IP (v4 version)
mobile host
correspondent
host
foreign agent
home agent
home location of mobile host
Mobile IP (v4 version)
mobile host
correspondent
host
foreign agent
home agent
home location of mobile host
Mobile IP (v4 version)
mobile host
correspondent
host
foreign agent
home agent
home location of mobile host
Mobile IP (v4 version)
mobile host
correspondent
host
foreign agent
home agent
home location of mobile host
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
Mobile IP (v6 version)
mobile host
correspondent
host
home agent
home location of mobile host
IPv6 Routing
RIPng


RIPv2, supports split-horizon with
poisoned reverse
RFC2080
BGP4+ Overview





Added IPv6 address-family
Added IPv6 transport
Runs within the same process - only one
AS supported
All generic BGP functionality works as for
IPv4
Added functionality to route-maps and
prefix-lists
IPv6 routing

OSPF & ISIS updated for IPv6
Outline





Protocol Background
Technology Highlights
Enhanced Capabilities
Transition Issues
Next Steps
Porting Issues
Effects on higher layers






Changes TCP/UDP checksum “pseudo-header”
Affects anything that reads/writes/stores/passes IP
addresses (just about every higher protocol)
Packet lifetime no longer limited by IP layer
(it never was, anyway!)
Bigger IP header must be taken into account when
computing max payload sizes
New DNS record type: AAAA and (new) A6
…
Sockets API Changes








Name to Address Translation Functions
Address Conversion Functions
Address Data Structures
Wildcard Addresses
Constant Additions
Core Sockets Functions
Socket Options
New Macros
Core Sockets Functions

Core APIs
Use
IPv6 Family and Address Structures
socket() Uses PF_INET6

Functions that pass addresses
bind()
connect()
sendmsg()
sendto()

Functions that return addresses
accept()
recvfrom()
recvmsg()
getpeername()
getsockname()
Name
to
Address
Translation

getaddrinfo()

Pass in nodename and/or servicename string
Can Be Address and/or Port


Optional Hints for Family, Type and Protocol


Pointer to Linked List of addrinfo structures Returned


Flags – AI_PASSIVE, AI_CANNONNAME, AI_NUMERICHOST,
AI_NUMERICSERV, AI_V4MAPPED, AI_ALL, AI_ADDRCONFIG
Multiple Addresses to Choose From
freeaddrinfo()
struct addrinfo {
int ai_flags;
int ai_family;
int getaddrinfo(
int ai_socktype;
IN const char FAR * nodename,
int ai_protocol;
IN const char FAR * servname,
size_t ai_addrlen;
IN const struct addrinfo FAR * hints,
char *ai_canonname;
OUT struct addrinfo FAR * FAR * res
struct sockaddr *ai_addr;
);
struct addrinfo *ai_next;
};
Address
to Name Translation
getnameinfo()


Pass in address (v4 or v6) and port



Size Indicated by salen
Also Size for Name and Service buffers (NI_MAXHOST, NI_MAXSERV)
Flags





NI_NOFQDN
NI_NUMERICHOST
NI_NAMEREQD
NI_NUMERICSERV
NI_DGRAM
int getnameinfo(
IN const struct sockaddr FAR * sa,
IN socklen_t salen,
OUT char FAR * host,
IN size_t hostlen,
OUT char FAR * serv,
IN size_t servlen,
IN int flags
);
Porting Environments

Node Types




Application Types




IPv4-only
IPv6-only
IPv6/IPv4
IPv6-unaware
IPv6-capable
IPv6-required
IPv4 Mapped Addresses
Porting Issues

Running on ANY System

Including IPv4-only

Address Size Issues

New IPv6 APIs for IPv4/IPv6

Ordering of API Calls

User Interface Issues

Higher Layer Protocol Changes
Specific things to look for

Storing IP address in 4 bytes of an array.

Use of explicit dotted decimal format in UI.

Obsolete / New:

AF_INET
replaced by
AF_INET6

SOCKADDR_IN
replaced by
SOCKADDR_STORAGE

IPPROTO_IP
replaced by
IPPROTO_IPV6

IP_MULTICAST_LOOP replaced by SIO_MULTIPOINT_LOOPBACK

gethostbyname
replaced by
getaddrinfo

gethostbyaddr
replaced by
getnameinfo
IPv6 literal addresses in URL’s
From RFC 2732
Literal IPv6 Address Format in URL's Syntax To use a literal IPv6 address in a
URL, the literal address should be enclosed in "[" and "]" characters. For
example the following literal IPv6 addresses:
FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
3ffe:2a00:100:7031::1
::192.9.5.5
2010:836B:4179::836B:4179

would be represented as in the following example URLs:
http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html
http://[3ffe:2a00:100:7031::1]
http://[::192.9.5.5]/ipng
http://[2010:836B:4179::836B:4179]
Other Issues

Renumbering & Mobility routinely result in changing IP
Addresses –



Use Names and Resolve, Don’t Cache
Multihomed Servers

More Common with IPv6

Try All Addresses Returned
Using New IPv6 Functionality
Porting Steps -Summary

Use IPv4/IPv6 Protocol/Address Family

Fix Address Structures
in6_addr
sockaddr_in6
sockaddr_storage

to allocate storage
Fix Wildcard Address Use
in6addr_any,
IN6ADDR_ANY_INIT
in6addr_loopback, IN6ADDR_LOOPBACK_INIT

Use IPv6 Socket Options
IPPROTO_IPV6,

Options as Needed
Use getaddrinfo()
For
Address Resolution
IPv4 - IPv6
Co-Existence / Transition
IPv6 Timeline
(A pragmatic projection)
2000
2001
2002
2003
2004
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
2005
2006
2007
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
• Early adopter
• Application porting <= Duration 3+ years
=>
• ISP adoption <= Duration 3+ years =>
• Consumer adoption
<=
Duration 5+ years =>
• Enterprise adoption <= Duration 3+ years =>
Deployments

IPv6 deployments will occur piecewise
from the edge.

Core infrastructure only moving when
significant customer usage demands it.

Platforms and products that are updated first
need to address the lack of ubiquity.
Whenever possible, devices and applications
should be capable of both IPv4 & IPv6, to
minimize the delays and potential failures
inherent in translation points.
Impediments to IPv6 deployment



Applications
Applications
Applications

Move to the new APIs NOW
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
co-exist 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
Dual-Stack Approach

When adding IPv6 to a system, do not delete IPv4



this multi-protocol approach is familiar and
well-understood (e.g., for AppleTalk, IPX, etc.)
note: in most cases, IPv6 will be bundled with
new OS releases, not an extra-cost add-on
Applications (or libraries) choose IP version to use

when initiating, based on DNS response:
Prefer


scope match first, when equal IPv6 over IPv4
when responding, based on version of initiating packet
This allows indefinite co-existence of IPv4 and IPv6, and gradual
app-by-app upgrades to IPv6 usage
Tunnels to Get Through
IPv6-Ignorant Routers


Encapsulate IPv6 packets inside IPv4 packets
(or MPLS frames)
Many methods exist for establishing tunnels:






manual configuration
“tunnel brokers” (using web-based service to create a tunnel)
automatic (depricated, using IPv4 as low 32bits of IPv6)
“6-over-4” (intra-domain, using IPv4 multicast as virtual LAN)
“6-to-4” (inter-domain, using IPv4 addr as IPv6 site prefix)
Can view this as:


IPv6 using IPv4 as a virtual NBMA link-layer, or
an IPv6 VPN (virtual public network), over the IPv4 Internet
Translation

May prefer to use IPv6-IPv4 protocol translation for:



new kinds of Internet devices (e.g., cell phones, cars,
appliances)
benefits of shedding IPv4 stack (e.g., serverless
autoconfig)
This is a simple extension to NAT techniques, to
translate header format as well as addresses



IPv6 nodes behind a translator get full IPv6 functionality
when talking to other IPv6 nodes located anywhere
they get the normal (i.e., degraded) NAT functionality when
talking to IPv4 devices
drawback : minimal gain over IPv4/IPv4 NAT approach
Tunnels



6to4
Configured
Automatic
6to4 tunnels
FP (3bits)
TLA (13bits)
IPv4 Address (32bits)
SLA ID (16bits)
Interface ID (64bits)
001
0x0002
ISP assigned
Locally administered
Auto configured
2002:8243:1::/48
2002:947A:1::/48
IPv4
IPv6
IPv6
148.122.0.1
130.67.0.1
11.0.0.1
6to4 prefix is 2002::/16 + IPv4 address.
2002:a.b.c.d::/48
IPv6 Internet
6to4 relay
2002:B00:1::1
Announces 2002::/16 to the IPv6 Internet
6to4 tunnels II
Pros
Cons
Minimal configuration
All issues that NMBA
networks have.
Only site border router
needs to know about 6to4
Requires relay router to
reach native IPv6 Internet
Works without adjacent
native IPv6 routers
Has to use 6to4
addresses, not native.
NB: there is a draft describing how to use IPv4 anycast to reach the relay router.
(This is already supported, by our implementation...)
Configured tunnels
3ffe:c00:2::/48
3ffe:c00:1::/48
IPv4
IPv6
IPv6
130.67.0.1
-------------------------------------|IPv4 header|IPv6 header IPv6 payload|
-------------------------------------IPv4 protocol type = 41
148.122.0.1
Configured tunnels II
Pros
Cons
As point to point links
Has to be configured and
managed
Multicast
Inefficient traffic patterns
Real addresses
No keepalive mechanism,
interface is always up
Automatic tunnels
0
IPv4 Address (32bits)
Defined
ISP assigned
148.122.0.1
::148.122.0.1
130.67.0.1
::130.67.0.1
IPv6
Connects dual stacked nodes
Quite obsolete
IPv4
IPv6
IPv6 Internet
Automatic tunnels II
Pros
Cons
Obsolete
Difficult to reach the native
IPv6 Internet, without
injecting IPv4 routing
information in the IPv6
routing table
Useful for some other
mechanisms, like BGP
tunnels
Has to use IPv4
compatible addresses
Tunneling issues




IPv4 fragmentation needs to be reconstructed at
tunnel endpoint.
No translation of Path MTU messages between
IPv4 & IPv6.
Translating IPv4 ICMP messages and pass back
to IPv6 originator.
May result in an inefficient topology.
Tunneling issues II


Tunnel interface is always up. Use routing
protocol to determine link failures.
Be careful with using the same IPv4 source
address for several tunneling mechanisms.
Demultiplexing incoming packets is difficult.
Deployment scenarios

Many ways to deliver IPv6 services to End Users




Service Providers and Enterprises may have
different deployment needs
IPv6 over IPv4 tunnels
Dedicated Data Link layers for native IPv6


Most important is End to End IPv6 traffic forwarding
no impact on IPv4 traffic & revenues
Dual stack Networks

IPv6 over MPLS or IPv4-IPv6 Dual Stack Routers
Media - Interface Identifier



IEEE interfaces - EUI-64
 MAC-address: 0050.a218.0c38
 Interface ID: 250:A2FF:FE18:C38
P2P links (HDLC, PPP)
 Interface ID: 50:A218:C00:D
 48 bits from the first MAC address in the box + 16
bit interface index. U/L bit off
IPv4 tunnels
 Interface ID: ::a.b.c.d
Outline





Protocol Background
Technology Highlights
Enhanced Capabilities
Transition Issues
Next Steps
Current Status
Standards

core IPv6 specifications are IETF Draft
Standards
=> well-tested & stable


other important specs are further behind on the
standards track, but in good shape



IPv6 base spec, ICMPv6, Neighbor Discovery, PMTU
Discovery, IPv6-over-Ethernet, IPv6-over-PPP,...
mobile IPv6, header compression, A6 DNS support,...
for up-to-date status: playground.sun.com/ipng
UMTS R5 cellular wireless standards mandate
IPv6
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, Epilogue,
Ericsson/Telebit, IBM, Hitachi, NEC, Nortel, Sun, Trumpet
others have beta releases now, supported products soon,
e.g., Compaq, 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
IPv6 Addresses
Bootstrap phase

Where to get address space?





Real IPv6 address space now allocated
by APNIC, ARIN and RIPE NCC
APNIC
ARIN
RIPE NCC
6Bone
2001:0200::/23
2001:0400::/23
2001:0600::/23
3FFE::/16
Have a look at www.cisco.com/ipv6 for further information
IPv6 Address Space
Current Allocations

APNIC (whois.apnic.net)
CONNECT-AU-19990916 2001:210::/35
WIDE-JP-19990813 2001:200::/35
SONYTELECOM-JPNIC-JP-20001207 2001:298::/35
TTNET-JPNIC-JP-20001208 2001:2A0::/35
CCCN-JPNIC-JP-20001228 2001:02A8::/35
IMNET-JPNIC-JP-20000314 2001:0248::/35
NUS-SG-19990827 2001:208::/35
KIX-KR-19991006 2001:220::/35
KORNET-KRNIC-KR-20010102 2001:02B0::/35
ETRI-KRNIC-KR-19991124 2001:230::/35

NTT-JP-19990922 2001:218::/35
ESNET-V6 2001:0400::/35
ARIN-001 2001:0400::/23
VBNS-IPV6 2001:0408::/35
CANET3-IPV6 2001:0410::/35
VRIO-IPV6-0 2001:0418::/35
CISCO-IPV6-1 2001:0420::/35
QWEST-IPV6-1 2001:0428::/35
DEFENSENET 2001:0430::/35
ABOVENET-IPV6 2001:0438::/35
SPRINT-V6 2001:0440::/35
UNAM-IPV6 2001:0448::/35
GBLX-V6 2001:0450::/35
HINET-TW-20000208 2001:238::/35
IIJ-JPNIC-JP-20000308 2001:240::/35
CERNET-CN-20000426 2001:250::/35
INFOWEB-JPNIC-JP-2000502 2001:258::/35
JENS-JP-19991027 2001:228::/35
BIGLOBE-JPNIC-JP-20000719 2001:260::/35
6DION-JPNIC-JP-20000829 2001:268::/35
DACOM-BORANET-20000908 2001:270::/35
ODN-JPNIC-JP-20000915 2001:278::/35
KOLNET-KRNIC-KR-20000927 2001:280::/35
HANANET-KRNIC-KR-20001030 2001:290::/35
TANET-TWNIC-TW-20001006 2001:288::/35
ARIN (whois.arin.net)
January 5th, 2001
IPv6 Address Space
Current Allocations

RIPE (whois.ripe.net)
EU-EUNET-20000403 2001:0670::/35
UK-BT-19990903 2001:0618::/35
DE-IPF-20000426 2001:0678::/35
CH-SWITCH-19990903 2001:0620::/35
DE-NACAMAR-20000403 2001:0668::/35
AT-ACONET-19990920 2001:0628::/35
DE-XLINK-20000510 2001:0680::/35
UK-JANET-19991019 2001:0630::/35
DE-DFN-19991102 2001:0638::/35
NL-SURFNET-19990819 2001:0610::/35
DE-ECRC-19991223 2001:0650::/35
FR-TELECOM-20000623 2001:0688::/35
PT-RCCN-20000623 2001:0690::/35
SE-SWIPNET-20000828 2001:0698::/35
RU-FREENET-19991115 2001:0640::/35
GR-GRNET-19991208 2001:0648::/35
EU-UUNET-19990810 2001:0600::/35
DE-TRMD-20000317 2001:0658::/35
FR-RENATER-20000321 2001:0660::/35
PL-ICM-20000905 2001:06A0::/35
DE-SPACE-19990812 2001:0608::/35
BE-BELNET-20001101 2001:06A8::/35
SE-SUNET-20001218 2001:06B0::/35
IT-CSELT-20001221 2001:06B8::/35
SE-TELIANET-20010102 2001:06C0::/35
Deployment

experimental infrastructure: the 6bone


production infrastructure in support of education
and research: the 6ren


for testing and debugging IPv6 protocols and
operations (see www.6bone.net)
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, SURFnet, Trumpet,…) have
announced commercial IPv6 service or service trials
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
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
Recent IPv6 “Hot Topics” in the
IETF








multihoming / address
selection
address allocation
DNS discovery
3GPP usage of IPv6
anycast addressing
scoped address
architecture
flow-label semantics
API issues






enhanced router-to-host info
site renumbering procedures
temp. addresses for privacy
inter-domain multicast routing
address propagation and AAA
issues of different access
scenarios


(always-on, dial-up, mobile,…)
and, of course, transition /
co-existence / interoperability
with IPv4
(flow label, traffic class, PMTU
discovery, scoping,…)
Note: this indicates vitality, not incompleteness, of IPv6!
Next Steps
For More Information




http://www.ietf.org/html.charters/ipngwgcharter.html
http://www.ietf.org/html.charters/ngtranscharter.html
http://playground.sun.com/ipv6/
http://www.6bone.net/ngtrans/
For More Information





http://www.6bone.net
http://www.ipv6forum.com
http://www.ipv6.org
http://www.cisco.com/ipv6/
http://www.microsoft.com/windows2000/librar
y/howitworks/communications/networkbasics/
IPv6.asp
For More Information

BGP4+ References


RFC2858 Multiprotocol extension to BGP
RFC2545 BGP MP for IPv6
RFC2842 Capability negotiation
RIPng RFC2080
Other Sources of Information

Books



IPv6, The New Internet Protocol
by Christian Huitema (Prentice Hall)
Internetworking IPv6 with Cisco Routers
by Silvano Gai (McGraw-Hill)
and many more... (14 hits at Amazon.com)
Questions?
2213
1313_06_2000_c2
© 2000, Cisco Systems, Inc.
119
Cisco Systems