IPv6 Tutorial
Gianluca Reali
1
IPv6 - Important changes
• Expanded Address Space
– Address length quadrupled to 16 bytes
• Header Format Simplification
– Fixed length, optional headers are daisy-chained
– IPv6 header is twice as long (40 bytes) as IPv4 header without options (20
bytes)
• No checksumming at the IP network layer
• No hop-by-hop segmentation
– Path MTU discovery
•Authentication and Privacy Capabilities
– IPsec is mandated
• No more broadcast
2
IPv4- Datagram
0
15 16
Version (4)
IHL (4)
31
Type of Service (8)
Identifier (16)
Total Length (16)
Flag(3)
Fragment Offset (13)
•Version = 4
• IHL - Internet Header Length = 5 with
no header options
[min = 160 bits] [max = 512 bits]
Time To Live (8)
Protocol (8)
Header Checksum (16)
• Type of service , desired quality
service
Source Address (32)
Destination Address (32)
Options & Padding (multiple of 32)
Data
.
•Identification, Flags, Fragmentation Offset- use to segmentation and
reassembly packet
Prec.
D
0 1 2 3
T R 0 0
4 5 6 7
0- 2 Precedence
3 Normal delay low delay
4 Normal throughput High throughput
5 Normal Reliability High reliability
6- 7 Reserved
•Option and Padding - additional info to
control functions such as routing and
security
Bit 0 = Reserved; must be 0
Bit 1 = DF ( 0 = May fragment; 1 = do not fragment )
Bit 2 = MF (0 = last fragment; 1 = more fragments )
3
Issue on header format
vers
hlen
TOS
identification
TTL
protocol
total length
flag
frag offset
header checksum
source address
destination address
options and padding
• Checksum in header format will calculate only the header
checksum. Computation will be done if there are changes
in header value. TTL value is decrement at every hop.
Therefore, computation will be done at every router hop.
• Options and Padding Field will be checked at every router
hop and this use up router processing time which will
degrade router performance.
4
Address space
• IPv4 with only 32 bits gave approximately 4.3 x109
•
•
•
More connected devices
More management costs
More demanding applications
- Communications appliances (e.g. phone, pager)
- Information appliances(e.g. electronic books)
- Entertainment appliances (e.g. set-top boxes)
LARGE ADDRESS SPACE NEEDED
Facts : With current world populations 2 persons need to
share an IP address
5
Limitation to IPv4 addressing
• Decision to stick with 32-bit address space meant that
there were only 232 (4,294,967,296) IPv4 addresses
available
• Classful A, B, and C octet boundaries are easy to
understand but inefficient to deploy in the real world. A
/24 is too small for an average organization, while a /16 is
too big!
4
IP
Internet gowth
6
Fragmentation flag
vers
hlen
TOS
identification
TTL
protocol
total length
flag
frag offset
header checksum
source address
destination address
• Identification Number
16 bits integer value used to identify all fragments. This id
sequence number!
• Flags - 3 bits control fragmentation
options and padding
is not a
0=may fragment
1=don’t fragment
R
reserved, must be 0
DF
MF
0=last fragment
1=more fragment
• Fragment offset - indicate the distance of fragment data
from the start of the original datagram, measure in 8 octets unit
7
Problems in fragmentation
• The end node has no way to know how many fragments
there be.
• Every node will travel independently.If any fragment lost,
all datagram must be discarded
• If any fragment fails to arrive (timer) all datagram must be
discarded
• IP will make no attempt to recover these situations
(connectionless). Only give ICMP error e.g “Packet too big”
• Security problems!
8
Routing problems
• Large Backbone Routing Table
backbone routing table explosion ~ 90K routes . Problem
with legacy IPv4
• Routing Performance
At every hop router will need to check and verify header
checksum.This will increase processing time and degrade
routing performance.
Fragmentation of packets are also done by router. Might
need to be fragmented several times. This will also effect
routing performance.
Hierarchical addressing scheme should be adopted and
simplified header field can ease router burden.
9
IP layer security
• Security at Network Layer.
• Confidentiality, Integrity, and Authentication are key
services used to protect against these threats
• If data is encrypted while in transit, it is impossible for a
perpetrator to observe or modify.
• Security in IPv4 is not mandated. We have to run IPSec on
top of IP.
Strong Network-Layer authentication, identity spoofing
and denial-of service can be prevented
10
Host auto-configuration
Stateful Server Mode
Via DHCP
DHCP
Server
DHCP request
host
DHCP respond
Stateless Server mode will be a better solution and can
save cost
11
Quality of Service
• Quality of Service in IPv4 is using best effort delivery
services, for data to arrive its destination as soon as
possible.
• No reservation for bandwidth. This is adequate for
traditional applications such as Telnet and FTP. But
nowadays, multimedia applications need real-time and
sensitive data transfer to the network. Therefore, better
QOS is needed.
An improved Quality of service need to be implemented.
12
What are IPv6 advantages?
•
•
•
•
•
scalable IP address with streamlined IP header
optimized routing table size (<10K routes)
better real time support
self-configuration of workstations
security features
Note:
IPv6 was designed to re-build and re-engineer IPv4; thus
still inherit some IPv4’s characteristics but rejects its flaws
13
Header comparison
0
15
vers
20
bytes
hlen
TOS
identification
TTL
16
31
total length
flags
protocol
frag offset
header checksum
Removed (6)
•
•
•
ID, flags, frag offset
TOS, hlen
header checksum
source address
destination address
Changed (3)
options and padding
•
•
•
IPv4
vers
traffic class
payload length
40
bytes
flow label
next header
source address
destination address
hop limit
total length=> payload
protocol=>next header
TTL=>hop limit
Added (2)
•
•
traffic class
flow label
Expanded
•
address 32 to 128 bits
IPv6
14
Major improvement
1- No Options. Options field is replaced with extension header. The
removal of the options results in a fixed length, 40 byte IP header.
2- No header checksum. Transport and data link layer have already
performed checksumming.The removal of this feature leads to fast IP
packet’s processing.
3- No segmentation procedure by routers. With path MTU discovery in
IPv6, only source host performs fragmentation process. Removal of
this procedure will speed up IP forwarding in routers.
4- Eliminated IPv4’s 40-octet limit on options in IPv6, limit is total packet
size, or Path MTU in some cases.
15
Packet size issues
IPv6 requires that every link in the internet have an MTU of 1280 octets or greater.
On any link that cannot convey a 1280-octet packet in one piece, link-specific
fragmentation and reassembly must be provided at a layer below IPv6.
Links that have a configurable MTU (for example, PPP links) must be configured to
have an MTU of at least 1280 octets; it is recommended that they be configured with
an MTU of 1500 octets or greater, to accommodate possible encapsulations (i.e.,
tunneling) without incurring IPv6-layer fragmentation.
From each link to which a node is directly attached, the node must be able to accept
packets as large as that link's MTU.
16
Fragmentation
• IPv6 fragmentation & reassembly is an end-to-end function
• Routers do not fragment packets BUT only send the ICMP
“message too big”(with the new MTU size) using the Path
MTU Discovery feature
• Advantage:
better router performance; that is intermediate routers
don’t have to check for the fragmentation fields
(identification + flags + fragment offset fields) every
time the packets pass through them
17
Path MTU discovery
ICMP “packet too big”
Destination
Source
FDDI
MTU=4500
A
FDDI
MTU=4500
Ethernet
MTU=1500
FDDI
MTU=4500
B
For packets bigger than 1280 bytes, path MTU discovery is expected:
• start by assuming MTU of the first-hop link
• if a packet reaches a link which couldn’t fit, an ICMP “packet too big”
is generated and sent back to the source
• then the source will fragmentize the packet into smaller chunks
(following this new MTU size) and start this process all over again
18
IPv6 packet structure
IPv6
Header
header
Extension
Headers
Higher-level protocol header
+ application content
payload
IPv6 packet
Definitions:
IP header provides addressing and control
IP payload carries information and error/control protocols
• Extension headers(optional): In IPv6, optional internet-layer information
is encoded in separate headers that may be placed between the IPv6 header and the
upper- layer header in a packet. There are a small number of such extension headers,
each identified by a distinct Next Header value (RFC 2460).
• Higher-level protocol header:
ICMPv6, UDP & TCP
19
Extension headers
IPv6 Header
Extension Headers
Higher-level protocol header
+ application content
IPv6 packet
IPv6 header
next header=TCP
TCP header + data
IP Payload
IP header
IPv6 header
Routing header
IP header
Extension header
next header=routing
next header=TCP
TCP header + data
IP Payload
IPv6 header
next header=routing
IP header
Routing header
next header=fragment
Fragment header
next header=TCP
fragment of
TCP header + data
Extension headers
IP Payload
Each extension header is an integer multiple of 8 octets long, in order to retain 8-octet
alignment for subsequent headers.
A full implementation of IPv6 includes implementation of the following extension
headers: Hop-by-Hop, Options Routing, Fragment Destination, Options, Authentication
Encapsulating Security Payload
20
Extension headers
• Processed only by node identified in IPv6 Destination Address field =>
much lower overhead than IPv4 options
exception: Hop-by-Hop Options header, which carries information that must
be examined and processed by every node along a packet's delivery path, including the
source and destination nodes (value zero in the Next Header field).
Currently defined Headers should appear in the following order:
–IPv6 header
–Hop-by-Hop Options header
–Destination Options header (for options to be processed by the first
destination that appears in the IPv6 Destination Address field plus subsequent
destinations listed in the Routing header)
–Routing header
–Fragment header
–Authentication header
–Encapsulating Security Payload header
–Destination Options header (for options to be processed only by the final
destination of the packet.)
–upper-layer header
21
Hop-by-Hop Options Header
The Hop-by-Hop Options header is used to carry optional information that must be
examined by every node along a packet's delivery path.
Next Header
Hdr Ext Len
Options
Next Header: 8-bit selector. Identifies the type of header immediately following the Hopby-Hop Options header. Uses the same values as the IPv4 Protocol field [RFC-1700 et
seq.].
Hdr Ext Len: 8-bit unsigned integer. Length of the Hop-by- Hop Options header in 8octet units, not including the first 8 octets.
Options: variable-length field, of length such that the complete Hop-by-Hop Options
header is an integer multiple of 8 octets long. Contains one or more TLV-encoded
options.
22
Options
the Hop-by-Hop Options header and the Destination Options header -carry a variable number of type-length-value (TLV) encoded
"options", of the following format:
Option Type
Opt Data Len
Option Data
Option Type: 8-bit identifier of the type of option.
Opt Data Len: 8-bit unsigned integer. Length of the Option Data field
of this option, in octets.
Option Data: Variable-length field. Option-Type-specific data.
23
Options
The Option Type identifiers are internally encoded such that their
highest-order two bits specify the action that must be taken if the
processing IPv6 node does not recognize the Option Type:
- 00 - skip over this option and continue processing the header.
- 01 - discard the packet.
- 10 - discard the packet and, regardless of whether or not the packet's
Destination Address was a multicast address, send an ICMP Parameter
Problem, Code 2, message to the packet's Source Address, pointing to the
unrecognized Option Type.
- 11 - discard the packet and, only if the packet's Destination Address was not
a multicast address, send an ICMP Parameter Problem, Code 2, message to
the packet's Source Address, pointing to the unrecognized Option Type.
The third-highest-order bit of the Option Type specifies whether or not
the Option Data of that option can change en-route to the packet's final
destination.
0 - Option Data does not change en-route
1 - Option Data may change en-route
24
Options
The 8-bit Option Type field contains the value 194 to indicate the
Jumbo Payload option.
A “jumbogram” is an IPv6 packet containing a payload larger than 65,535
octets. The regular IPv6 header has a 16-bit Payload Length field and,
therefore, supports payloads up to 65,535 octets long. However, the Jumbo
Payload option uses an IPv6 hop-by-hop option, which carries a 32-bit length
field, in order to allow transmission of IPv6 packets with payloads between
65,536 and 4,294,967,295 octets (232-1) in length.
In order for a network to support jumbograms, all the nodes in the network
should implement Jumbo Payload option. Furthermore, the UDP and TCP
protocols in those nodes also have to be enhanced.
The payload length field of the IPv6 header must be set to 0 in every packet
that carries the Jumbo Payload Option. The Jumbo Payload Option is not
consistent with the Fragment header, therefore they cannot be present in the
25
Routing Header
The Routing header is used by an IPv6 source to list one or more intermediate nodes to
be "visited" on the way to a packet's destination. The Routing header is identified by a
Next Header value of 43 in the immediately preceding header.
Next Header
Hdr Ext Len Routing Type Segments Left
Type-specific data
Next Header: 8-bit selector. Identifies the type of header immediately following the
Routing header. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].
Hdr Ext Len: 8-bit unsigned integer. Length of the Routing header in 8-octet units, not
including the first 8 octets.
Routing Type: 8-bit identifier of a particular Routing header variant.
Segments Left: 8-bit unsigned integer. Number of route segments remaining, i.e.,
number of explicitly listed intermediate nodes still to be visited before reaching the final
destination.
Type-specific: data Variable-length field, of format determined by the Routing Type, and
26
of length such that the complete Routing header is an integer multiple of 8 octets long.
Fragment Header
The Fragment header is used by an IPv6 source to send a packet larger than would fit in
the path MTU to its destination. The Fragment header is identified by a Next Header
value of 44 in the immediately preceding header, and has the following format:
Next Header
Reserved
Fragment Offset
Res
M
Identification
Next Header 8-bit selector. Identifies the initial header type of the Fragmentable Part of
the original packet. Uses the same values as the IPv4 Protocol field [RFC-1700 et seq.].
Reserved: 8-bit reserved field. Initialized to zero for transmission; ignored on reception.
Fragment Offset: 13-bit unsigned integer. The offset, in 8-octet units, of the data
following this header, relative to the start of the Fragmentable Part of the original packet.
Res: 2-bit reserved field. Initialized to zero for transmission; ignored on reception.
M flag 1 = more fragments; 0 = last fragment.
Identification 32 bits. Identification of fragmented original packet, which must be different
than that of any other fragmented packet sent recently.
27
Fragmentation rivisited
The initial, large, unfragmented packet is referred to as the "original packet", and it is
considered to consist of two parts, as illustrated:
Unfragmentable Part
Fragmentable Part
The Unfragmentable Part consists of the IPv6 header plus any extension headers that
must be processed by nodes en-route to the destination, that is, all headers up to and
including the Routing header if present, else the Hop-by-Hop Options header if present,
else no extension headers.
The Fragmentable Part consists of the rest of the packet, that is, any extension headers
that need be processed only by the final destination node(s), plus the upper-layer
header and data.
28
Fragmentation rivisited
The Fragmentable Part of the original packet is divided into fragments, each, except
possibly the last ("rightmost") one, being an integer multiple of 8 octets long. The
fragments are transmitted in separate "fragment packets" as illustrated:
Unfragmentable Part
First
fragment
Unfragmentable Part
Fragment
Header
First
fragment
Fragment
Header
Last
fragment
…
Last
fragment
…
Unfragmentable Part
The last header of the Unfragmentable Part changed to 44.
29
Destination Options Header
The Destination Options header is used to carry optional information that need be
examined only by a packet's destination node(s). The Destination Options header is
identified by a Next Header value of 60 in the immediately preceding header, and has
the following format:
Next Header
Hdr Ext Len
Options
Next Header: 8-bit selector. Identifies the type of header immediately following the
Destination Options header. Uses the same values as the IPv4 Protocol field [RFC-1700
et seq.].
Hdr Ext Len: 8-bit unsigned integer. Length of the Destination Options header in 8-octet
units, not including the first 8 octets.
Options: Variable-length field, of length such that the complete Destination Options
header is an integer multiple of 8 octets long. Contains one or more TLV-encoded
options.
30
Security Issues
Use of AH and ESP headers
Two operative modes can be selected:
Transport mode
In transport mode, only the payload of the IP packet is usually encrypted and/or
authenticated. The routing is intact, since the IP header is neither modified nor
encrypted; however, when the authentication header is used, the IP addresses cannot
be translated, as this will invalidate the hash value. The transport and application layers
are always secured by hash, so they cannot be modified in any way (for example by
translating the port numbers). Transport mode is used for host-to-host communications.
Tunnel mode
In tunnel mode, the entire IP packet is encrypted and/or authenticated. It is then
encapsulated into a new IP packet with a new IP header. Tunnel mode is used to create
virtual private networks for network-to-network communications (e.g. between routers to
link sites), host-to-network communications (e.g. remote user access), and host-to-host
communications (e.g. private chat).
31
Authentication Header
Next Header (8 bits) : it indicates the protected upper-layer protocol. The value is taken from the list of IP
protocol numbers.
Hdr Ext Len (8 bits): length of the Authentication Header in 4-octet units, minus 2 (a value of 0 means 8
octets, 1 means 12 octets, etcetera). The header length must be a multiple of 8 octets if carried in an IPv6
packet. This restriction does not apply to an Authentication Header carried in an IPv4 packet.
Reserved (16 bits): reserved for future use (all zeroes if not used).
Security Parameters Index (32 bits): Arbitrary value which is used (together with the source IP address) to
identify the security association of the sending party.
Sequence Number (32 bits): A monotonic strictly increasing sequence number (incremented by 1 for every
packet sent), used also to prevent replay attacks.
Integrity Check Value (multiple of 32 bits): variable length check value. It may contain padding to align the
field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.
32
AH Modes
Transport Mode
Tunnel Mode
33
Encapsulating Security Payload (ESP)
Security Parameters Index (32 bits) : arbitrary value which is used (together with the source
IP address) to identify the security association of the sending party.
Sequence Number (32 bits) : a monotonically increasing sequence number (incremented by
1 for every packet sent) used also to protect against replay attacks.
Payload data (variable): the protected contents of the original IP packet, including any data
used to protect the contents (e.g. an Initialization Vector for the cryptographic algorithm).
The type of content that was protected is indicated by the Next Header field.
34
Encapsulating Security Payload (ESP)
Padding (0-255 octets): padding for encryption, to extend the payload data to a size that fits
the encryption's cypher block size, and to align the next field.
Pad Length (8 bits): size of the padding in octets.
Next Header (8 bits): type of the next header. The value is taken from the list of IP protocol
numbers.
Authentication Data (multiple of 32 bits): variable length check value. It may contain padding
to align the field to an 8-octet boundary for IPv6, or a 4-octet boundary for IPv4.
35
Encryption and Authentication
Algorithms
• Encryption:
–
–
–
–
–
–
Three-key triple DES
RC5
IDEA
Three-key triple IDEA
CAST
Blowfish
• Authentication:
– HMAC-MD5-96
– HMAC-SHA-1-96
36
ESP Modes
Transport Mode
Tunnel Mode
37
Combinations of Security
Associations
38
IPsec modes and combinations
Transport Mode
Tunnel Mode
AH
Authenticates IP payload and
selected portions of IP
header
Authenticates entire inner IP
datagram (header and
payload) and selected
portions of the outer IP
header
ESP
Encrypts IP payload
Encrypts inner IP datagram
ESP with
Authentication
Encrypts IP payload and
authenticates IP payload but
not IP header
Encrypts and authenticates
inner IP datagram
39
Summary of Extension Headers
If the upper-layer header is another IPv6 header (in the case of IPv6 being
tunneled over or encapsulated in IPv6), it may be followed by its own extension
headers, which are separately subject to the same ordering recommendations.
40
No Next Header
The value 59 in the Next Header field of an IPv6 header or any extension header
indicates that there is nothing following that header. i.e. the payload should be empty.
If the Payload Length field of the IPv6 header indicates the presence of octets past the
end of a header whose Next Header field contains 59, those octets must be ignored, and
passed on unchanged if the packet is forwarded (RFC 2460)
41
Flow label
The 20-bit Flow Label field in the IPv6 header may be used by a source to label
sequences of packets for which it requests special handling by the IPv6 routers, such as
non-default quality of service or "real-time" service.
This aspect of IPv6 is subject to change as the requirements for flow support in the
Internet is modified. Hosts or routers that do not support the functions of the Flow Label
field are required to set the field to zero when originating a packet, pass the field on
unchanged when forwarding a packet, and ignore the field when receiving a packet.
42
Traffic Class
The 8-bit Traffic Class field in the IPv6 header is available for use by originating nodes
and/or forwarding routers to identify and distinguish between different classes or
priorities of IPv6 packets.
There are a number of proposals in the use of the IPv4 Type of Service and/or
Precedence bits to provide various forms of "differentiated service" for IP packets, other
than through the use of explicit flow set-up. The Traffic Class field in the IPv6 header is
intended to allow similar functionality to be supported in IPv6.
-The service interface to the IPv6 service within a node must provide a means for an
upper-layer protocol to supply the value of the Traffic Class bits in packets originated by
that upper- layer protocol. The default value must be zero for all 8 bits.
- Nodes that support a specific (experimental or eventual standard) use of some or all of
the Traffic Class bits are permitted to change the value of those bits in packets that they
originate, forward, or receive, as required for that specific use. Nodes should ignore and
leave unchanged any bits of the Traffic Class field for which they do not support a
specific use.
- An upper-layer protocol must not assume that the value of the Traffic Class bits in a
received packet are the same as the value sent by the packet's source.
43
Upper-Layer Protocol Issues
Any transport or other upper-layer protocol that includes the addresses from the IP
header in its checksum computation must be modified for use over IPv6, to include the
128-bit IPv6 addresses instead of 32-bit IPv4 addresses.
The Next Header value in the pseudo-header identifies the upper-layer protocol (e.g., 6
for TCP, or 17 for UDP). It will differ from the Next Header value in the IPv6 header if
there are extension headers between the IPv6 header and the upper- layer header.
Unlike IPv4, when UDP packets are originated by an IPv6 node, the UDP checksum is
not optional. That is, whenever originating a UDP packet, an IPv6 node must compute a
UDP checksum over the packet and the pseudo-header, and, if that computation yields
a result of zero, it must be changed to hex FFFF for placement in the UDP header. IPv6
receivers must discard UDP packets containing a zero checksum, and should log the
error.
When computing the maximum payload size available for upper-layer data, an upperlayer protocol must take into account the larger size of the IPv6 header relative to the
IPv4 header.
44
How Was IPv6 Address Size
Chosen?
• Some wanted fixed-length, 64-bit addresses
– Easily good for 1012 sites, 1015 nodes, at .0001 allocation
efficiency (3 orders of magnitude more than IPv6 requirement)
– Minimizes growth of per-packet header overhead
– Efficient for software processing
• Some wanted variable-length, up to 160 bits
– Compatible with OSI NSAP addressing plans
– Big enough for auto-configuration using IEEE 802 addresses
– Could start with addresses shorter than 64 bits & grow later
• Settled on fixed-length, 128-bit addresses
45
Address space
IPv4 Address space
192.228.134.34
IPv6 Address Space
3FFE:90:AD:23:112:9:56:210
32-bit
128-bit
• 128-bit or 16 bytes
• 2^128=340,282,366,920,938,463,463,374,607,431,768,211,456
• 4.2 x 10^9
IPv4
versus
3.4 x 10^38
addresses
IPv6
Note:
IPv4 allows 1 IP for every 2 persons, but IPv6 offers ~5.6 x
10^28 per person(out of 6 billions population -- 6 x 10^9)
46
Address syntax: preferred
• Hexadecimal values of the eight 16-bit pieces, separated
by colon
X:X:X:X:X:X:X:X
X = 16-bit numbers
e.g. A3BF or FFFE
• Example:
FE78:3450:BED8:9542:FEDC:BA09:1236:763C
3FFE:0:0:0:13:45D:432:1A
47
Address syntax: compressed
• Compressed form=> “::” indicates multiple groups of 16bits of zeros, but only once in an address
4A80:0:0:0:5:800:50CA:290D => 4A80::5:800:50CA:290D
FE80:0:0:0:0:0:0:349
=> FE80::349
4D0A:0:0:89:0:0:236:8009
=> 4D0A::89:0:0:23:8009 or
4D0A:0:0:89::23:8009
0:0:0:0:0:0:0:1
=> ::1
48
Address type
• There are 3 types of addresses:
Unicast : defines a single recipient
A packet sent to a unicast address is delivered to the interface
identified by that address
Anycast : defines a number of recipients
A packet sent to an anycast address is delivered to one of the
interfaces (the working nearest interface)
Multicast : defines a number of recipients
A packet sent to a muticast address is delivered to all of the
interfaces identified by that address
A single interface may be assigned multiple IPv6 addresses of any type
(unicast, anycast, multicast)
49
Address allocation
Prefix is used to identify type of IPv6 address; normally
the first 16 bits (or first 2 bytes)
Address Type
Unspecified
Loopback
Multicast
Binary prefix
00…0 (128 bits)
00...1 (128 bits)
IPv6 notation
::/128
::1/128
11111111
FF00::/8
Link-Local unicast
1111111010
FE80::/10
Global Unicast
(everything else)
Anycast addresses are taken from the unicast address
spaces and are not syntactically distinguishable from unicast
addresses.
50
Global Unicast Addresses (RFC 3587)
128 bit
n bits
global routing prefix
m bits
Subnet-ID
128-n-m bits
Interface-ID
The global routing prefix is a (typically hierarchically- structured) value assigned
to a site (a cluster of subnets/links), the subnet ID is an identifier of a link within
the site, and the interface ID is configurable in different ways
All Global Unicast addresses other than those that start with binary 000 have a
64-bit interface ID field (i.e., n + m = 64). Global Unicast addresses that start
with binary 000 have no such constraint on the size or structure of the interface
ID field. They are special addresses shown in what follows.
51
IPv4-compatible
& IPv4-mapped
Allocation
Binary Prefix
Example
IPv4-compatible
00..(96 bits of zero)
0:0:0:0:0:0:n.n.n.n
IPv4-mapped
00..ffff(80 bits of zero)
0:0:0:0:0:ffff:n.n.n.n
• These addresses have a mixed environment of IPv4 and
IPv6 addresses:
1) IPv4-compatible IPv6 address
technique for hosts and routers to dynamically tunnel IPv6 packets
over IPv4 routing infrastructure – dual stack
0:0:0:0:0:0:192.226.124.45 => ::192.226.124.45
2) IPv4-mapped IPv6 address
Never src/dest of IPv6 packets.
0:0:0:0:0:FFFF:192.226.124.45 => ::FFFF:192.226.124.45
52
IPv4-mapped addresses
IPv6-only applications
TCP / UDP / others (SCTP,
DCCP, etc.)
IPv4-mapped
IPv6 addresses
IPv6 addresses
IPv4
IPv4 packets
IPv6
IPv6 packets
53
Link Local Addresses
128 bit
10 bits
54 bits
1111 1110 10
0
64 bits
Interface-ID
Link-Local addresses are designed to be used for addressing on a single link
for purposes such as automatic address configuration, neighbor discovery, or
when no routers are present.
Routers must not forward any packets with Link-Local source or destination
addresses to other links.
54
Site Local Addresses
128 bit
10 bits
1111 1110 11
54 bits
subnet ID
64 bits
Interface-ID
Site-Local addresses were originally designed to be used for addressing
inside of a site without the need for a global prefix. Site-local addresses
are now deprecated.
The special behavior of this prefix defined in [RFC3513] must no longer
be supported in new implementations (i.e., new implementations must
treat this prefix as Global Unicast).
Existing implementations and deployments may continue to use this
prefix.
55
Unique Local IPv6 Unicast
Addresses (RFC 4193)
IPv6 unicast address format that is globally unique and is intended for
local communications, usually inside of a site. These addresses are not
expected to be routable on the global Internet.
128 bit
7 bits
1
Prefix
L
40bits
Global ID
16 bits
Subnet ID
64 bits
Interface-ID
Prefix: FC00::/7 prefix to identify Local IPv6 unicast addresses.
L Set to 1 if the prefix is locally assigned. Set to 0 may be defined in the future.
Global ID 40-bit global identifier used to create a globally unique prefix.
Subnet ID 16-bit Subnet ID is an identifier of a subnet within the site.
Interface ID 64-bit Interface ID.
56
Unique Local IPv6 Unicast
Addresses
128 bit
7 bits
1
Prefix
L
40bits
Global ID
16 bits
Subnet ID
64 bits
Interface-ID
The allocation of Global IDs is pseudo-random . They MUST NOT be assigned
sequentially or with well-known numbers. This is to ensure that there is not any
relationship between allocations and to help clarify that these prefixes are not
intended to be routed globally.
The use of a pseudo-random algorithm to generate Global IDs in the locally
assigned prefix gives an assurance that any network numbered using such a
prefix is highly unlikely to have that address space clash with any other network
that has another locally assigned prefix allocated to it. This is a particularly
useful property when considering a number of scenarios including networks
that merge, overlapping VPN address space, or hosts mobile between such
57
networks.
Anycast Addresses
An IPv6 anycast address is an address that is assigned to more
than one interface (typically belonging to different nodes), with the
property that a packet sent to an anycast address is routed to the
"nearest" interface having that address, according to the routing
protocols' measure of distance.
Anycast addresses are allocated from the unicast address space,
using any of the defined unicast address formats. Thus, anycast
addresses are syntactically indistinguishable from unicast
addresses. When a unicast address is assigned to more than one
interface, thus turning it into an anycast address, the nodes to
which the address is assigned must be explicitly configured to
know that it is an anycast address.
58
Required Anycast Address
128 bit
n bits
121-n bits
Subnet prefix
111…..1111
7 bits
anycast ID
The Subnet-Router anycast address is predefined. The "subnet prefix" in
an anycast address is the prefix that identifies a specific link. Within each
subnet, the highest 27=128 interface identifier values are reserved for
assignment as subnet anycast addresses.
Packets sent to the Subnet-Router anycast address will be delivered to
one router on the subnet.
All routers are required to support the Subnet-Router anycast addresses
for the subnets to which they have interfaces. The Subnet-Router anycast
address is intended to be used for applications where a node needs to
communicate with any one of the set of routers.
59
Multicast Addresses (RFC 4291)
128 bit
4
8
4
11111111
flags scope
112
Group-ID
Defines address scope
0 Reserved
1 Node-local scope
3 Link-local scope
4 Admin Local Scope
5 Site-local scope
8 Organization local scope
E Global scope
F Reserved
First 3 bits set to 0
Last bit defines address type (T flag):
0 = Permanent (or well-known)
1 = Locally assigned (or transient)
60
Multicast Addresses
Interface-Local scope spans only a single interface on a node and is useful only
for loopback transmission of multicast.
Link-Local multicast scope spans the same topological region as the
corresponding unicast scope.
Admin-Local scope is the smallest scope that must be administratively
configured, i.e., not automatically derived from physical connectivity or other,
non-multicast-related configuration.
Site-Local scope is intended to span a single site.
Organization-Local scope is intended to span multiple sites belonging to a
single organization.
Scopes unassigned are available for administrators to define additional
multicast regions.
61
Multicast Addresses
Reserved Multicast Addresses:
FF00:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0
FF01:0:0:0:0:0:0:0
FF04:0:0:0:0:0:0:0
FF07:0:0:0:0:0:0:0
FF0A:0:0:0:0:0:0:0
FF0D:0:0:0:0:0:0:0
FF02:0:0:0:0:0:0:0
FF05:0:0:0:0:0:0:0
FF08:0:0:0:0:0:0:0
FF0B:0:0:0:0:0:0:0
FF0E:0:0:0:0:0:0:0
The above multicast addresses are reserved and shall never be
assigned to any multicast group.
62
Multicast Addresses
Some well-known multicast addresses are pre-defined. The group IDs
shown are defined for explicit scope values. Use of these group IDs for
any other scope values, with the T flag equal to 0, is not allowed.
All Nodes Addresses:
FF01:0:0:0:0:0:0:1
FF02:0:0:0:0:0:0:1
multicast addresses that identify the group of all
IPv6 nodes, within scope 1 (interface-local) or 2
(link-local).
All Routers Addresses:
FF01:0:0:0:0:0:0:2
FF02:0:0:0:0:0:0:2
FF05:0:0:0:0:0:0:2
multicast addresses that identify the group of all
IPv6 routers, within scope 1 (interface-local), 2
(link-local), or 5 (site-local).
Solicited-Node Address:
FF02:0:0:0:0:1:FF
XX:XXXX
ARP-like
Solicited-Node multicast address are computed
as a function of a node's unicast and anycast
addresses. A Solicited-Node multicast address is
formed by taking the low-order 24 bits of an
address (unicast or anycast) and appending
those bits to the prefix FF02:0:0:0:0:1:FF00::/104
resulting in a multicast address in the range 63
Interface Identifiers
• A host is required to recognize the following addresses as
identifying itself:
–
–
–
–
–
Its Link-Local Address for each interface
Assigned Unicast Addresses
Loopback Address
All-Nodes Multicast Addresses
Solicited-Node Multicast Address for each of its assigned unicast
and anycast addresses
– Multicast Addresses of all other groups to which the host belongs.
64
Interface Identifiers
• Routers are required to recognize:
– The Subnet-Router anycast addresses for the interfaces it is
configured to act as a router on.
– All other Anycast addresses with which the router has been
configured.
– All-Routers Multicast Addresses
– All valid host addresses
– Multicast Addresses of all other groups to which the router
belongs.
65
Hierarchical Addressing &
Aggregation
Customer
no 1
ISP
2001:0410:0001:/48
Customer
no 2
Only
announces
the /32
prefix
2001:0410::/32
IPv6 Internet
2001::/16
2001:0410:0002:/48
–Larger address space enables:
•Aggregation of prefixes announced in the global routing table.
•Efficient and scalable routing.
–But current Multi-Homing schemes break the model
(note: no masks in IPv6!)
66
Address Allocation Policy
IANA allocates addresses to Regional
Internet Registry, or RIR. Currently,
there are four RIR: APNIC (Asia Pacific
Network Information Centre), ARIN for
North America, RIPE NCC (Reseaux IP
Europeans Network Coordination
Centre) mainly for Europe, and LACNIC
(Latin American and Caribbean Internet
Addresses Registry) for South America
and Caribbean regions.
RIR (or National IR - NIR) allocates
address to organizations called LIR
(Local Internet Registry). An LIR is an
organization which is delegated by RIR
or NIR to allocate address to users. LIR
usually is a service provider. An LIR
allocates acquired address to end user
organizations, or other ISP.
67
Address Allocation Policy
Ex: 2001::/16 0010 0000 0000 0001 Global Unicast Assignments [RFC3513]
Each registry gets a /23 prefix from IANA, within the 2001::/16 space
Registry allocates an initial /32 prefix to a new IPv6 ISP
ISP allocates a /48 prefix (out of the /32) to each customer
68
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
69
MAC-to-EUI-64 conversion
example
 MAC Address: 0000:0B0A:2D51
• In binary:
00000000 00000000 00001011 00001010 00101101 01010001
U/L Bit
Company-ID

Individual Node-ID
Insert FFFE between Company-ID and Node-ID
00000000 00000000 00001011 11111111 11111110 00001010 00101101 01010001

Set U/L bit to 1
= FFFE
00000010 00000000 00001011 11111111 11111110 00001010 00101101 01010001
U/L Bit
 Resulting EUI-64 Address: 0200:0BFF:FE0A:2D51
70
Types of Transition to IPv6
Mechanisms
• Dual Stacks
– IPv4/IPv6 coexistence on one device
• Tunnels
– For tunneling IPv6 across IPv4 clouds
– Later, for tunneling IPv4 across IPv6 clouds
• Translators
– IPv6 <-> IPv4
71
Dual Stacks
Network, Transport, and Application layers do not necessarily interact
without further modification or translation
IPv6
Applications
IPv4
Applications
TCP/UDPv6
TCP/UDPv4
IPv6
IPv4
0x86dd
0x0800
Physical/Data Link
72
Tunnel Applications
IPv4
IPv6
IPv6
IPv6
Router to Router
IPv4
IPv6
Host to Host
IPv4
IPv6
IPv6
Host to Router / Router to Host
73
Tunnels to Get Through
IPv6-Ignorant Routers
• encapsulate IPv6 packets inside IPv4 packets
(or MPLS frames)
• can view this as:
– IPv6 using IPv4 as a virtual link-layer, or
– an IPv6 VPN (virtual public network), over the IPv4 Internet
74
Tunnel Types
• Configured or automated tunneling
– Ex: Router to router: raw encapsulation of IPv6 packets using IPv4 protocol
number 41 is recommended for configured tunneling (aka 6in4 tunneling).
– The tunnel endpoints are explicitly configured, either by an administrator
manually or the operating system's configuration mechanisms, or by a tunnel
broker service.
– It is recommended for large, well-administered networks.
• Automatic tunneling, the routing infrastructure automatically
determines the tunnel endpoints.
– 6to4 (RFC 3056), widely deployed protocol 41 encapsulation.
– ISATAP (Intra-Site Automatic Tunnel Addressing Protocol)
• Host to router, router to host
• Maybe host to host
– 6over4 (RFC 2529)
• Host to router, router to host
– Teredo
• For tunneling through IPv4 NAT
– IPv64
• For mixed IPv4/IPv6 environments
75
Configured tunneling
IPv6 host
2001::A:A:B
• Encapsulate IPv6
packet in Ipv4
• IPv6 only
address
……
IPv4 IPv6
R1
2001::B:B:C
4
traffic
flow label
payload len next
dst = 2001::B:B:C
(IPv6 adr)
payload
hl TOS
len
ident
frag off
TTL
hops
src = 2001::A:A:B
(IPv6 adr)
R2
IPv4IPv6
2001::B:B:C
6
IPv6 host
2001::B:B:C
IPv4 network
41
checksum
src = R1
dst = R2
6
traffic
flow label
payload len next
hops
src = 2001::A:A:B
(IPv6 adr)
6
traffic
flow label
payload len next
hops
dst = 2001::B:B:C
(IPv6 adr)
src = 2001::A:A:B
(IPv6 adr)
payload
dst = 2001::B:B:C
(IPv6 adr)
payload
76
IPv6 Tunnel Broker with the Tunnel
Setup Protocol (TSP) (RFC 5572)
A tunnel broker with the Tunnel Setup Protocol (TSP) enables the
establishment of tunnels of various inner protocols, such as IPv6 or IPv4, inside
various outer protocols packets, such as IPv4, IPv6, or UDP over IPv4 for IPv4
NAT traversal.
The control protocol (TSP) is used by the tunnel client to negotiate the tunnel
with the broker.
A mobile node implementing TSP can be connected to both IPv4 and IPv6
networks whether it is on IPv4 only, IPv4 behind a NAT, or on IPv6 only.
A tunnel broker may terminate the tunnels on remote tunnel servers or on itself.
77
IPv6 Tunnel Broker with the Tunnel
Setup Protocol (TSP) (RFC 5572)
TSP is a signaling protocol to set up tunnel parameters between two
tunnel endpoints. TSP is implemented as a tiny client code in the
requesting tunnel endpoint. The other endpoint is the server that will set
up the tunnel service. TSP uses XML basic messaging over TCP or UDP.
TSP negotiates tunnel parameters between the two tunnel endpoints.
Parameters that are always negotiated are:
- Authentication of the users,
- Tunnel encapsulation:
IPv6 over IPv4 tunnels [RFC4213]
IPv4 over IPv6 tunnels [RFC2473]
IPv6 over UDP-IPv4 tunnels for NAT traversal
- IP address assignment for the tunnel endpoints
- DNS registration of the IP endpoint address (AAAA)
78
IPv6 Tunnel Broker with the Tunnel
Setup Protocol (TSP) (RFC 5572)
• Three basic components:
1. TSP Client: Dual-stacked host or router
2. Client Tunnel Endpoint
3. TSP Server (Tunnel Broker)
4. Server Tunnel Endpoint
• A few tunnel brokers:
– Freenet6 [Canada] (www.freenet6.net)
– CERNET/Nokia [China] (www.tb.6test.edu.cn)
– Internet Initiative Japan (www.iij.ad.jp)
– Hurricane Electric [USA] (www.tunnelbroker.com)
– BTexacT [UK] (www.tb.ipv6.btexact.com)
– Many others…
• 1,3, and 4 form the tunnel broker model (RFC 3053), where 3 is
the tunnel broker and 4 is the tunnel server. The tunnel broker
may control one or many tunnel servers.
79
TSP Used on Tunnel Broker Model
1.
2.
3.
TSP
Server
3
4.
5.
6.
4
DNS
Tunnel
Broker
7.
1
2
6
TSP
Client
IPv4
Network
7
AAA Authorization
Configuration request
TB chooses:
•
TS
•
IPv6 addresses
•
Tunnel lifetime
TB registers tunnel IPv6 addresses
Config info sent to TS
Config info sent to client:
•
Tunnel parameters
•
DNS name
Tunnel enabled
5
Tunnel
Server
IPv6
Network
IPv6 Tunnel
80
Automatic tunneling
IPv6 host
::1.2.3.4
• Encapsulate IPv6
packet in Ipv4
……
IPv4IPv6
• rely on IPv4compatible IPv6
address
2.3.4.5
traffic
flow label
payload len next
dst = ::2.3.4.5
(IPv4-compatible IPv6 adr)
2.3.4.5
hl TOS
len
ident
frag off
TTL
hops
src = ::1.2.3.4
(IPv4-compatible IPv6 adr)
payload
IPv4IPv6
2.3.4.5
4
6
IPv4/6 host
2.3.4.5
IPv4 network
prot checksum
src = 1.2.3.4
4
TTL
dst = 2.3.4.5
6
traffic
prot checksum
src = 1.2.3.4
dst = 2.3.4.5
flow label
payload len next
hl TOS
len
ident
frag off
hops
6
traffic
flow label
payload len next
hops
src = ::1.2.3.4
(IPv4-compatible IPv6 adr)
src = ::1.2.3.4
(IPv4-compatible IPv6 adr)
dst = ::2.3.4.5
(IPv4-compatible IPv6 adr)
dst = ::2.3.4.5
(IPv4-compatible IPv6 adr)
payload
payload
81
6to4 (RFC 3056) – WAN tunneling
•
•
•
Designed for site-to-site and site to existing IPv6 network connectivity
Site border router must have at least one globally-unique
IPv4 address
Uses IPv4 embedded address
/16
/48
/64
2002
Public IPv4
address
SubnetID
Interface ID
Example:
Reserved 6to4 prefix:
2002::/16
IPv4 address:
138.14.85.210 = 8a0e:55d2
Resulting 6to4 prefix:
2002:8a0e:55d2::/48
•
•
Router advertises 6to4 prefix to hosts via RAs
Embedded IPv4 address allows discovery of tunnel endpoints
82
6to4
IPv4 address: 138.14.85.210
6to4 prefix: 2002:8a0e:55d2::/48
IPv6
Public Internet
IPv4 address: 65.114.168.91
6to4 prefix: 2002:4172:a85b::/48
6to4
Relay Router
IPv4
Network
IPv6
Site
IPv6
Site
IPv6
6to4 Router
6to4 address:
2002:8a0e:55d2::8a0e:55d2
6to4 Router
6to4 address:
2002:4172:a85b::4172:a85b
83
6over4
• aka “Virtual Ethernet”: transmit IPv6 packets between dual-stack nodes
on top of a multicast-enabled IPv4 network. IPv4 is used as a virtual
data link layer (virtual Ethernet) on which IPv6 can be run.
• Early proposed tunnel solution: 6over4 defines a trivial method for
generating a link-local IPv6 address from an IPv4 address, and a
mechanism to perform Neighbor Discovery on top of IPv4.
84
6over4
• Encapsulates IPv6 packets in IPv4 (protocol type 41)
Starting from fe80::
192.0.2.142, C000028e in hexadecimal notation
link-local IPv6 address: fe80::C000:28e
To facilitate IPv6 multicast communications over an IPv4 multicastenabled infrastructure, RFC 2529 defines the following mapping to
translate an IPv6 multicast address to an IPv4 multicast address:
239.192.[ second to last byte of IPv6 address ].[ last byte of IPv6 address ]
Example:
To perform ICMPv6 Neighbor Discovery, multicast must be used. Any IPv6
multicast packet gets encapsulated in an IPv4 multicast packet with
destination 239.192.x.y, where x and y are the penultimate and last bytes
of the IPv6 multicast address respectively.
85
ISATAP Addresses (RFC 5214)
• ISATAP (Intra-Site Automatic Tunnel Access Protocol) –
Campus tunneling
– It is a transition mechanism which can be used within a
site to connect isolated IPv6/IPv4-dualstack hosts to the
IPv6 internet.
– Within a site usually only one ISATAP router is needed.
The host/router functioning as an ISATAP server should
be dualstack and have a connection to the IPv6 internet
in order for it to become a gateway for all clients in the
ISATAP subnet it serves. An ISATAP client using a
certain server as gateway also needs a valid globalscope IPv6 prefix to build its address with. This prefix
should therefore be advertised by the router which also
needs to have this prefix routed to it from the outside.
86
ISATAP
IPv4/IPv6
Router
IPv6
IPv4
IPv6
6to4
Router
IPv4
ISATAP hosts must be configured with a potential routers
list (PRL). Each of these routers is infrequently probed by
an ICMPv6 Router Discovery message, to determine which
of them are functioning.
87
ISATAP
Global IPv4 address:
Global IPv6 prefix:
Link-local address:
Global IPv6 address:
Private IPv4 address:
Global IPv6 prefix:
Link-local address:
Global IPv6 address:
Example 1 :
65.114.168.91
2001:468:1100:1::/64
fe80::0200:5efe:65.114.168.91
2001:468:1100:1::0200:5efe:65.114…..
Example 2:
172.18.133.14
2001:468:1100:1::/64
fe80::5efe: 172.18.133.14
2001:468:1100:1::5efe:172.18.133.14
88
Teredo (RFC4380)
•
•
aka “Shipworm”
For tunneling IPv6 through one or several NATs
– Other tunneling solutions require global IPv4 address, and so do not work
from behind NAT
– Can be stateless or stateful (using TSP)
•
•
Tunnels over UDP (port 3544) rather than IP protocol #41
Basic components:
– Teredo Client: Dual-stacked node
– Teredo Server: Node with globally routable IPv4 Internet access, provides
IPv6 connectivity to client
– Teredo Relay: Dual-stacked router providing connectivity to client
– Teredo Bubble: IPv6 packet with no payload (NH #59) for creating mapping
in NAT
– Teredo Service Prefix: Prefix originated by TS for creating client IPv6
address
Teredo navalis
89
1.
2.
3.
4.
5.
6.
RS to server
NAT maps inside address/port
to outside address/port
TS notes:
•
source address/port
•
NAT type
RA to client containing:
•
Service prefix
•
origin indication
Client creates IPv6 address from:
•
Server prefix
•
“Obfusticated” origin
indication"mapped IPv4 address"
IPv6 packets
tunneled to relay
Teredo

TSP can be used in place of RS/RA for:


Stateful tunnel
Authentication
IPv4
Network
2
3
Source: 9.0.0.1:4096
Destination: 1.2.3.4:3544
Source: 10.0.0.1:2716
Destination: 1.2.3.4:3544
5
3ffe:831f:102:304::efff:f6ff:fffe
4
Source: 1.2.3.4
Destination: 9.0.0.1:4096
Prefix:3ffe:831f:0102:0304::/64
Origin Indication: 9.0.0.1:4096
1
Client
10.0.0.2
Teredo
Server
IPv4 =1.2.3.4
IPv6 prefix = 3ffe:831f::/32
NAT
IPv6
Network
IPv6 over UDP tunnel
6
Inside Address: 10.0.0.1
Outside Address: 9.0.0.1
Teredo
Relay
4096:9.0.0.1=00010000000000000:00001001.00000000.00000000.00000001 
111011111111111111110110.11111111.11111111.11111110  efff:f6ff:fffe
90
IPv64
• Proposed for highly interconnected IPv4 and IPv6 networks (midVer.
transition)
HL TOS
Datagram Length
4
Datagram-ID
Flag Frag Offset
• IPv64 packets: IPv6 encapsulated in IPv4
TTL
– bit 48 (numbering from 0)
of IPv4 header indicates IPv64 packet
Source IPv4 Address
Destination IPv4 Address
• IPv64 routers:
– Process IPv64 packets as IPv6
– Process IPv4 packets as IPv4
– Process IPv6 packets as IPv6
• IPv4 routers:
Protocol Header Checksum
IP Options
IPv64 bit
1 = IPv64
0 = IPv4
Ver. Traffic
6
class
Payload Length
Flow label
Next
Hdr.
Hop
Limit
Source IPv6 Address
– Process IPv64 packets as IPv4
• IPv6 routers:
Destination IPv6 Address
– Cannot process IPv64 packets
– IPv64-to-IPv4 translation required at IPv64
routers
– Proposed IPv6 Extension Header carries necessary IPv4 information for
re-translating back to IPv64, if necessary
91
Dual-Stack Transition Mechanism (DSTM)
• aka 4over6
– Tunnels IPv4 over IPv6 networks
– Next-Header Number for IPv4 = 4
• Three basic components:
– Tunnel End Point: Border router between IPv6-only network and
IPv4 Internet or intranet
– DSTM Clients: Dual-stacked nodes, create tunnels to Tunnel End
Pont (TEP)
– DSTM Address Server: Allocates IPv4 addresses to clients
• Uses existing protocols
– DSTM Server can communicate with Client or TEP via DHCPv6 or
TSP
• Server can optionally assign port range for IPv4 address
conservation
– Multiple clients have same IPv4 address, different port ranges
92
DSTM
1.
2.
3.
4.
1
Client needs IPv4 connectivity
Client requests tunnel info
Server sends IPv4 tunnel endpoint
addresses
Tunnel set up
jeff.juniper.net =
192.168.1.2
DSTM
Server
2
3
IPv6
Network
3
IPv4
Network
4
IPv4 in IPv6 Tunnel
Client
Tunnel
End-Point
93
Translators
• Network level translators
– Stateless IP/ICMP Translation Algorithm (SIIT)(RFC 6145)
– NAT-PT (RFC 2766) - deprecated
– Bump in the Stack (BIS) (RFC 2767)
• Transport level translators
– Transport Relay Translator (TRT) (RFC 3142)
• Application level translators
– Bump in the API (BIA)(RFC 3338)
– Application Level Gateways (ALG)
94
Stateless IP/ICMP Translation (SIIT)
• Translator replaces headers IPv4 IPv6
• Translates ICMP messages
– Contents of message translated
– ICMP pseudo-header checksum added
• Fragments IPv4 messages to fit IPv6 MTU when
necessary
• Uses IPv4-translated addresses to refer to IPv6-enabled
nodes
– ::ffff:0:0:0/96 + 32-bit IPv4 address
• Uses IPv4-mapped addresses to refer to IPv4-only
nodes
– 0:0:0:0:0:ffff/96 + 32-bit IPv4 address
• Requires IPv6 hosts to acquire an IPv4 address
– SIIT must know these addresses
95
Stateless IP/ICMP Translation (SIIT)
204.127.202.4
IPv4
Network
Source = 216.148.227.68
Dest = 204.127.202.4
IPv6
Network
SIIT
Source = 204.127.202.4
Dest = 216.148.227.68
Source = ::ffff:0:216.148.227.68
Dest = ::ffff:204.127.202.4
Source = ::ffff:204.127.202.4
Dest = ::ffff:0:216.148.227.68
SIIT also changes:
3ffe:3700:1100:1:210:a4ff:fea0:bc97
216.148.227.68
•Traffic Class   TOS
•Payload length
•Protocol Number   NH Number
•TTL   Hop Limit
96
Network Address Translation - Protocol
Translation (NAT-PT)
•
Stateful address translation
– Tracks supported sessions
– Inbound and outbound session packets must traverse the same NAT
•
•
Uses SIIT for protocol translation
Two variations:
– Basic NAT-PT provides translation of IPv6 addresses to a pool of IPv4 addresses
– NAT-PT manipulates IPv6 port numbers so that multiple IPv6 sources can share a
single IPv4 address
•
DNS Application Level Gateway (DNS-ALG) is also specified, but has some
problems
–
–
–
–
–
–
Internal A queries might return AAAA record
Possible problems for internal zone transfers, mixed v4/v6 networks, etc.
Possible problems resolving to external dual-stacked hosts
Assumes DNS traffic traverses NAT-PT box (topology limitation)
No DNS-sec
Vulnerable to DoS attacks by depletion of address pools
97
Network Address Translation - Protocol
Translation (NAT-PT)
IPv4 Pool: 120.130.26/24
IPv6 prefix: 3ffe:3700:1100:2/64
IPv6
Network
IPv4
Network
DNS
v4host.4net.org?
NAT-PT
v4host.4net.org
AAAA 3ffe:3700:1100:2::204.127.202.4
v4host.4net.org
A 204.127.202.4
v4host.4net.org
204.127.202.4
v6host.6net.com
3ffe:3700:1100:1:210:a4ff:fea0:bc97
98
Network Address Translation - Protocol
Translation (NAT-PT)
IPv4 Pool: 120.130.26/24
IPv6 prefix: 3ffe:3700:1100:2/64
IPv6
Network
IPv4
Network
Mapping Table
DNS
Inside
Outside
3ffe:3700:1100:1:210:a4ff:fea0:bc97 120.130.26.10
Source = 3ffe:3700:1100:1:210:a4ff:fea0:bc97
Dest = 3ffe:3700:1100:2::204.127.202.4
Source = 120.130.26.10
Dest = 204.127.202.4
NAT-PT
Source = 204.127.202.4
Dest = 120.130.26.10
Source = 3ffe:3700:1100:2::204.127.202.4
Dest = 3ffe:3700:1100:1:210:a4ff:fea0:bc97
v4host.4net.org
204.127.202.4
v6host.6net.com
3ffe:3700:1100:1:210:a4ff:fea0:bc97
99
Transport Relay Translator (TRT)
• aka TCP/UDP Relay. It enables IPv6-only hosts to
exchange {TCP,UDP} traffic with IPv4-only hosts.
• Based on proxy firewall concept
• No IP packets transit the TRT
• Two connections established:
– Initiator to TRT
– TRT to target node
• Requires “special” DNS to translate IPv4 addresses into
IPv6 and vice versa
– TRT does not translate DNS queries/records
• Only works with TCP and UDP
100
Transport Relay Translator (TRT)
Query to “special” DNS from v6host
for v4host.4net.org returns:
AAAA fec0:0:0:1::204.127.202.4
IPv4
Network

TCP/IPv6 Session
Source = 3ffe:3700:1100:1:210:a4ff:fea0:bc97
Dest = fec0:0:0:1::204.127.202.4
v4host.4net.org
204.127.202.4
TCP/IPv4 Session
Source = 216.148.227.68
Dest = 204.127.202.4
TRT
TCP/IPv4 Session
Source = 204.127.202.4
Dest = 216.148.227.68
“Dummy” IPv6 Prefix =
fec0:0:0:1::/64
IPv4 Address =
216.148.227.68
TCP/IPv6 Session
Source = fec0:0:0:1::204.127.202.4
Dest = 3ffe:3700:1100:1:210:a4ff:fea0:bc97
v6host.6net.com
3ffe:3700:1100:1:210:a4ff:fea0:bc97
IPv6
Network
101
Application Layer Gateways
• Application-specific translator
• Needed when application layer contains IP address
• Similar to ALGs used in firewalls, some NATs
102
ICMPv6
Some important ICMPv6 message types:
1
2
3
4
128
129
Destination unreachable
Packet too big
Time exceeded
Parameter problem
Echo request
Echo reply
103
ICMPv6: Destination Unreachable
32 bits
Type=1
Code
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
packet.
Checksum
Unused
As much of invoking packet
as will fit without the ICMPv6 packet
exceeding the minimum IPv6 MTU
Unused
Code
0 - no route to destination
1 - communication with destination
administratively prohibited
2 - (not assigned)
3 - address unreachable
4 - port unreachable
This field is unused for all code
values. It must be initialized to zero
by the sender and ignored by the
receiver.
104
ICMPv6: Packet too big
32 bits
Type=2
Code
Checksum
MTU
As much of invoking packet
as will fit without the ICMPv6 packet
exceeding the minimum IPv6 MTU
Code
MTU
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
packet.
Set to 0 by the sender and ignored by the receiver
The maximum transmission unit of the next-hop link
105
ICMPv6: Time exceeded
32 bits
Type=3
Code
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
packet.
Checksum
Unused
As much of invoking packet
as will fit without the ICMPv6 packet
exceeding the minimum IPv6 MTU
Unused
Code
0 – Hop limit exceeded in transit
1 – Fragment reassembly time
exceeded
This field is unused for all code
values. It must be initialized to zero
by the sender and ignored by the
receiver.
106
ICMPv6: Parameter problem
32 bits
Type=4
Code
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
packet.
Checksum
Pointer
As much of invoking packet
as will fit without the ICMPv6 packet
exceeding the minimum IPv6 MTU
Pointer
Code
0 - erroneous header field
encountered
1 - unrecognized Next Header type
encountered
2 - unrecognized IPv6 option
encountered
Identifies the octet offset within the
invoking packet where the error was
detected.
The pointer will point beyond the end
of the ICMPv6 packet if the field in
error is beyond what can fit in the
maximum size of an ICMPv6 error
message.
107
ICMPv6: Echo request
32 bits
Type=128
Identifier
Code=0
Checksum
Sequence Number
IPv6 Header
Destination Address:
Any legal IPv6 address.
Data
Code
0
Identifier
An identifier to aid in matching Echo Replies to this Echo Request. May be zero.
Sequence Number A sequence number to aid in matching Echo Replies to this Echo Request. May
be zero.
Data
Zero or more octets of arbitrary data.
108
ICMPv6: Echo reply
32 bits
Type=129
Code=0
Identifier
Checksum
Sequence Number
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
Echo Request packet.
Data
Code
Identifier
Sequence Number
Data
0
The identifier from the invoking Echo Request message.
The sequence number from the invoking Echo Request message
The data from the invoking Echo Request message.
109
Neighbor discovery
Provides functionality for
• Serverless autoconfiguration
• Router discovery
• Prefix discovery
• Address resolution
• Neighbor unreachability detection
• Link MTU discovery
• Next-hop determination
• Duplicate address detection
110
Neighbor discovery
ND makes use of five ICMPv6 packets to provide IPv6
nodes with the information they need before
communicating
133
134
135
136
5
Router solicitation (RS)
Router advertisement (RA)
Neighbor solicitation (NS)
Neighbor advertisement (NA)
Redirect
111
Router solicitation (RS)
 ICMP packet type 133
 Sent by host to speed up learning of link-local routers
 Source address is sending host‘s address or
0:0:0:0:0:0:0:0 (if no address is assigned to the
sending interface)
 Destination address is typically all-routers multicast
address: FF02::2
 May contain sender‘s link layer address (MUST NOT
be included if the Source Address is the unspecified
address. Otherwise, it SHOULD be included on link
layers that have addresses.)
 Reply is a Router Advertisement (RA)
112
Router solicitation (RS) format
32 bits
Type=133
Code=0
Checksum
Reserved (unused, initialized to zero by the sender)
Options....
The only valid option is the Source Link-Layer which MUST be included if
known e.g. the EUI-64 value of the interface else no option field should be
included.
113
Router advertisement (RA)




ICMP packet type 134
Sent by routers periodically or in response to a solicitation to provide
information necessary for a node to configure itself
Source address is link-local address of the sending router
Destination address is either
–
–


unicast address of a node that sent an RS, or
link-scope all-nodes multicast address: FF02::1
Hop-limit MUST be set to 255
Possible options contained in RA:
–
–
–
Source link layer address of the router
MTU
Prefix information about on-link prefixes
114
Router advertisement (RA) format
32 bits
Type=134
Code=0
Cur. Hop Limit M O Reserved
Checksum
Router lifetime
Reachable Time
Retransmit Timer
Options....
Cur Hop Limit 8-bit unsigned integer. The default value that should be placed in
the Hop Count field of the IP header for outgoing IP packets. A
value of zero means unspecified (by this router).
M
1-bit "Managed address configuration" flag. When set, it indicates
that addresses are available via Dynamic Host Configuration
Protocol [DHCPv6].
O
1-bit "Other stateful configuration" flag. When set, it indicates that
other configuration information is available via DHCPv6. Examples
of such information are DNS-related information or information on
115
other servers within the network.
Neighbor discovery:
Router solicitation
E
Default GW-List
A
B
C
D
C
RS
A
B
F
G
RA
116
Neighbor discovery:
Router advertisement
E
Default GW-List
A
D
C
A
B
F
G
RA
117
Neighbor solicitation (NS)
•
•
•
•
•
ICMP packet type 135
Used to provide/obtain link-layer address to/of a neighbor
Used to verify neighbor reachability
IPv6 Source-address is link-local address of soliciting node
IPv6 Destination-address is either
– solicited-node multicast address associated with target IP address
(link layer determination) FF02:0:0:0:0:1:FF XX:XXXX
– Unicast address of the target (reachability verification)
• Hop-limit MUST be set to 255
• Reply is a Neighbor advertisement (NA)
118
Neighbor solicitation (NS) format
32 bits
Type=135
Code=0
Checksum
Reserved
Target address
Options....
Target Address: The IP address of the target of the solicitation. It MUST NOT be
a multicast address.
Possible options: Source link-layer address, which is the link-layer address for the
sender. MUST NOT be included when the source IP address is the
unspecified address. Otherwise, on link layers that have addresses
this option MUST be included in multicast solicitations and
SHOULD be included in unicast solicitations.
119
Neighbor advertisement (NA)
• ICMP packet type 136
• Sent in response to NS or unsolicited to immediately
propagate new information
• Source address is any valid unicast address
assigned to sending node
• Destination address is
– For solicited advertisements
• Source address of the solicitation
• If address of NS is unspecified: all-nodes multicast address
– For unsolicited advertisements
• All-nodes multicast
• Hop-limit MUST be set to 255
120
Neighbor advertisement (NA)
format
32 bits
Type=136
Code=0
Checksum
R S O Reserved
Target address
Options....
R
S
O
Router flag. When set, the R-bit indicates that the sender is a router.
Solicited flag. When set, the S-bit indicates that the advertisement was sent in
response to a Neighbor Solicitation from the Destination address. The S-bit is
used as a reachability confirmation for Neighbor Unreachability Detection. It
MUST NOT be set in multicast advertisements or in unsolicited unicast
advertisements.
Override flag indicates that the information of the message should override an
existing Neighbor chache for which no link layer address exists
121
Redirect
32 bits
Type=137
Code=0
Checksum
Reserved
Target address
Destination address
Options....
122
Redirect
Default GW-List
A
B
C
E
ICMP Redirect to
Router B
D
Sent data to Host 3 using
Default GW "A"
C
A
Path used with Default
Gateway "A"
Redirect traffic
via Router B
B
F
G
Host 3
123
Next-hop discovery
The neighbor cache is the IPv6equivalent of the Address Resolution
Protocol (ARP) cache on an IPv4 host. A host that has a packet to
send must first determine what next hop to use. If a packet was
previously sent to the destination, the next hop might be stored in a
destination cache.
 Check neighbor cache, kept updated from previous
packet transmissios, for existing next-hop entry for
particular destination.
 If not in cache, longest prefix match is done.
 Check whether destination is on- or off-link
 On-link: Sent directly to destination
 Off-link: Sent to default router. Possible redirect.
 Identify link-layer address of next-hop
124
Default router selection
 A Host selects one router from it‘s default router list, if
– destination is off-link AND no cache entry exists for the
destination
OR
– Exisiting default router appears to be failing
• Default router is selected the first time traffic is sent
to an off-link destination. This selection is cached and
used for subsequent transmission.
• REACHABLE routers have coarse preference metric
(low, medium, or high).
• If multiple reachable routers exist, selection process
depends on vendor‘s implementation
125
Neighbor unreachability detection
The process by which a node determines that IPv6 packets cannot
be exchaged with a neighboring node. After the link-layer address
for a neighbor has been determined, the state of the entry in the
neighbor cache is tracked. If the neighbor is no longer exchanging
packets, the neighbor cache entry is eventually removed.
 2 ways to verify neighbor reachability:
– Using hints from upper-layer protocols
– From responses to neighbor solicitations
 Forward direction communication (FDC) must be
possible for a neighbor to be REACHABLE
 FDC is verified if forward progress is being made by
an upper-layer protocol (i.e. TCP, reception of TCP
acks)
126
Neighbor unreachability detection
• If no verification can be received from upper-layer
protocols (like UDP):
– Node actively probes neighbors to determine reachability
state
• Probes are sent in conjunction with traffic. No traffic,
no probes!
• Probe is neighbor solicitation (NS)
• Neighbor advertisement (NA) reply is expected to
establish FDC
127
Neighbor unreachability detection
•
•
Neighbor cache stores information about neighbors
– IP address
– Link-layer address
– Reachability state
Neighbor reachability states (RFC 4861, updated by RFC 7048)
– INCOMPLETE: Address resolution is being performed on the entry. Specifically,
a NS has been sent to the solicited-node multicast address of the target, but the
corresponding NA has not yet been received.
– REACHABLE: Forward-direction communication has been verified within the
past (e.g.) 30 seconds.
– STALE: An entry in the neighbor cache has not been verified as reachable within
the past 30 seconds. An unsolicited NA message will add an entry to the cache
for the sender of the message, with the state STALE. No action is required until
traffic is sent to the STALE entry.
– DELAY: No reachable verification has been received within the past 30 seconds,
and a packet has been sent to the specified neighbor within the past 5 seconds.
If no positive confirmation is received within 5 seconds of entering DELAY state,
send an NS and change state to PROBE.
– PROBE: An NS has been sent to verifiy reachability. No NA has yet been
received. After N unsuccessful attempts discart entity (RFC 4861).
– UNREACHABLE (RFC 7048). Increase timeout and send multicast NS. 128
Stateless Autoconfiguration
1. RS
2. RA
2. RA
1 - ICMP Type = 133 (RS)
Src = ::
Dst = All-Routers multicast Address
query= please send RA
2 - ICMP Type = 134 (RA)
Src = Router Link-local Address
Dst = All-nodes multicast address
Data= options, prefix, lifetime,
autoconfig flag
Router solicitations are sent by booting nodes to request RAs for
configuring the interfaces.
129
Auto configuration
“Plug and play” feature
Stateless mode :
Prefix
3ffe:89::/64
+
via ICMP (no server required)
IPv6 Address
Link Address
=
00:A87:C09:1BE:CC7:BA
3ffe:89::A87:C09:1BE:CC7:BA
router advertisement
Stateful server mode :
via DHCP
DHCP
server
DHCP response
3ffe:89::A87:C09:1BE:CC7:BA
DHCP request
00:A87:C09:1BE:CC7:BA
130
Auto configuration
Renumbering
Hosts renumbering is done by
modifying the RA to announce
the old prefix with a short
lifetime and the new prefix.
Router renumbering protocol
(RFC 2894), to allow domaininterior routers to learn of
prefix introduction /
withdrawal
RA indicates
SUBNET
PREFIX
SUBNET PREFIX +
MAC ADDRESS
SUBNET PREFIX +
MAC ADDRESS
At boot time, an IPv6 host
build a Link-Local address,
then its global IPv6
address(es) from RA
131
IPv6 Addressing Examples
LAN: 3ffe:b00:c18:1::/64
Ethernet0
interface Ethernet0
ipv6 address 2001:410:213:1::/64 eui-64
MAC address: 0060.3e47.1530
router# show ipv6 interface Ethernet0
Ethernet0 is up, line protocol is up
IPv6 is enabled, link-local address is FE80::260:3EFF:FE47:1530
Global unicast address(es):
2001:410:213:1:260:3EFF:FE47:1530, subnet is 2001:410:213:1::/64
Joined group address(es):
FF02::1:FF47:1530
FF02::1
FF02::2
MTU is 1500 bytes
132
Duplicate address detection
 Must be performed by all nodes
 Performed before assigning a unicast address to an
interface
 Performed on interface initialization
 Not performed for anycast addresses
 Link must be multicast capable
 New address is called "tentative" as long as
duplicate address detection takes place
133
Duplicate Address Detection
A
B
ICMP type = 135
Src = 0 (::)
Dst = Solicited-node multicast of A
Data = link-layer address of A
Query = what is your link address?
Duplicate Address Detection (DAD) uses neighbor solicitation to verify
the existence of an address to be configured.
134
Duplicate address detection
• If address already exists, the particular node sends a
NA reply with
– Target address = tentative IP address
– Destination address = tentative solicited-node address
• If soliciting node receives NA reply with target
address set to the tentative IP address, the address
must be duplicate
135
Overview of Mobile IPv6
CN
4.
3.
HA
1.
MN
2.
• 1. MN obtains Local IP address using stateless or stateful autoconfiguration
– Neighbor Discovery
• 2. MN registers with HA by sending a Binding Update
• 3. HA intercepts traffic for registered MN and tunnels packets from CN to
MN
• 4. MN sends packets from CN directly or via HA using Tunnel
136
Route Optimization
Home
Agent
Correspondent
Host
CN to MN
Mobile
Node
• Traffic is routed directly from the CN to the MN
• Binding Update SHOULD be part of every IPv6 node implementation
• IPv4 also has route optimization but CN needs enhanced IP stack and Key
management is a problem
• Security Issues –
– Shared Key or PKI Problem and We need a Scalable Solution
137