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
 Transition Plans

Apr 2005 IIT Kanpur 2

 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 3

 IP Datagram Header
0 4 8 16 19 31
VERS HLEN TOS TOTAL LENGTH

IDENTIFICATION FLAG FRAGMENT OFFSET

TTL PROTOCOL CHECKSUM

SOURCE ADDRESS

DESTINATION ADDRESS

OPTIONS (if any) + PADDING

Apr 2005 IIT Kanpur 4

 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 5

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 6

 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 7

 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 8

 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 9

 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 10

 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 11

 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 12

 IPv6 Header Format

0 4 12 16 24 31
Vers Traffic Class Flow Label

Payload Length Next Header Hop Limit

Source Address

Destination Address

Apr 2005 IIT Kanpur 13

 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 14

 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 15

 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 16

 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 17

 Address Types

Unicast Address for a single interface.

Multicast Identifier for a set of interfaces.
Packet is sent to all these interfaces.
Anycast Identifier for a set of interfaces.
Packet is sent to the nearest one.

Apr 2005 IIT Kanpur 18

 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 19

 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 :
– IPv4-mapped
– IPv4-compatible
– link-local
– site-local

Apr 2005 IIT Kanpur 20

 Unicast Addresses Examples
 Global Aggregate Address
3 13 32 16 64 bits
FP TLA NLA SLA Interface ID
Public Topology Site Interface Identifier
Topology
 Link local address
10 bits 54 bits 64 bits
1111111010 0 Interface ID
 Site-local address

10 bits 38 bits 16 bits 64 bits

1111111011 0 subnet ID Interface ID

Apr 2005 IIT Kanpur 21

 Multicast Address

8 bits 4 4 112 bits

11111111 flags scope Group ID

Flags 000T 3 bits reserved

T= 0 permanent
T= 1 transient

Scope 2 link-local
5 site-local
8 org-local
E global
Permanent groups are formed independent of scope.

Apr 2005 IIT Kanpur 22

 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 23

 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 24

 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
 Independent of key management algorithm.
 Security implementation is mandatory
requirement in IPv6.

Apr 2005 IIT Kanpur 25

 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 26

 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 27

 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 28

 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 auto-
configuration, 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 29

 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
 Redirect - used to inform hosts of a better first hop
for a destination.

Apr 2005 IIT Kanpur 30

 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 31

 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 32

 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 33

 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 34

 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 35

  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 36

 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 37

 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 38

 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 39

 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 40

 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 41

 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 42

 NAT-PT

 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.

Apr 2005 IIT Kanpur 43

 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 44

 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 45

 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 46

 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 47

 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 48

 Thank You

Apr 2005 IIT Kanpur 49