IPv6 Tutorial - unipg.itconan.diei.unipg.it/WEB-RTM/lucidiRCM/IPv6.pdf · 2 IPv6 - Important changes • Expanded Address Space – Address length quadrupled to 16 bytes • Header

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.


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:


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

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)



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



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.



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




payload



payload

4

frag off ident

src = 1.2.3.4

dst = 2.3.4.5

TTL prot checksum

src = ::1.2.3.4


dst = ::2.3.4.5




payload

4

frag off ident

src = 1.2.3.4

dst = 2.3.4.5

TTL prot checksum

src = ::1.2.3.4


dst = ::2.3.4.5


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


Source: 1.2.3.4


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



• IPv4 routers:


• 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


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


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





32 bits

MTU

IPv6 Header




packet.

106

ICMPv6: Time exceeded

Code 0 – Hop limit exceeded in transit

1 – Fragment reassembly time

exceeded





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




packet.

107

ICMPv6: Parameter problem

Code 0 - erroneous header field

encountered

1 - unrecognized Next Header type

encountered

2 - unrecognized IPv6 option

encountered





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




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


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.


Data

32 bits

Identifier Sequence Number

IPv6 Header




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


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


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


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


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


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

IPv6 Tutorial - unipg.itconan.diei.unipg.it/WEB-RTM/lucidiRCM/IPv6.pdf · 2 IPv6 - Important changes • Expanded Address Space – Address length quadrupled to 16 bytes • Header

Documents