IPv6: An Introduction
Dheeraj Sanghi
Department of Computer Science and Engineering
Indian Institute of Technology Kanpur
dheeraj@iitk.ac.in
http://www.cse.iitk.ac.in/users/dheeraj
Outline



Problems with IPv4
Basic IPv6 Protocol
IPv6 features
– Auto-configuration, QoS, Security, Mobility

Apr 2005
Transition Plans
IIT Kanpur
1
Internet Protocol
Transports a datagram from source host to destination,
possibly via several intermediate nodes (“routers”)
Service is:



Unreliable: Losses, duplicates, out-of-order delivery
Best effort: Packets not discarded capriciously, delivery
failure not necessarily reported
Connectionless: Each packet is treated independently
Apr 2005
IIT Kanpur
2
IP Datagram Header
0
VERS
4
8
HLEN
16
TOTAL LENGTH
TOS
IDENTIFICATION
TTL
31
19
FLAG
PROTOCOL
FRAGMENT OFFSET
CHECKSUM
SOURCE ADDRESS
DESTINATION ADDRESS
OPTIONS (if any) + PADDING
Apr 2005
IIT Kanpur
3
Problems with IPv4: Limited Address Space
IPv4 has 32 bit addresses.
 Flat addressing (only netid + hostid with “fixed”
boundaries)
 Results in inefficient use of address space.
 Class B addresses are almost over.
 Addresses will exhaust in the next 5 years.
 IPv4 is victim of its own success.

Apr 2005
IIT Kanpur
4
Problems with IPv4: Routing Table Explosion




IP does not permit route aggregation
(limited supernetting possible with new routers)
Mostly only class C addresses remain
Number of networks is increasing very fast
(number of routes to be advertised goes up)
Very high routing overhead
– lot more memory needed for routing table
– lot more bandwidth to pass routing information
– lot more processing needed to compute routes
Apr 2005
IIT Kanpur
5
Problems with IPv4: Header Limitations





Maximum header length is 60 octets.
(Restricts options)
Maximum packet length is 64K octets.
(Do we need more than that ?)
ID for fragments is 16 bits. Repeats every 65537th packet.
(Will two packets in the network have same ID?)
Variable size header.
(Slower processing at routers.)
No ordering of options.
(All routers need to look at all options.)
Apr 2005
IIT Kanpur
6
Problems with IPv4: Other Limitations

Lack of quality-of-service support.
– Only an 8-bit ToS field, which is hardly used.
– Problem for multimedia services.


No support for security at IP layer.
Mobility support is limited.
Apr 2005
IIT Kanpur
7
IP Address Extension


Strict monitoring of IP address assignment
Private IP addresses for intranets
– Only class C or a part of class C to an organization
– Encourage use of proxy services
 Application level proxies
 Network Address Translation (NAT)


Remaining class A addresses may use CIDR
Reserved addresses may be assigned
But these will only postpone address exhaustion.
They do not address problems like QoS, mobility, security.
Apr 2005
IIT Kanpur
8
IPng Criteria
At least 109 networks, 1012 end-systems
 Datagram service (best effort delivery)
 Independent of physical layer technologies
 Robust (routing) in presence of failures
 Flexible topology (e.g., dual-homed nets)
 Better routing structures (e.g., aggregation)
 High performance (fast switching)
 Support for multicasting

Apr 2005
IIT Kanpur
9
IPng Criteria
Support for mobile nodes
 Support for quality-of-service
 Provide security at IP layer
 Extensible
 Auto-configuration (plug-and--play)
 Straight-forward transition plan from IPv4
 Minimal changes to upper layer protocols

Apr 2005
IIT Kanpur
10
IPv6: Distinctive Features
Header format simplification
 Expanded routing and addressing capabilities
 Improved support for extensions and options
 Flow labeling (for QoS) capability
 Auto-configuration and Neighbour discovery
 Authentication and privacy capabilities
 Simple transition from IPv4

Apr 2005
IIT Kanpur
11
IPv6 Header Format
0
4
Vers
12
16
24
Traffic Class
Flow Label
Payload Length
Next Header
31
Hop Limit
Source Address
Destination Address
Apr 2005
IIT Kanpur
12
IPv6 Header Fields
Version number (4-bit field)
The value is always 6.
 Flow label (20-bit field)
Used to label packets requesting special handling by
routers.
 Traffic class (8-bit field)
Used to mark classes of traffic.
 Payload length (16-bit field)
Length of the packet following the IPv6 header, in octets.
 Next header (8-bit field)
The type of header immediately following the IPv6 header.

Apr 2005
IIT Kanpur
13
IPv6 Header Fields
Hop limit (8-bit field)
Decremented by 1 by each node that forwards the packet.
Packet discarded if hop limit is decremented to zero.
 Source Address (128-bit field)
An address of the initial sender of the packet.
 Destination Address (128-bit field)
An address of the intended recipient of the packet. May
not be the ultimate recipient, if Routing Header is present.

Apr 2005
IIT Kanpur
14
Header Changes from IPv4
Longer address - 32 bits  128 bits
 Fragmentation field moved to separate header
 Header checksum removed
 Header length removed (fixed length header)
 Length field excludes IPv6 header
 Time to live  Hop limit
 Protocol  Next header
 64-bit field alignment
 TOS replaced by flow label, traffic class

Apr 2005
IIT Kanpur
15
Extension Headers







Less used functions moved to extension headers.
Only present when needed.
Processed only by node identified in IPv6 destination field.
=> much lower overhead than IPv4 options
Exception: Hop-by-Hop option header
Eliminated IPv4’s 40-byte limit on options
Currently defined extension headers: Hop-by-hop,
Routing, Fragment, Authentication, Privacy, End-to-end.
Order of extension headers in a packet is defined.
Headers are aligned on 8-byte boundaries.
Apr 2005
IIT Kanpur
16
Address Types
Unicast
Multicast
Anycast
Apr 2005
Address for a single interface.
Identifier for a set of interfaces.
Packet is sent to all these interfaces.
Identifier for a set of interfaces.
Packet is sent to the nearest one.
IIT Kanpur
17
Text Representation of Addresses

HEX in blocks of 16 bits
BC84 : 25C2 : 0000 : 0000 : 0000 : 55AB : 5521 : 0018

leading zero suppression
BC84 : 25C2 : 0 : 0 :55AB : 5521 : 18

Compressed format removes strings of 0s
BC84 : 25C2 :: 55AB : 5521 : 18
:: can appear only once in an address.
can also be used to compress leading or trailing 0s

Mixed Notation (X:X:X:X:X:X:d.d.d.d)
e.g., ::144.16.162.21
Apr 2005
IIT Kanpur
18
IPv6 Addresses





128-bit addresses
Multiple addresses can be assigned to an interface
Provider-based hierarchy to be used in the beginning
Addresses should have 64-bit interface IDs in EUI-64
format
Following special addresses are defined :
–
–
–
–
Apr 2005
IPv4-mapped
IPv4-compatible
link-local
site-local
IIT Kanpur
19
Unicast Addresses Examples

Global Aggregate Address
3
13
FP TLA
32
NLA
Public Topology

1111111010
54 bits
0
64 bits
Interface ID
Site-local address
10 bits
1111111011
Apr 2005
Site
Topology
64 bits
Interface ID
Interface Identifier
Link local address
10 bits

16
SLA
38 bits
0
16 bits
subnet ID
IIT Kanpur
64 bits
Interface ID
20
Multicast Address
8 bits
4
11111111 flags scope
Flags
4
000T
T= 0
T= 1
112 bits
Group ID
3 bits reserved
permanent
transient
Scope
2
link-local
5
site-local
8
org-local
E
global
Permanent groups are formed independent of scope.
Apr 2005
IIT Kanpur
21
IPv6 Routing
Hierarchical addresses are to be used.
 Initially only provider-based hierarchy will be used.
 Longest prefix match routing to be used.
(Same as IPv4 routing under CIDR.)
 OSPF, RIP, IDRP, ISIS, etc., will continue as is
(except 128-bit addresses).
 Easy renumbering should be possible.
 Provider selection possible with anycast groups.

Apr 2005
IIT Kanpur
22
QoS Capabilities


Protocol aids QoS support, not provide it.
Flow labels
–
–
–
–
–

To identify packets needing same quality-of-service
20-bit label decided by source
Flow classifier: Flow label + Source/Destination addresses
Zero if no special requirement
Uniformly distributed between 1 and FFFFFF
Traffic class
– 8-bit value
– Routers allowed to modify this field
Apr 2005
IIT Kanpur
23
IPv6: Security Issues

Provision for
– Authentication header
 Guarantees authenticity and integrity of data
– Encryption header
 Ensures confidentiality and privacy

Encryption modes:
– Transport mode
– Tunnel mode


Apr 2005
Independent of key management algorithm.
Security implementation is mandatory
requirement in IPv6.
IIT Kanpur
24
Mobility Support in IPv6





Mobile computers are becoming commonplace.
Mobile IPv6 allows a node to move from one link to
another without changing the address.
Movement can be heterogeneous, i.e., node can move
from an Ethernet link to a cellular packet network.
Mobility support in IPv6 is more efficient than mobility
support in IPv4.
There are also proposals for supporting micro-mobility.
Apr 2005
IIT Kanpur
25
Neighbour Discovery



Router Discovery - determines set of routers on the link.
Prefix Discovery - set of on-link address prefixes.
Parameter Discovery - to learn link parameters such as
link MTU, or internet parameters like hop limit, etc.

Address Auto-configuration - address prefixes that can
be used for automatically configuring interface address.



Address resolution - IP to link-layer address mapping.
Duplicate Address Detection.
Route Redirect - inform of a better first hop node to
reach a particular destination.
Apr 2005
IIT Kanpur
26
Neighbour Discovery Operation

Based on ICMPv6 messages
–
–
–
–
–

Router Solicitation (RS)
Router Advertisement (RA)
Neighbour Solicitation (NS)
Neighbour Advertisement (NA)
Redirect
Router Solicitation
– sent when an interface becomes enabled, hosts
request routers to send RA immediately.
Apr 2005
IIT Kanpur
27
Neighbour Discovery Operation (contd..)

Router advertisement
– Sent by routers periodically or in response to RS.
– Hosts build a set of default routers based on this
information.
– Provides information for address autoconfiguration, set of on-link prefixes etc.
– Supplies internet/subnet parameters, like MTU,
and hop limit.
– Includes router’s link-layer address.
Apr 2005
IIT Kanpur
28
Neighbour Discovery Operation (contd..)

Neighbour Solicitation
– To request link-layer address of neighbour
– Also used for Duplicate Address Detection

Neighbour Advertisement
– Sent in response to NS
– May be sent without solicitation to announce change
in link-layer address

Apr 2005
Redirect - used to inform hosts of a better first hop
for a destination.
IIT Kanpur
29
Additional Features
Anycast Addresses
 Multiple nodes on link may have this address
 All those nodes will respond to an NS message.
 Host will get multiple NA messages, but should
accept only one.
 The messages should be tagged as non-override.
Proxy advertisements
 Router may send NA on behalf of others.
 Useful for mobile nodes who have moved.
Apr 2005
IIT Kanpur
30
Address Auto-configuration
The problem
System bootstrap (“plug and play”)
 Address renumbering

Addressing Possibilities
Manual
Address configured by hand
Autonomous
Host creates address with no external
interaction (e.g., link local)
Semi-autonomous
Host creates address by combining a priori
information and some external information.
Stateless Server
Host queries a server, and gets an address.
Server does not maintain a state.
Stateful Server
Host queries a server, and gets an address.
Server maintains a state.
Apr 2005
IIT Kanpur
31
Auto-configuration in IPv6
Link-local prefix concatenated with 64-bit MAC address.
(Autonomous mode)
 Prefix advertised by router concatenated with 64-bit MAC
address. (Semi-autonomous mode.)
 DHCPng (for server modes)
– Can provide a permanent address (stateless mode)

– Provide an address from a group of addresses, and keep track
of this allocation (stateful mode)
– Can provide additional network specific information.
– Can register nodes in DNS.
Apr 2005
IIT Kanpur
32
Address Renumbering

To migrate to a new address
– change of provider
– change in network architecture

Methods
– router adds a new prefix in RA, and informs that the old
prefix is no longer valid.
– When DHCP lease runs out, assign a new address to node.
– DHCPng can ask nodes to release their addresses.


Requires DNS update. DHCPng can update DNS for clients.
Existing conversations may continue if the old address
continues to be valid for some time.
Apr 2005
IIT Kanpur
33
Upper Layer Issues

Minor changes in TCP
– Maximum segment size should be based on Path MTU.
– The packet size computation should take into account larger
size of IP header(s).
– Pseudo-header for checksum is different.



UDP checksum computation is now mandatory.
Most application protocol specifications are
independent of TCP/IP - hence no change.
FTP protocol exchanges IPv4 addresses - hence needs
to be changed.
Apr 2005
IIT Kanpur
34

The pseudo-header is changed in checksum
computation:
– Address are 128 bits.
– Payload length is 32 bits.
– Payload length is not copied from IPv6 header.
(Extension headers should not be counted.)
– Next header field of last extension header is used in place
of protocol.

UDP packets must also have checksum.
(Since no IP checksum now.)
Apr 2005
IIT Kanpur
35
Changes in Other Protocols

ICMPv6
– Rate limiting feature added
 Timer based
 Bandwidth based
– IGMP, ARP merged
– Larger part of offending packet is included

DNS
– AAAA type for IPv6 addresses
– A6 type: recursive definition of IP address
– Queries that do additional section processing are redefined
to do processing for both ‘A’ and ‘AAAA’ type records
Apr 2005
IIT Kanpur
36
Socket API
“Sockets” interface – the de facto standard API for TCP/IP
Applications.
 Need to change Socket API in order to reflect the increased
address length in IPv6.
 Also need to make new features like flow label, visible to
applications.
 A few new library routines
 Complete source and binary compatibility with original API.
 One can have some sockets using IPv4 and others using
IPv6.

Apr 2005
IIT Kanpur
37
Transition to IPv6: Design Goal
No “flag”day.
 Incremental upgrade and deployment.
 Minimum upgrade dependencies.
 Interoperability of IPv4 and IPv6 nodes.
 Let sites transition at their own pace.
 Basic migration tools

– Dual stack and tunneling
– Translation
Apr 2005
IIT Kanpur
38
Transition Mechanisms: Dual Stack
New nodes support both IPv4 and IPv6.
 Upgrading from IPv4 to v4/v6 does not break anything.
 Same transport layer and application above both.
 Provides complete interoperability with IPv4 nodes.

Apr 2005
IIT Kanpur
39
Transition Mechanism: Tunnels


Tunnel IPv6 packets across IPv4 topology.
Configured tunnels:
– Explicitly configured tunnel endpoints.
– Router to router, host to router.

Automatic tunnels:
– Automatic address resolution using embedded IPv4
address (like IPv4-compatible address).
– Host to host, router to host
Apr 2005
IIT Kanpur
40
Transition mechanism: Translation


This will allow communication between IPv6 only
hosts and IPv4 only hosts.
A typical translator consists of two components:
– translation between IPv4 and IPv6 packets.
– Address mapping between IPv4 and IPv6

For translation, three technologies are available:
– header conversion
– transport relay
– application proxy
Apr 2005
IIT Kanpur
41
NAT-PT





Apr 2005
Combination of Network Address Translation
(NAT) and Protocol Translation (PT)
Meant for communication between IPv6-only and
IPv4-only nodes.
No change is needed on the IPv6-only nodes.
But translation is not stateless.
Hence, single point of failure.
IIT Kanpur
42
NAPT-PT



Network Address Port Translation + Protocol Translation
In addition to changing IP address, changes the port
number also in the transport layer header.
It will allow IPv6 nodes to communicate with IPv4 nodes
transparently using a single IPv4 address.
Apr 2005
IIT Kanpur
43
Stateless IP-ICMP Translation (SIIT)





SIIT also translates between IPv4 and IPv6 headers.
Stateless: Translator does not keep address mapping.
There has to be a translator on every path, not
necessarily on all physical links.
Uses IPv4-translatable addresses.
Assumes that there is an IPv4 address pool of addresses
for the subnet.
Apr 2005
IIT Kanpur
44
Issues in Translation
PMTU discovery is optional on IPv4 network.
 Fragmentation is difficult to handle.
 Security Associations may not be transparent.
 Options may not be translatable.
 UDP checksum is optional over IPv4.
 Some ICMP messages are different.
 Connections can only start from IPv6 node.

Apr 2005
IIT Kanpur
45
Transition Plan for Internet



Maintain complete V4 routing till addresses last.
Upgrade V4 routers to dual stack.
Incrementally build up V6 backbone routing system.
– Use v6-over-v4 tunnels to construct 6bone.
– Grow like Mbone (multicast backbone).

De-activate tunnels as soon as underlying path
upgraded to V6.
Apr 2005
IIT Kanpur
46
Transition Options for User Sites

Incrementally upgrade V4 hosts to dual V4/V6
– Use IPv4-compatible addresses with existing IPv4
address assignments
– Host-to-host automatic tunneling over IPv4

Upgrade routers to IPv6.
– Hosts may require native IPv6 addresses
– DNS upgrade is needed before hosts get IPv6
addresses
Connect IPv6 router to an IPv6-enabled ISP.
 Install translators like NAT-PT or SIIT.

Apr 2005
IIT Kanpur
47
Thank You
Apr 2005
IIT Kanpur
48