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
March 1977 version
(deprecated)
1
IP
January 1978 version
(deprecated)
2
IP
February 1978 version A (deprecated)
3
IP
February 1978 version B (deprecated)
4
IPv4
September 1981 version (current widespread)
5
ST
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
90s.
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 wont 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-onCable, 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 ISPs

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 IPv4s 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
bigthey 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

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 nodes 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
Rule
Rule
Rule

Smallest matching scope

3:
4:
5:
6:

Avoid deprecated addresses

Prefer home addresses
Prefer outgoing interface
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

Rule 7: Prefer temporary addresses

Rule 8: Use longest matching prefix

Local policy may override

Destination Address Selection

Rules

Rule
Rule
Rule
Rule
Rule

Avoid unusable destinations

Prefer matching scope
Avoid dst with matching deprecated src address
Prefer home addresses
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

Rule
Rule
Rule
Rule

1:
2:
3:
4:
5:

6:
7:
8:
9:

Prefer higher precedence

Prefer smaller scope
Use longest matching prefix
Order returned by DNS

Local policy may override

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

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)
11111111

RESERVED (80bits)

Group ID (32bits)

Lcl/Sit/Gbl

MUST be 0

Locally administered

low-order bit indicates permanent/transient group

(three other flags reserved)

scope field:

Scope (4bits)

flag field

Flags
(4bits)
000T

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 mobiles 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
struct addrinfo
addrinfo {{
int
int ai_flags;
ai_flags;
int
ai_family;
int ai_family;
int
int getaddrinfo(
getaddrinfo(
int
int ai_socktype;
ai_socktype;
IN
const
char
FAR
*
nodename,
IN const char FAR * nodename,
int
ai_protocol;
int ai_protocol;
IN
IN const
const char
char FAR
FAR ** servname,
servname,
size_t
size_t ai_addrlen;
ai_addrlen;
IN
IN const
const struct
struct addrinfo
addrinfo FAR
FAR ** hints,
hints,
char
*ai_canonname;
char *ai_canonname;
OUT
OUT struct
struct addrinfo
addrinfo FAR
FAR ** FAR
FAR ** res
res
struct
struct sockaddr
sockaddr *ai_addr;
*ai_addr;
);
);
struct
addrinfo
*ai_next;
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
int getnameinfo(
getnameinfo(
IN
IN const
const struct
struct sockaddr
sockaddr FAR
FAR ** sa,
sa,
IN
socklen_t
salen,
IN socklen_t salen,
OUT
OUT char
char FAR
FAR ** host,
host,
IN
size_t
hostlen,
IN size_t hostlen,
OUT
OUT char
char FAR
FAR ** serv,
serv,
IN
size_t
servlen,
IN size_t servlen,
IN
IN int
int flags
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 URLs

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, Dont 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

Q Q Q Q Q Q Q Q
1 2 3 4 1 2 3 4

2002

2003

2004

Q Q Q Q
1 2 3 4

Q Q Q Q
1 2 3 4

2005

Q Q Q Q Q Q Q Q
1 2 3 4 1 2 3 4

2006

2007

Q Q Q Q
1 2 3 4

Q Q Q Q
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)
001

TLA
(13bits)
0x0002

IPv4 Address (32bits)

ISP assigned

SLA ID (16bits)
Locally
administered

Interface ID (64bits)
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
130.67.0.1

-------------------------------------|IPv4 header|IPv6 header IPv6 payload|

-------------------------------------IPv4 protocol type = 41

IPv6
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
NUS-SG-19990827 2001:208::/35
KIX-KR-19991006 2001:220::/35
ETRI-KRNIC-KR-19991124 2001:230::/35
NTT-JP-19990922 2001:218::/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

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
KORNET-KRNIC-KR-20010102 2001:02B0::/35

ARIN (whois.arin.net)

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

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
UK-JANET-19991019 2001:0630::/35
DE-DFN-19991102 2001:0638::/35
NL-SURFNET-19990819 2001:0610::/35
RU-FREENET-19991115 2001:0640::/35

DE-XLINK-20000510 2001:0680::/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
PL-ICM-20000905 2001:06A0::/35

GR-GRNET-19991208 2001:0648::/35

DE-SPACE-19990812 2001:0608::/35

EU-UUNET-19990810 2001:0600::/35

BE-BELNET-20001101 2001:06A8::/35

DE-TRMD-20000317 2001:0658::/35

SE-SUNET-20001218 2001:06B0::/35

FR-RENATER-20000321 2001:0660::/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