1
IPv6 Tutorial
Gianluca Reali
2
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
3
IPv4- Datagram
0 15 16 31
Version (4) Total Length (16)
Identifier (16) Fragment Offset (13)
IHL (4) Type of Service (8)
Options & Padding (multiple of 32)
Time To Live (8) Protocol (8) Header Checksum (16)
Source Address (32)
Destination Address (32)
Data
.
Flag(3)
•Version = 4
• IHL - Internet Header Length = 5 with
no header options
[min = 160 bits] [max = 512 bits]
• Type of service , desired quality
service
0- 2 Precedence
3 Normal delay low delay
4 Normal throughput High throughput
5 Normal Reliability High reliability
6- 7 Reserved
Prec. D T R 0 0
0 1 2 3 4 5 6 7
•Identification, Flags, Fragmentation Offset- use to segmentation and
reassembly packet
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 )
•Option and Padding - additional info to
control functions such as routing and
security
4
Issue on header format
• 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.
vers
frag offset
source address
destination address
options and padding
header checksum
TOS total length
identification
hlen
protocol
flag
TTL
5
Address space
- Communications appliances (e.g. phone, pager) - Information appliances(e.g. electronic books) - Entertainment appliances (e.g. set-top boxes)
• More connected devices
• More management costs
• More demanding applications
• IPv4 with only 32 bits gave approximately 4.3 x109
LARGE ADDRESS SPACE NEEDED
Facts : With current world populations 2 persons need to
share an IP address
6
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!
Internet gowth
IP 4
7
Fragmentation flag
• Identification Number
16 bits integer value used to identify all fragments. This id is not a
sequence number!
• Flags - 3 bits control fragmentation
R DF MF
• Fragment offset - indicate the distance of fragment data
from the start of the original datagram, measure in 8 octets unit
reserved, must be 0
0=may fragment
1=don’t fragment
0=last fragment
1=more fragment
vers
frag offset
source address
destination address
options and padding
header checksum
TOS total length
identification
hlen
protocol
flag
TTL
8
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!
9
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.
10
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
11
Host auto-configuration
Stateful Server Mode
Via DHCP
DHCP
Server
DHCP request
DHCP respond
host
Stateless Server mode will be a better solution and can
save cost
12
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.
13
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
14
Header comparison
vers
0 15 16 31
hlen TOS total length
identification flags frag offset
TTL protocol header checksum
source address
destination address
options and padding
20 bytes
vers traffic class flow label
payload length next header hop limit
source address
destination address
40 bytes
Removed (6) • ID, flags, frag offset
• TOS, hlen
• header checksum
Changed (3) • total length=> payload
• protocol=>next header
• TTL=>hop limit
Added (2) • traffic class
• flow label
Expanded • address 32 to 128 bits
IPv4
IPv6
15
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.
16
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.
17
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
18
Path MTU discovery
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
FDDI MTU=4500
Ethernet MTU=1500
Source Destination
FDDI MTU=4500
FDDI MTU=4500
ICMP “packet too big”
A B
19
IPv6 packet structure
Extension
Headers
Higher-level protocol header
+ application content
payload
IPv6 packet
IPv6
Header
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
header
20
Extension headers
IPv6 header next header=TCP
TCP header + data
IP header IP Payload
Extension header
IPv6 header next header=routing
IP header
Routing header next header=TCP
TCP header + data
IP Payload
Extension headers
IPv6 header next header=routing
IP header
Routing header next header=fragment
fragment of TCP header + data
IP Payload
Fragment header next header=TCP
Extension Headers Higher-level protocol header
+ application content IPv6 Header
IPv6 packet
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
21
Extension headers
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
• 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).
22
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: 8-bit selector. Identifies the type of header immediately following the Hop-
by-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 8-
octet 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.
Next Header Hdr Ext Len
Options
23
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: 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.
Option Type Option Data Opt Data Len
24
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
25
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
same IPv6 packet.
26
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
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
of length such that the complete Routing header is an integer multiple of 8 octets long.
Routing Type Segments Left
27
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
Identification
Fragment Offset
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.
Res M
28
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
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.
Fragmentable Part
29
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
Last
fragment …
Unfragmentable Part Fragment
Header First
fragment
Unfragmentable Part Fragment
Header
Last
fragment
…
The last header of the Unfragmentable Part changed to 44.
30
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.
31
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).
32
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.
33
AH Modes
Transport Mode
Tunnel Mode
34
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.
35
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.
Encapsulating Security Payload (ESP)
36
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
37
ESP Modes
Transport Mode
Tunnel Mode
38
Combinations of Security
Associations
39
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
40
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.
41
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)
42
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.
43
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.
44
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 upper-
layer protocol must take into account the larger size of the IPv6 header relative to the
IPv4 header.
45
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
46
• 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 versus 3.4 x 10^38 addresses
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)
Address space
IPv4 IPv6
IPv4 Address space
192.228.134.34
32-bit
IPv6 Address Space
3FFE:90:AD:23:112:9:56:210
128-bit
47
Address syntax: preferred
• Hexadecimal values of the eight 16-bit pieces, separated
by colon
• Example:
FE78:3450:BED8:9542:FEDC:BA09:1236:763C
3FFE:0:0:0:13:45D:432:1A
X:X:X:X:X:X:X:X
X = 16-bit numbers
e.g. A3BF or FFFE
48
Address syntax: compressed
• Compressed form=> “::” indicates multiple groups of 16-
bits 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
49
Anycast : defines a number of recipients A packet sent to an anycast address is delivered to one of the
interfaces (the working nearest interface)
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
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)
50
Address allocation
Unspecified 00…0 (128 bits) ::/128
Multicast 11111111 FF00::/8
Link-Local unicast 1111111010 FE80::/10
Address Type Binary prefix
Loopback 00...1 (128 bits) ::1/128
Anycast addresses are taken from the unicast address
spaces and are not syntactically distinguishable from unicast
addresses.
IPv6 notation
Prefix is used to identify type of IPv6 address; normally
the first 16 bits (or first 2 bytes)
Global Unicast (everything else)
51
Global Unicast Addresses (RFC 3587)
Interface-ID global routing prefix
n bits 128-n-m bits
128 bit
Subnet-ID
m bits
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.
52
IPv4-compatible
& IPv4-mapped
• These addresses have a mixed environment of IPv4 and
IPv6 addresses:
0:0:0:0:0:0:192.226.124.45 => ::192.226.124.45
0:0:0:0:0:FFFF:192.226.124.45 => ::FFFF:192.226.124.45
1) IPv4-compatible IPv6 address
technique for hosts and routers to dynamically tunnel IPv6 packets
over IPv4 routing infrastructure – dual stack
2) IPv4-mapped IPv6 address Never src/dest of IPv6 packets.
IPv4-compatible 00..(96 bits of zero) 0:0:0:0:0:0:n.n.n.n
Allocation Binary Prefix Example
IPv4-mapped 00..ffff(80 bits of zero) 0:0:0:0:0:ffff:n.n.n.n
53
IPv4-mapped addresses
IPv6-only applications
TCP / UDP / others (SCTP,
DCCP, etc.)
IPv4 IPv6
IPv4 packets IPv6 packets
IPv4-mapped
IPv6 addresses
IPv6 addresses
54
Link Local Addresses
Interface-ID 1111 1110 10
10 bits 64 bits
128 bit
0
54 bits
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.
55
Site Local Addresses
Interface-ID 1111 1110 11
10 bits 64 bits
128 bit
subnet ID
54 bits
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.
56
Unique Local IPv6 Unicast
Addresses (RFC 4193)
Interface-ID Prefix
7 bits 64 bits
128 bit
Global ID Subnet ID
40bits 16 bits
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.
1
L
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.
57
Unique Local IPv6 Unicast
Addresses
Interface-ID Prefix
7 bits 64 bits
128 bit
Global ID Subnet ID
40bits 16 bits 1
L
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
networks.
58
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.
59
Required Anycast Address
111…..1111 anycast ID Subnet prefix
n bits 121-n bits 7 bits
128 bit
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.
60
Multicast Addresses (RFC 4291)
Group-ID 11111111 flags
8 4 112
128 bit
scope
4
First 3 bits set to 0
Last bit defines address type (T flag):
0 = Permanent (or well-known)
1 = Locally assigned (or transient)
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
61
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.
62
Multicast Addresses
Reserved Multicast Addresses:
FF00:0:0:0:0:0:0:0 FF01:0:0:0:0:0:0:0 FF02:0:0:0:0:0:0:0
FF03:0:0:0:0:0:0:0 FF04:0:0:0:0:0:0:0 FF05:0:0:0:0:0:0:0
FF06:0:0:0:0:0:0:0 FF07:0:0:0:0:0:0:0 FF08:0:0:0:0:0:0:0
FF09:0:0:0:0:0:0:0 FF0A:0:0:0:0:0:0:0 FF0B:0:0:0:0:0:0:0
FF0C:0:0:0:0:0:0:0 FF0D:0:0:0:0:0:0:0 FF0E:0:0:0:0:0:0:0
FF0F:0:0:0:0:0:0:0
The above multicast addresses are reserved and shall never be
assigned to any multicast group.
63
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
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
Solicited-Node Address:
FF02:0:0:0:0:1:FF
XX:XXXX
ARP-like
multicast addresses that identify the group of all
IPv6 nodes, within scope 1 (interface-local) or 2
(link-local).
multicast addresses that identify the group of all
IPv6 routers, within scope 1 (interface-local), 2
(link-local), or 5 (site-local).
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
64
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.
65
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.
66
Hierarchical Addressing &
Aggregation
–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
ISP
2001:0410::/32
Customer
no 2
IPv6 Internet
2001::/16
2001:0410:0002:/48
2001:0410:0001:/48
Customer
no 1
Only
announces
the /32
prefix
(note: no masks in IPv6!)
67
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.
68
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
69
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
70
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 00000010 00000000 00001011 11111111 11111110 00001010 00101101 01010001
Resulting EUI-64 Address: 0200:0BFF:FE0A:2D51 U/L Bit
= FFFE
71
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
72
Dual Stacks
Physical/Data Link
IPv6 IPv4
TCP/UDPv6
IPv6
Applications
0x0800 0x86dd
TCP/UDPv4
IPv4
Applications
Network, Transport, and Application layers do not necessarily interact
without further modification or translation
73
Tunnel Applications
IPv4
IPv4
IPv6
Router to Router
Host to Router / Router to Host
Host to Host
IPv6 IPv6 IPv6
IPv6
IPv4
IPv6
74
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
75
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
76
Configured tunneling
……
IPv4 IPv6 IPv4 IPv6
src = 2001::A:A:B
(IPv6 adr)
dst = 2001::B:B:C
(IPv6 adr)
6 traffic flow label
payload len next hops
payload
flow label 6 traffic
payload len next hops
payload
4
frag off ident
src = R1
dst = R2
TTL 41 checksum
src = 2001::A:A:B
(IPv6 adr)
dst = 2001::B:B:C
(IPv6 adr)
2001::B:B:C
IPv6 host
2001::A:A:B IPv4 network IPv6 host
2001::B:B:C
• Encapsulate IPv6
packet in Ipv4
• IPv6 only
address hl TOS len
2001::B:B:C
R1 R2
src = 2001::A:A:B
(IPv6 adr)
dst = 2001::B:B:C
(IPv6 adr)
6 traffic flow label
payload len next hops
payload
77
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.
78
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)
79
• 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.
IPv6 Tunnel Broker with the Tunnel
Setup Protocol (TSP) (RFC 5572)
80
TSP Used on Tunnel Broker Model
IPv6
Network
Tunnel
Broker
IPv4
Network Tunnel
Server
TSP
Client
DNS
1
1. AAA Authorization
2. Configuration request
3. TB chooses:
• TS
• IPv6 addresses
• Tunnel lifetime
4. TB registers tunnel IPv6 addresses
5. Config info sent to TS
6. Config info sent to client:
• Tunnel parameters
• DNS name
7. Tunnel enabled
2
3
5
4
IPv6 Tunnel
6
7
TSP
Server
81
Automatic tunneling
src = ::1.2.3.4
(IPv4-compatible IPv6 adr)
dst = ::2.3.4.5
(IPv4-compatible IPv6 adr)
6 traffic flow label
payload len next hops
payload
flow label 6 traffic
payload len next hops
payload
4
frag off ident
src = 1.2.3.4
dst = 2.3.4.5
TTL prot checksum
src = ::1.2.3.4
(IPv4-compatible IPv6 adr)
dst = ::2.3.4.5
(IPv4-compatible IPv6 adr)
flow label 6 traffic
payload len next hops
payload
4
frag off ident
src = 1.2.3.4
dst = 2.3.4.5
TTL prot checksum
src = ::1.2.3.4
(IPv4-compatible IPv6 adr)
dst = ::2.3.4.5
(IPv4-compatible IPv6 adr)
2.3.4.5 2.3.4.5 2.3.4.5
……
IPv4 IPv6 IPv4 IPv6
IPv6 host
::1.2.3.4 IPv4 network IPv4/6 host
2.3.4.5
• Encapsulate IPv6
packet in Ipv4
• rely on IPv4-
compatible IPv6
address hl TOS len hl TOS len
82
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
• Router advertises 6to4 prefix to hosts via RAs
• Embedded IPv4 address allows discovery of tunnel endpoints
Reserved 6to4 prefix: 2002::/16
IPv4 address: 138.14.85.210 = 8a0e:55d2
Resulting 6to4 prefix: 2002:8a0e:55d2::/48
Example:
2002 Public IPv4
address
/48 /64 /16
Interface ID Subnet-
ID
83
6to4
IPv4 address: 138.14.85.210
6to4 prefix: 2002:8a0e:55d2::/48
6to4 address:
2002:8a0e:55d2::8a0e:55d2
IPv4 address: 65.114.168.91
6to4 prefix: 2002:4172:a85b::/48
6to4 address:
2002:4172:a85b::4172:a85b
IPv4
Network
IPv6
Site IPv6
Site IPv6
IPv6
Public Internet
6to4 Relay Router
6to4 Router 6to4 Router
84
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.
85
6over4 • Encapsulates IPv6 packets in IPv4 (protocol type 41)
Starting from fe80::
link-local IPv6 address: fe80::C000:28e
192.0.2.142, C000028e in hexadecimal notation
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.
To facilitate IPv6 multicast communications over an IPv4 multicast-
enabled 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 ]
86
• 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 global-
scope 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.
ISATAP Addresses (RFC 5214)
87
ISATAP
IPv6
IPv4
IPv4
IPv6
IPv4/IPv6
Router
6to4
Router
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.
88
ISATAP
Global IPv4 address: 65.114.168.91
Global IPv6 prefix: 2001:468:1100:1::/64
Link-local address: fe80::0200:5efe:65.114.168.91
Global IPv6 address: 2001:468:1100:1::0200:5efe:65.114…..
Example 1 :
Private IPv4 address: 172.18.133.14
Global IPv6 prefix: 2001:468:1100:1::/64
Link-local address: fe80::5efe: 172.18.133.14
Global IPv6 address: 2001:468:1100:1::5efe:172.18.133.14
Example 2:
89
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
90
Teredo
IPv6
Network
Teredo
Server
IPv4
Network
Teredo
Relay
Client
10.0.0.2
Inside Address: 10.0.0.1
Outside Address: 9.0.0.1
1
1. RS to server
2. NAT maps inside address/port
to outside address/port
3. TS notes:
• source address/port
• NAT type
4. RA to client containing:
• Service prefix
• origin indication
5. Client creates IPv6 address from:
• Server prefix
• “Obfusticated” origin
indication"mapped IPv4 address"
6. IPv6 packets
tunneled to relay 2 3
5
3ffe:831f:102:304::efff:f6ff:fffe
6
NAT
Source: 10.0.0.1:2716
Destination: 1.2.3.4:3544
IPv4 =1.2.3.4
IPv6 prefix = 3ffe:831f::/32
Source: 9.0.0.1:4096
Destination: 1.2.3.4:3544
Source: 1.2.3.4
Destination: 9.0.0.1:4096
Prefix:3ffe:831f:0102:0304::/64
Origin Indication: 9.0.0.1:4096
4
IPv6 over UDP tunnel
TSP can be used in place of RS/RA for:
Stateful tunnel
Authentication
4096:9.0.0.1=00010000000000000:00001001.00000000.00000000.00000001
111011111111111111110110.11111111.11111111.11111110 efff:f6ff:fffe
91
IPv64
• Proposed for highly interconnected IPv4 and IPv6 networks (mid-transition)
• IPv64 packets: IPv6 encapsulated in IPv4
– bit 48 (numbering from 0)
of IPv4 header indicates IPv64 packet
• IPv64 routers:
– Process IPv64 packets as IPv6
– Process IPv4 packets as IPv4
– Process IPv6 packets as IPv6
• IPv4 routers:
– Process IPv64 packets as IPv4
• IPv6 routers:
– 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
Ver.
4 HL Datagram Length TOS
Datagram-ID Flag Frag Offset
TTL Protocol Header Checksum
Source IPv4 Address
Destination IPv4 Address
IP Options
Ver.
6
Traffic
class Flow label
Payload Length Next
Hdr.
Hop
Limit
Source IPv6 Address
Destination IPv6 Address
IPv64 bit 1 = IPv64
0 = IPv4
92
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
93
DSTM
IPv6
Network
DSTM
Server
IPv4
Network
Tunnel
End-Point
Client
1
1. Client needs IPv4 connectivity
2. Client requests tunnel info
3. Server sends IPv4 tunnel endpoint
addresses
4. Tunnel set up
2
3
3
IPv4 in IPv6 Tunnel
4
jeff.juniper.net =
192.168.1.2
94
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)
95
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
96
Stateless IP/ICMP Translation (SIIT)
IPv6
Network
IPv4
Network
3ffe:3700:1100:1:210:a4ff:fea0:bc97
216.148.227.68
204.127.202.4
SIIT 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
Source = 216.148.227.68
Dest = 204.127.202.4
Source = 204.127.202.4
Dest = 216.148.227.68
SIIT also changes: •Traffic Class TOS
•Payload length
•Protocol Number NH Number
•TTL Hop Limit
97
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
98
v4host.4net.org
AAAA 3ffe:3700:1100:2::204.127.202.4
Network Address Translation - Protocol
Translation (NAT-PT) IPv6
Network
IPv4
Network
v6host.6net.com
3ffe:3700:1100:1:210:a4ff:fea0:bc97
v4host.4net.org
204.127.202.4
NAT-PT
DNS
IPv4 Pool: 120.130.26/24
IPv6 prefix: 3ffe:3700:1100:2/64
v4host.4net.org?
v4host.4net.org
A 204.127.202.4
99
Network Address Translation - Protocol
Translation (NAT-PT) IPv6
Network
IPv4
Network
v6host.6net.com
3ffe:3700:1100:1:210:a4ff:fea0:bc97
v4host.4net.org
204.127.202.4
NAT-PT
DNS
IPv4 Pool: 120.130.26/24
IPv6 prefix: 3ffe:3700:1100:2/64
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
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
Mapping Table
Inside Outside
3ffe:3700:1100:1:210:a4ff:fea0:bc97 120.130.26.10
100
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
101
Transport Relay Translator (TRT)
IPv6
Network
IPv4
Network
v6host.6net.com
3ffe:3700:1100:1:210:a4ff:fea0:bc97
v4host.4net.org
204.127.202.4
TRT
“Dummy” IPv6 Prefix =
fec0:0:0:1::/64
IPv4 Address =
216.148.227.68
TCP/IPv6 Session
Source = 3ffe:3700:1100:1:210:a4ff:fea0:bc97
Dest = fec0:0:0:1::204.127.202.4
TCP/IPv4 Session
Source = 216.148.227.68
Dest = 204.127.202.4
TCP/IPv4 Session
Source = 204.127.202.4
Dest = 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
Query to “special” DNS from v6host
for v4host.4net.org returns:
AAAA fec0:0:0:1::204.127.202.4
102
Application Layer Gateways
• Application-specific translator
• Needed when application layer contains IP address
• Similar to ALGs used in firewalls, some NATs
103
ICMPv6
Some important ICMPv6 message types:
1 Destination unreachable
2 Packet too big
3 Time exceeded
4 Parameter problem
128 Echo request
129 Echo reply
104
ICMPv6: Destination Unreachable
Code 0 - no route to destination
1 - communication with destination
administratively prohibited
2 - (not assigned)
3 - address unreachable
4 - port unreachable
Type=1 Code Checksum
As much of invoking packet
as will fit without the ICMPv6 packet
exceeding the minimum IPv6 MTU
32 bits
Unused
Unused This field is unused for all code
values. It must be initialized to zero
by the sender and ignored by the
receiver.
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
packet.
105
ICMPv6: Packet too big
Code Set to 0 by the sender and ignored by the receiver
MTU The maximum transmission unit of the next-hop link
Type=2 Code Checksum
As much of invoking packet
as will fit without the ICMPv6 packet
exceeding the minimum IPv6 MTU
32 bits
MTU
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
packet.
106
ICMPv6: Time exceeded
Code 0 – Hop limit exceeded in transit
1 – Fragment reassembly time
exceeded
Type=3 Code Checksum
As much of invoking packet
as will fit without the ICMPv6 packet
exceeding the minimum IPv6 MTU
32 bits
Unused
Unused This field is unused for all code
values. It must be initialized to zero
by the sender and ignored by the
receiver.
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
packet.
107
ICMPv6: Parameter problem
Code 0 - erroneous header field
encountered
1 - unrecognized Next Header type
encountered
2 - unrecognized IPv6 option
encountered
Type=4 Code Checksum
As much of invoking packet
as will fit without the ICMPv6 packet
exceeding the minimum IPv6 MTU
32 bits
Pointer
Pointer 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.
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
packet.
108
ICMPv6: Echo request
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.
Type=128 Code=0 Checksum
Data
32 bits
Identifier Sequence Number
IPv6 Header
Destination Address:
Any legal IPv6 address.
109
ICMPv6: Echo reply
Code 0
Identifier The identifier from the invoking Echo Request message.
Sequence Number The sequence number from the invoking Echo Request message
Data The data from the invoking Echo Request message.
Type=129 Code=0 Checksum
Data
32 bits
Identifier Sequence Number
IPv6 Header
Destination Address:
Copied from the Source
Address field of the invoking
Echo Request packet.
110
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
111
Neighbor discovery
ND makes use of five ICMPv6 packets to provide IPv6
nodes with the information they need before
communicating
133 Router solicitation (RS)
134 Router advertisement (RA)
135 Neighbor solicitation (NS)
136 Neighbor advertisement (NA)
5 Redirect
112
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)
113
Router solicitation (RS) format
Type=133 Code=0 Checksum
Reserved (unused, initialized to zero by the sender)
32 bits
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.
114
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
115
Router advertisement (RA) format
Type=134 Code=0 Checksum
Reachable Time
32 bits
Cur. Hop Limit M O Reserved Router lifetime
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
other servers within the network.
116
Neighbor discovery:
Router solicitation
A
B
C
D
E
F G
Default GW-List
A
B
C
RS
RA
117
Neighbor discovery:
Router advertisement
A
B
C
D
E
F G
Default GW-List
A
RA
118
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)
119
Neighbor solicitation (NS) format
Type=135 Code=0 Checksum
Reserved
32 bits
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.
120
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
121
Neighbor advertisement (NA)
format
Type=136 Code=0 Checksum
Reserved
32 bits
Target address
Options....
R S O
R Router flag. When set, the R-bit indicates that the sender is a router.
S 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.
O Override flag indicates that the information of the message should override an
existing Neighbor chache for which no link layer address exists
122
Redirect
Type=137 Code=0 Checksum
Reserved
32 bits
Target address
Options....
Destination address
123
Redirect
A
B
C
D
E
F G
Default GW-List
A
B
C
ICMP Redirect to
Router B
Path used with Default
Gateway "A"
Host 3
Sent data to Host 3 using
Default GW "A"
Redirect traffic
via Router B
124
Next-hop discovery
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
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.
125
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
126
Neighbor unreachability detection
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)
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.
127
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
128
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.
129
Stateless Autoconfiguration
Router solicitations are sent by booting nodes to request RAs for
configuring the interfaces.
1 - ICMP Type = 133 (RS)
Src = ::
Dst = All-Routers multicast Address
query= please send RA
2. RA 2. RA 1. RS
2 - ICMP Type = 134 (RA)
Src = Router Link-local Address
Dst = All-nodes multicast address
Data= options, prefix, lifetime,
autoconfig flag
130
Auto configuration
“Plug and play” feature
Stateless mode :
Stateful server mode :
via ICMP (no server required)
via DHCP
Prefix
3ffe:89::/64 + Link Address
00:A87:C09:1BE:CC7:BA =
IPv6 Address
3ffe:89::A87:C09:1BE:CC7:BA
DHCP server
00:A87:C09:1BE:CC7:BA
DHCP request
router advertisement
3ffe:89::A87:C09:1BE:CC7:BA
DHCP response
131
Auto configuration
At boot time, an IPv6 host
build a Link-Local address,
then its global IPv6
address(es) from RA
RA indicates
SUBNET
PREFIX
SUBNET PREFIX +
MAC ADDRESS SUBNET PREFIX +
MAC ADDRESS
SUBNET PREFIX +
MAC ADDRESS SUBNET PREFIX +
MAC ADDRESS
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 domain-
interior routers to learn of
prefix introduction /
withdrawal
132
IPv6 Addressing Examples
LAN: 3ffe:b00:c18:1::/64
Ethernet0
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
interface Ethernet0
ipv6 address 2001:410:213:1::/64 eui-64
133
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
134
Duplicate Address Detection
ICMP type = 135
Src = 0 (::)
Dst = Solicited-node multicast of A
Data = link-layer address of A
Query = what is your link address?
A B
Duplicate Address Detection (DAD) uses neighbor solicitation to verify the existence of an address to be configured.
135
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
136
Overview of Mobile IPv6
• 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
HA
1. 2.
MN
CN
4. 3.
137
Route Optimization
• 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
Mobile
Node
Home
Agent
Correspondent
Host
CN to MN
Top Related