Chapter 10 I.P.V.6

A. Van Maele et al.

Audio by Paper2Audio.

Additions to the book on the topic of I.P.V.6, by I.Dlab

Computer Networking

A Top-Down Approach

Special thanks to Dries Naudts & Johannes Deleu for providing information and giving feedback on the draft versions.

Goals

• Understand the basics of I.P.V.6

– I.P.V.6 structure

– I.C.M.Pv6 features

– Differences with I.P.V.4

• A world with I.P.V.4 and I.P.V.6 – Transition mechanisms

The need & progress of I.P.V.6 today

I.P.V.6 X-2

In general, excellent information on I.P.V.6 can be found on the following websites: 6deploy dot eu U.R.L ( although you still need Adobe Flash to access this site )

en dot wikipedia dot org U.R.L

The 6deploy website has been extensively consulted to work out this chapter.

Further, in depth reading can be found in

I.P.V.6 Fundamentals: A Straightforward Approach to Understanding I.P.V.6 Cisco Press, Rick Graziani

I.S.B.N 978-1-587-14313-7

I.P.V.6 Essentials, 2nd Edition,

Silvia Hagen, O'Reilly Media

I.S.B.N 978-0-596-10058-2 The left figure illustrates the different Regional Internet Registries (R.I.R), which are now organised on a continental level.

:Image summary: A bar chart and corresponding color-coded world map illustrating IPv4 address distribution among Regional Internet Registries (RIRs). The chart measures pool size in /8s, showing ARIN with the largest share at 100.0, followed by APNIC at 52.9804, RIPE NCC at 49.0861, LACNIC at 11.3715, and AFRINIC at 7.2271. An IETF_Reserved category is listed at 35.3282. A remark notes that since 2011, all /8 blocks have been assigned to RIRs, with no further changes except for shifts between them.

The right figure indicates the number of /8 blocks that are allocated to these R.I.R's in 2011 (in total there are 256 /8 blocks).

1. I.E.T.F reserved: As noted in R.F.C 5735 a number of address blocks are reserved outside 'conventional' use in the public Internet. Adding up these 'Specialized Address Blocks' makes for the equivalent of +/-35 /8 address blocks in this category. This is composed of 16 /8 blocks reserved for use in multicast scenarios, 16 /8 blocks reserved for some unspecified future use, 1 /8 block (0.0.0.0/8) for local identification, a single /8 block reserved for loopback (127.0.0.0/8), and a /8 block reserved for private use (10.0.0.0/8). Smaller address blocks are also reserved for other special uses.

2. The remaining 221 /8 address blocks are available for use in the public I.P.V.4 Internet. iana (Internet Assigned Numbers Authority) holds a pool of unallocated addresses, while the remainder has already been allocated by iana for further downstream assignment by the R.I.R's. Historically, the blocks have been assigned in a {non-hierarchical} order.

See also: potaroo dot net U.R.L

Image sources:

ripe dot net U.R.L

potaroo dot net U.R.L Historically, the /8 class A blocks were handed to whichever organisation requested such an address block. /8 address blocks have been assigned to I.T companies such as H.P, I.B.M and Apple. Also large I.S.P's as Level3 own /8 address ranges. But also other companies, not immediately active as big I.T companies today, such as General Electric Ford or Xerox were involved in the 1980s, and have retained these large address spaces for a very long time – or ever since.

Image summary: This treemap diagram visualizes the distribution of IPv4 address space, representing the allocation of IP blocks to various organizations and regional internet registries. The chart uses blocks of varying sizes to indicate the amount of address space held by entities such as ARIN, APNIC, RIPE NCC, and large corporations like IBM, Microsoft, and the Department of Defense. Large portions of the map are color-coded by registry, while smaller, fragmented sections represent more granular allocations. Two large gray areas in the top right corner are designated for multicast and future use.

E.g. network 44.0.0.0 slash 8 has been assigned to Amprnet, amateur digital radio communication, since 1981 (originally requested by Hank Magnuski, see R.F.C790). Only starting in 2010 some of these class A address ranges have been returning to the R.I.R's for re-usage as the number of available I.P.V.4 started decreasing. Historically, Stanford University was one of the first organisations (already in the year 2000) to start reconfiguring their entire network, so their original 36.0.0.0 slash 8 network could be re-used by Apnic.

[source:

computerworld dot com dot au U.R.L move rekindles net address debate/

On the next slides, some of the history of the depletion of I.P.V.4 addresses will be discussed.

I.P.V.4 Address Exhaustion

- Known issue since 1992

- Life extended by cidr and N.A

- Figure: # of available /8 networks per continent

- International depletion: 3rd of Febr, 2011

Image summary: A line graph titled RIR IPv4 Address Run-Down Model plotting the RIR Address Pool in /8s against time from 2008 to 2015 for five regional internet registries. ARIN begins with the highest pool at approximately 25 /8s and declines most sharply, while AFRINIC, APNIC, RIPE NCC, and LACNIC start at lower levels and decline more gradually. All five registries' pools converge toward zero by 2015.

Image summary: A line graph titled IANA Allocations - Smoothed Data showing the Address Count in /8s from 2002 to 2012. The count increases steadily from approximately 120 in 2002 to a peak of 220 by 2012, with a final plateau circled in purple at the end of the timeline.

I.P.v 4 was developed in the 70s and the 80s, and the main members of the Internet then were universities and companies who were active in developing network technology (I.B.M, Xerox, Cisco,...). In 1984, the networks consisted of only 1000 hosts. The address space seemed large at the time – about 4.10 superscript 9 addresses – and for example an American university like Stanford could easily request a /8 network range.

Already in 1992, the I.E.T.F became aware that the continuing growth of the Internet and the rules with classful addressing would quickly lead to a shortage of networks. This exhaustion of I.P.V.4 address space led to adaptations of the existing standards:

- As a short-term solution the I.E.T.F proposed the use of Classless Inter-Domain Routing (cidr), which allows for more efficient use of the I.P.V.4 address space.

- After much discussion, around 1995, I.P.V.6 (I.P version 6) was picked as the final I.P.n.g (I.P next generation) proposal from a set of proposals. The core I.P.V.6 protocols became an I.E.T.F Draft Standard on August 10, 1998.

- A new standard, Network Address Translation (nat), enabled the existence of very small networks using private address space.

nat was the real saver for for example small home networks and many company activities.

However, further growth of the Internet in for example Asia and Africa led to the allocation of almost all /8 networks, as is depicted in the figure above. The last 5 available /8 networks have been assigned to the 5 continental R.I.R's on February 3rd, 2011. apnic already used this last /8 network, implying that I.P.V.4 addresses for that R.I.R are now depleted. The other R.I.R's still have some ranges of available I.P.V.4 addresses, however for every R.I.R a depletion date within the next 3 years has been predicted.

- I.P.V.4 only Internet (without I.P.V.6?)

- Multiple Layers of nat (Carrier-grade nat)

- – Free Market for public I.P.V.4 Addresses?

Image summary: A line graph titled RIR IPv4 Address Run-Down Model tracking the available IPv4 address pools for five Regional Internet Registries (RIRs) from 2013 to 2020. The y-axis represents the RIR Address Pool in /8s, and the x-axis represents the Date. AFRINIC holds the largest pool, starting above 4.0 and declining steadily toward zero by 2019. APNIC, ARIN, RIPE NCC, and LACNIC show various rates of decline, with most pools dropping below 1.0 /8 by 2016. A marker denotes Oct/2015, and a label for IPv6 X-6 appears at the bottom right.

[ Text continued from previous slide ]

In some recently more developed countries, for example Russia, another method to deal with depletion is used without shifting towards I.P.V.6. As there is lack of public I.P.V.4 addresses, I.S.P's also started to use nat to provide their customers with a private I.P address on their home routers. When a user at home then uses his own nat device, he will get multi-level nat (alternative names: nat.4.4.4, Carrier-grade nat).

greater than (Reference: en dot wikipedia dot org U.R.L)

As outlined in R.F.C.5.6.8.4, this can lead to problems of mistaken end host identity if both the I.S.P and the home user nat device would use the same address range (e.g. the default 192.168.0.0/24 range on most devices).

Some proposed to organise the I.P.V.4 address space as a free market, so this economic principle would regulate the availability of I.P.V.4 addresses. But then again this would oppose to the principle that everyone should be able to have access to the Internet; furthermore most policies of for example ripe and national legislations do not support to own an I.P address.

Very recently the policies have been relaxed and trading of I.P.V.4 addresses is starting within R.I.R's – for example between Belgian and Dutch TelCos (see. for example iptrading dot com).

Image summary: A line chart showing the increase of IPv6 usage based on Google data from 2010 to November 13, 2024. The usage grows exponentially over time, reaching a total of 42.04% by the end date, consisting entirely of native usage. A vertical blue line marks the date of international IPv4 depletion on February 3rd, 2011.

As depicted above, the usage of I.P.V.6 has increased worldwide since the I.P.V.4 address depletion. The increase however is still small compared to I.P.V.4 usage: the number of Google-users using I.P.V.6 is still only about 40%.

(figure: percentage of users that access Google over I.P.V.6).

European # of I.P.V.6 clients: November 2025

Image summary: A map of Europe showing IPv6 adoption rates and latency impact for November 2025. France has the highest listed adoption at 87.31% with a -20ms latency and -0.03% impact. Germany follows at 75% adoption with -10ms latency and -0.01% impact. Belgium has 69.69% adoption with 0ms latency and -0.01% impact, while the Netherlands has the lowest listed adoption at 24.51% with 0ms latency and 0.03% impact.

Belgium

I.P.V.6 Adoption: 69.69%

Latency / impact: 0ms / -0.01%

France

I.P.V.6 Adoption: 87.31%

Latency / impact: -20ms / -0.03%

Within Europe, some countries have either an active government strategy who pushes the usage of I.P.V.6 (e.g. Slovenia), or some Internet Providers who have already migrated to using I.P.V.6 (e.g. France, {free dot fr} ). The figure on this slide illustrates the number of client making I.P.V.6 requests to Google, based on their country.

The measurements contain information about the additional delay that I.P.V.6 hosts experience compared to I.P.V.4 hosts (Latency), and the percentage the increased latency is compared to the average latency of I.P.V.4 hosts (impact). As can be seen, European countries already using I.P.V.6 do not experience significant additional latency.

These statistics are updated on google dot com U.R.L

F.Y.I, see also :

vyncke dot org U.R.L and akamai dot com U.R.L

Netherlands IPv6 Adoption: 24.51% Latency / impact: 0ms / 0.03%

Germany IPv6 Adoption: 75% Latency / impact: -10ms / -0.01%

Outline

Addressing Scheme

- Notation

Address scopes

– Address types

The I.P.V.6 Header

I.C.M.Pv6 "Super" Protocol

I.P.V.4 and I.P.V.6

I.P.V.6 X-9

Address Space

• 128-bit long addresses (=16 bytes)

- >– 2 raised to the power of 128 is approximately 3.4 times 10 raised to the power of 38 addresses (compared to I.P.v 4: 4.3 times 10 raised to the power of 9)

Notation:

– 8 fields of 2 bytes, separated by a colon :

2 bytes per field: hexadecimal

Example (32 hex symbols) 2001:0660:30f3:AC01:0000:0000:6d43:210f

2 logical parts:

- First 64 bits: (sub-)network prefix

- Last 64 bits: interface identifier (I.I.D)

- Notation : I.P.V.6 address/prefix length

- 2001:0660:30F3:AC01:0000:0000:6d43:210f/64

I.P.V.6 X-10

I.P.V.6 addresses consist of eight hexadecimal groups. Each hexadecimal group, separated by a colon (:) consists of a 16-bit hexadecimal value. The following is an example of the I.P.V.6 format:

X.X.X.X:X.X.X.X:X.X.X.X:X.X.X.X:X.X.X.X:X.X.X.X:X.X.X.X:X.X.X.X

A group of xxxx represents the 16-bit hexadecimal value. Each individual x represents a 4-bit hexadecimal value. The following is an example of a possible I.P.V.6 address:

Math summary: This expression represents a specific IPv6 address. It consists of eight groups of sixteen bit hexadecimal values separated by colons, starting with twenty zero one and ending with twenty one zero eff.

I.P.V.6 addresses are normally written with hexadecimal digits, as opposed to the dot-decimal notation of the 32 bit I.P.V.4 addresses.

I.P.V.6 addresses are typically composed of two logical parts: a 64-bit (sub-)network prefix, and a 64-bit host part called interface identifier.

The prefix length is the same as the slash notation in I.P.V.4: it identifies the part of the address that belongs to the network identifier. It specifies how many left-most bits of the address identify the scope of the prefix. When for example an I.S.P has a /48 prefix length, it can use the remaining 16 bits of the prefix or network part to create further subnets.

This prefix length is based on cidr principles, and allows aggregation of ranges, reducing routing table sizes.

Address Notation

- Base format

2001:0660:30f3:0001:0000:0000:6d43:210f

- Skip leading zero's

2001:660:30f3:1:0:0:6d43:210f

• Replace consecutive zero's (only allowed once)

2001:660:30f3:1::6d43:210f

- Notation remarks:

- I.P.V.4 address included in last bytes: dot-decimal allowed 2001:0660:30f3:0001::101.67.33.15

- Literal I.P.v 6 notation in U.R.L's: between brackets http:// [2001:660:30f3:2:a00:20ff:fe 18:964c]:443/ I.P.v 6 address Port nr

I.P.V.6 X-11

The base format of 16 bytes is quite long, and two principles have been added to allow shorter notation of an I.P.V.6 address.

First, the leading zeros in a 16-bit block must be skipped. Hence

Becomes 2001:0660:30f3:0001:0000:0000:6d43:210f

2001:660:30f3:1:0:0:6d43:210f

Second, a double colon must replace consecutive zero's of leading or trailing zeros within the address, to its maximum capability. The example then becomes 2001:660:30f3:1:6d43:210f

The symbol "::" must not be used to shorten just one 16-bit 0 field. E.g. the 4 superscript th hextet in 2001:db8:1:0:1:2:3:4 must be explicitly noted. A double colon can only appear once in an address, so this shortening operation can be done only once. When equal in length, the first sequence of zero bits must be shortened. For example, 2001:db8::1:0:0:1 is correct representation.

The rules for notation are quite strict, and formalized in R.F.C 5952

Sometimes the lower 4 bytes of an I.P.V.6 address contain an I.P.V.4 address. In this case you can write the last 4 bytes as a regular I.P address, for example 2001:0660:30f3:0001::101.67.33.15.

Using colons in the address conflicts with the meaning of a colon in a U.R.L, as colons have a different meaning in U.R.L's. Because colons are also used in U.R.L's to separate the port number from the address information, an I.P.V.6 address is noted with its literal representation in a U.R.L, by surrounding it with brackets, for example

http:// [2001:660:30f3:2:a00:20ff:fe 18:964c]:443/

This is formalised in R.F.C 3986

Interface Identifier (I.I.D)

Image summary: This diagram illustrates the process of generating an IPv6 Interface Identifier (IID) from a 48-bit MAC address using the EUI-64 format. It shows the transformation of a MAC address (00-08-b3-1e-83-29) by splitting it into two parts, inserting the hex value 'ff:fe' in the middle, and toggling the U/L bit to create an EUI-64 address, which is then converted into the final 64-bit IID. The text highlights that using a device's MAC address for this identifier creates privacy concerns because it can be traced on websites, and suggests using randomized, time-changing privacy addresses generated via hashing as a solution.

The last 64bits of an I.P.V.6 address are used to form an Interface Identifier (I.I.D) within a network. The creation of such an identifier depends on the link-layer protocol. As most networks in company and home environments are using Ethernet technology, we explain how an I.I.D is deduced from the mac address of an L.2 interface.

The Interface Identifier is a unique 64-bit identifier that is based upon the E.U.I-64 (Extended Unique Identifier) format defined by I-triple-E. To create an E.U.I-64 address from a mac address, the 16 bits of 11111111 11111110 (0xfffe) are inserted into the I-triple-E 802 address between the company I.D and the vendor-supplied I.D.

To obtain the 64-bit interface identifier for I.P.V.6 unicast addresses, the U/L bit in the E.U.I-64 address is complemented (if it is a 1, it is set to 0; and if it is a 0, it is set to 1). This is the 7 superscript th bit within the E.U.I-64 address.

In I.P.V.4, users typically get an I.P address from an D.H.C.P server, implying that their address changes from time to time. Their Internet usage is thus anonymous.

Using I.P.V.6, as the interface identifier is always based on the E.U.I-64 address (as derived from the static I-triple-E 802 address), it is possible to identify the traffic of a specific node (regardless of the prefix), making it easy to track a specific user and his use of the Internet. To address this concern and provide a level of anonymity, an alternative I.P.V.6 interface identifier that is randomised and changes over time is described in R.F.C 4941.

Informational : in practice, different operating systems choose different default I.I.D generation:

• Windows 7 by default uses privacy addresses

- Linux supports privacy addresses, but by default uses an E.U.I-64 based I.I.D

- Mac O.S X prior to version 10.7 uses E.U.I-64 based I.I.D's by default; privacy keys are the default setting from version 10.7 onwards.

Further information:

technet dot microsoft dot com U.R.L

tools dot ietf dot org U.R.L

Multiple addresses

Every interface mostly has more than one I.P.V.6 address

– for example Host: local and global address => address scope concept

– for example D.H.C.P server : a unicast and a multicast address => address type

• 'New' concept : address scope

– Defines where the address is valid

E.g. Local addresses Global addresses

I.P.V.6 X-13

In I.P.V.4, a typical interface had one address. I.P.V.6 interfaces are designed to have multiple addresses. For example, a D.H.C.P server has a unicast address for normal operations (e.g. an S.S.H connection to maintain the server), but also has a multicast address to receive D.H.C.P requests. In this example, the addresses are of a different type.

Each I.P.V.6 address also has a 'scope', which specifies in which part of the network it is valid and unique. The scope of an address is encoded as part of the address, and can typically be found in the first bits.

In general, scopes are now defined in R.F.C 4007, but this R.F.C already indicates that changes in the definitions are to be expected. E.g. multicast scopes have been redefined (see further).

Image summary: A diagram illustrating IPv6 address scopes, which define where an address is valid. The graphic shows two computers connected to a switch, which is then connected to a router leading into the IPv6 Internet. It distinguishes between a Link-Local Scope, which is local and not routable, and a Global Scope, which is routable. The diagram highlights that a single interface can hold multiple addresses, specifically both a Link-Local Address and a Global Address, and notes that site-local addresses are defined but deprecated.

Address Scopes

The main scopes are:

- link-local -> unique on the current link

- global -> a public I.P address, globally unique

- site-local -> unique within the organization -> deprecated

Previously defined scopes have been deprecated, as research has turned out that the definitions might lead to problems. Example is the site-local addresses (obsoleted by R.F.C 3879).

If an interface has multiple addresses, the question arises which address should be set when an outgoing packet is being crafted by the node. Rules have been set-up to give priority to the addresses in determining the source address by R.F.C 6724.

Link-local Address scope

Link-local Address

।Image summary: A diagram illustrating the structure of an IPv6 link-local address with the prefix fe80::/10. The address is divided into three segments: the first 10 bits are set to 1111 1110 10, followed by a 54-bit field of zeros, and concluding with a 64-bit Interface ID.

Practice: fe80::/64 (54 bits are all zero!)

Auto-generated

– “Zero-config” communication in lan

Configured without central server or manual administration

Example : not configured I.P.V.6 host

Code summary: This text provides the network configuration details for an Internet adapter labeled eth1, specifically an Intel PRO/1000 MT Desktop Adapter. It lists hardware identification via the physical address and outlines the current connection state, noting that DHCP is disabled while autoconfiguration is enabled, and specifies the preferred link-local IPv6 address.

One of the first things an I.P.V.6 node does at boot time, is to auto-generate an I.P.V.6 link-local address for each of its interfaces. As all nodes are doing this auto-configuration, communication "on the link" is possible without the need for a D.H.C.P server or router, or a manual configuration.

Link-local addresses consist of a fixed prefix fe80::/10, completed with 54 zeros to fill up the network part, and their Interface I.D in the host part of the address.

As an example, let's have a look at the interface of an I.P.V.6 host, which hasn't been configured with any address:

:Code summary: This command execution displays the network interface configuration for eth1, identifying its hardware MAC address, its IPv6 link-local address within a 64-bit prefix, and active operational flags such as UP, BROADCAST, and MULTICAST.

As can be seen, the host has automatically generated an I.P.V.6 Link-local address, with an I.I.D based on the mac address of the interface. This is the default setting on a Linux based host.

A Windows based host by default applies an extra md5 step, to mask the mac address of the interface. An example is illustrated in the slide of this page (see above).

The Link-local scope fe80::/10 can be compared with the 169.254/16 range in I.P.V.4.

Informational: where the strict definition of the link-local prefix allows a huge address space – fe80::/10, all Link-local Unicast Addresses in practice use the fe80::/64 prefix, as can be seen in the Linux example. The remaining 54 bits of the network part, are always set to zero, although other values would still include them within the link-local scope. This is reserved address space, and not (yet) in use.

Further reading : ietf dot org U.R.L

Global Address scope

• Global Unicast Address

- – Prefix 2000::/3

Table summary: A network address breakdown where the Global routing prefix is 3 bits, the Subnet ID is 45 bits, and the Interface ID is 16 bits, totaling 64 bits.

/48 prefix

- Allocated in /48 prefix ranges

- To for example companies, universities, ...

- Allows further subnetting: 16bit Subnet I.D

- Example : 2001:06a8:1d80::/48

- – 2001:06a8:1d80:0027::/64 : servers

- – 2001:06a8:1d80:1018::/64 : test subnet ipv6 only

- Still 65536 – 2 possible subnets available!

I.P.V.6 X-16

The global (unicast) address has the functionality of what we know as “a classical I.P.V.4 address”.

The first three bits are set to “001”; the prefix 2000::/3 hence indicates all globally routable addresses.

Current recommendations are to allocate addresses in blocks of 45 bits, to for example I.S.P's or companies. Organizations hence become network ranges consisting of a /48 prefix. The remaining 16 bits in the network part can be used to do further subnetting within the organization.

An example: iMinds I.C.T research) has been assigned the 2001:06a8:1d80::/48 prefix. A first subnet was created by iMinds, 2001:06a8:1d80:0027::/64, to create a network for their servers. A second subnet, 2001:06a8:1d80:1018::/64, has been created to allow tests with Global I.P.V.6 addresses.

This further subnetting can be done by the company itself; 2 to the power of 16 equals 65,536 possible subnets can be created.

Exercise 1: network example

। Image summary: A network diagram illustrating a connection to the IPv6 Internet. Two computers, each with a unique MAC address and a prompt for a Link-Local Address, are connected to a network switch, which is further connected to a router that also lists a MAC address and prompts for a Link-Local Address. The router then connects to a cloud representing the IPv6 Internet.

Configure a Link-Local I.P.V.6 address on each interface

Configure Global I.P.V.6 addresses in the same lan

(network: 2001:db8:1::/64)

I.P.V.6 X-17

As an exercise, calculate the Link-Local addresses of the small network above. We presume Linux hosts, without additional md5 randomisation.

Further on, we will continue elaborating this basic network.

Network example: host routing table

Image summary: A network diagram and a corresponding kernel IPv6 routing table illustrating a host connected to the IPv6 Internet via ROUTER1. The host has two IPv6 addresses: fe80::208:b3ff:fe1e:8329 and 2001:db8:1:0:208:b33ff:fe1e:8329. ROUTER1 has the address fe80::20c:46ff:fefa:ceb0 and 2001:db8:1:0:20c:46ff:fefa:ceb0. The reduced routing table on the host lists three entries on interface eth1: a directly connected route to 2001:db8:1::/64, a directly connected route to fe80::/64, and a default route (::/0) with a next hop of fe80::20c:46ff:fefa:ceb0.

Once the host has both a link-local and global address, the routing table of the host is interesting to study.

The host now has three routes:

• The link-local network fe80::/64

• The global network, of which he has received the prefix (see AutoConfiguration)

• The default route ::/0, pointing to the router as the default gateway as next hop As in I.P.V.4 routing tables, the basic information consists of the networks the node is directly connected to, and a default route to the Internet.

Directly connected routes Default route

Informational:

The flags of the latter contain information about this default route: it is up (U), and points to a gateway (G). This entry has been dynamically (D) added when the address was configured on the router (A).

The Metric column displays the 'distance' to the target (usually counted in hops). It is not used by recent kernels, but may be needed by routing daemons. The other columns (Ref, Use) contain statistical information about the usage of the route.

Exercise 2: router routing table

Image summary: A network diagram illustrating IPv6 communication between two computers, PC X and PC Y, and a router, Router A, connected to the IPv6 Internet. PC X, with address fe80::208:b3ff:fe1e:8329, and PC Y, with address fe80::20c:46ff:feb2:a5b0, are connected to Router A. Router A has two interfaces: eth1 with address fe80::20c:46ff:fefa:ceb0 and eth2 with address fe80::211:2fff:fecf:7678. The diagram depicts two ping request scenarios from PC X: one directed to Router A's eth1 address and another directed to a next hop address, fe80::280:c8ff:fe66:fcc, located within the IPv6 Internet cloud.

A router typically has more than one interface. When initialised, all interfaces generate an I.I.D and configure a Link-local I.P.V.6 address.

Construct the routing table of the router – only containing link-local networks, without global addresses until now.

Can you ping from P.C X to router B.

Can router A respond to a ping coming from P.C X?

Construct the routing table of router A. Only use Link-local. 1) Can PC X ping Router B? 2) Can PC X ping Router A?

Default Subnet sizes

/48 not at random (<=> I.P.V.4)

– /12 to /23 registry for R.I.R

R.I.R = regional Internet registry

Organised on continental level /32 I.S.P Prefix /48 Site Prefix

Bits 49 to 64 for subnets within a site (company, university)

216 = 65,535 subnets available

: Image summary: A diagram illustrating the structure of an IPv6 address. The address is divided into hierarchical segments: a Registry (/23), an ISP (/32), a Site (/48), and a Subnet (/64). The left side of the address contains hexadecimal values '2001', '0DB8', '0001', and '0001', while the final segment is labeled 'Interface ID' and is explicitly marked as being 64 bits long.

In I.P.V.4, the available /8 classes have been distributed to the R.I.R's (regional Internet registry) on a “when needed basis”. This leads to a distribution of the I.P.V.4 classes around the globe without the possibility to efficiently aggregate large networks.

Less aggregation is a burden for large routers, as they have large tables.

I.P.V.6 global scope addresses are managed in a more hierarchical way. The continental R.I.R's have not received “some /48” blocks, but have been assigned a /23 prefixes in the available 2000::/3 global scope.

Upon request, they should assign /32 sized prefixes to I.S.P's. An I.S.P then has +65k/48 blocks available to assign to customers, such as companies or universities.

The routes to these customers are aggregated by the I.S.P; when peering with other I.S.P's only the aggregated route /32 has to be added to the routing table of other I.S.P's. Further fragmentation of the address space should only happen within the network of the I.S.P.

I.S.P's in the same geographical region can be aggregated into large /23 address blocks, which can be used by for example tier-1 I.S.P's to route these aggregated blocks using intercontinental connections.

). Image summary: A hierarchical diagram illustrating the distribution of IPv6 unicast address assignments. At the top is IANA, which manages the 2001::/3 block. This is distributed to five Regional Internet Registries: AfriNIC, APNIC, ARIN, LACNIC, and RIPE NCC, each receiving blocks from ::/12 to ::/23. Each regional registry then assigns /32 blocks to Internet Service Providers (ISPs), which in turn allocate /48 blocks to individual Sites.

A graphical overview of how the Global Scope is organised is depicted above:

• iana allocates from the Global Scope 2001::/3 I.P.V.6 unicast address space to regional registries such as apnic and ripe.

• Each regional registry gets a /23 prefix from iana, although a larger address space can be requested (upto /12 is in use)

• The registry typically allocates a /32 prefix to an I.P.V.6 I.S.P.

- Then the I.S.P allocates a /48 prefix to each customer (or potentially /64 for a local network or /128 for a single host).

An overview of already assigned I.P.V.6 unicast address space by iana: iana dot org U.R.L

Regional R.I.R's can ask for larger address space then a /23 when needed. arin, the U.S.A Registrar, uses the following I.P.V.6 address blocks:

Math summary: This expression lists several IPv6 address blocks assigned by ARIN to allow routing toward the USA. It specifies five networks with a twenty three bit prefix and one network with a twelve bit prefix.

One /12 block has been requested and assigned. These six networks allow other continents to route toward the U.S.A.

https://www.iana.org/assignments/ipv6-unicast-address-assignments

Link-local addition: zone index

• Zone index appended to Link-local address

Image summary: A network diagram illustrating the use of IPv6 zone indices to distinguish between link-local addresses across different network segments. The diagram shows two distinct zones connected by a router: a local network segment on the left and the IPv6 Internet on the right. It demonstrates that because link-local addresses like fe80::/10 are not unique globally, a zone index, formatted as address%zone_id, must be appended to the address to specify the interface, such as fe80::208:b3ff:fe1e:8329%eth1 or fe80::280:c8ff:fe66:fcc%eth2, to ensure correct routing within the host operating system.

The solution for multiple Link-local scopes in one routing table is defined by R.F.C 4007: the addition of a unique zone index for traffic entering the link-local interface of a node, represented textually in the form address percent zone id, for example: fe80::280:c8ff:fe66:fcc percent eth2

The zone index should be unique for each zone, but this is of course from the viewpoint of the node itself. The R.F.C allows the O.S of a node to choose how the zone index is represented, using a unique number or just the name of the interface. Each O.S has his own preference to define this zone index:

- The Microsoft Windows I.P.V.6 stack uses numeric zone lds, for example fe80::3%1. The index is determined by the interface number.

- Most Unix-like systems (e.g., B.S.D, Linux, Mac O.S 10) use the interface name as a zone index.

As this zone index is only added inside the node, it cannot be detected by for example Wireshark.

Unfortunately, relatively few I.P.V.6-capable applications understand zone I.D syntax (with the notable exception of OpenSSH, thus rendering link-local addresses unusable for applications if multiple interfaces use link-local addresses.

Informational remarks:

• The Linux ifconfig command as of version 1.42 does not display zone I.D's.

- The notation using the"%" symbol creates a syntax conflict with the percent-encoding used with U.R.I's.

Private Networks: u.l.a (Unique Local Address)

Image summary: A network diagram titled Multiple LANs, no Global Scope, illustrating two distinct local area networks connected by a central router. Each network segment is labeled as having a Link-Local Scope, with individual devices and router interfaces assigned specific IPv6 link-local addresses starting with fe80. The diagram highlights that while the two LANs are separated by the router, they both fall under a broader Unique Local Address Scope.

Link-local addresses are bound to the limits of a lan; when packets need to cross the border of the router they need other addresses, such as Global addresses. Global addresses can span multiple L.A.N's in an organisation, however a globally assigned prefix needs to be requested. Structuring a local network with multiple L.A.N's, without global addresses, can be done using the Unique Local Address (u.l.a) scope.

Without global addresses, Unique Local Addresses can be used to interconnect L.A.N's – and communicate beyond the Link-local scope.

The functionality is comparable with the I.P.v 4 private addresses.

• Multiple LANs, no Global Scope?

Unique Local Address Scope ( $ \rightarrow $ see next)

Unique Local Address scope

Unique Local Address (u.l.a)

- Third scope next to Link-local and Global

- Local communications between L.A.N's

-

- – Fixed prefix: fc00::/7

Table summary: A single record of network identifiers where the Global ID is 7, the Subnet ID is 40, and the Interface ID is 64, associated with the value 1

- Pseudo-randomly allocated global I.D

- High probability of uniqueness

- Avoiding conflicts when connecting two u.l.a sites

- When generated locally : L=1 (-> fd00::/8)

- Note that fc00::/8 is not used ('for future use')

I.P.V.6 X-24

A unique local address (u.l.a) is an I.P.V.6 address, available for networks that are not routable on the global I.P.V.6 Internet. A fixed prefix is preserved: fc00::/7.

In R.F.C.4.1.9.3, the remaining bits of the network part are defined :

- The L bit is set to one if the Global I.D is locally allocated. L=0 may be defined in the future

• 40-bit global identifier used to create a globally unique prefix -> this allows for 2 superscript 40 different I.D's!

- 16-bit Subnet I.D is an identifier of a subnet within the site, to create multiple L.A.N's with the same global identifier.

A u.l.a scope is routable only within a private network or between a limited set of u.l.a sites. The R.F.C defining the u.l.a addresses, contains an algorithm which allows a pseudo-random generation of a Global I.D. If routing is to happen between two independently created u.l.a sites, the chance that there is a conflict due to having the same Global I.D on both sites is very small ( 1/2 superscript 40 ).

The functionality is comparable with the I.P.V.4 private addresses, but almost without a chance that another site with “private addresses” would have the same prefix (e.g. when a tunnel has been set up between two sites). In I.P.V.4, almost all private sites use 192.168.1.0/24 – and end up with ambiguities when interconnected with tunnels.

Remark: as local assignment of pseudo-unique I.D's is the only method defined, by default the L bit is always set to 1. This implies that all U.L.A's in use at this moment should start with the prefix fd00::/8 ; the range fc00::/8 is reserved for future definitions.

Unique Local Address : example

Image summary: A network diagram illustrating IPv6 addressing with a central router connecting two distinct subnets. The central router uses interfaces eth1 and eth2 to link to two separate switches, each serving two desktop computers. The diagram demonstrates the use of Unique Local Addresses (ULA) with a 48-bit global ID prefix, showing how a 40-bit prefix is used to derive 64-bit subnets, labeled as fdda:c01d:bee2:1::/64 on the left and fdda:c01d:bee2:2::/64 on the right. Each device is assigned specific link-local and ULA addresses.

When using a u.l.a scope, a first step is using the algorithm in the R.F.C to generate a pseudo-random global I.D of 40 bits, for example da:c01d:bee2. Some websites provide an implementation of the algorithm, for example cd34 dot com U.R.L .

When you have generated a (pseudo-unique) global I.D, this results in a prefix as for example fdda:c01d:bee2::/48. Recall that the L bit should be set to 1.

In the network portion of the U.L.Addresses, 16 bits are remaining to create multiple subnets within your organisation. In the example, two subnets for each lan can be created, for example

fdda:c01d:bee2:1::/64 and fdda:c01d:bee2:2::/64

Using these subnet ranges, each host in the two separate L.A.N's should be assigned a Unique Local Address from the corresponding range. When manually assigned, the I.I.D can be chosen.

As I.P.V.6 is designed to support multiple addresses, the u.l.a is added to the interfaces of the nodes next to the auto-configured Link-local address. Furthermore, when a Global scope would be configured in the organisation, they can co-exist with the already assigned Unique Local Addresses.

Remark: in practice, unthoughtful system administrators do not pseudo-random generate the I.D, but just choose “0”. fc00::/64 is often used as a u.l.a scope. However, when ever interconnecting two sites using this u.l.a addressing, the same problems of interconnecting two sites using 192.168.1.0/24 will arise. Furthermore, fd00 should have been chosen as the L bit is still reserved!

Step 1: generate a (semi-)unique Global ID:

e.g. “da:c01d:bee2” (40 bits) => Prefix fdda:c01d:bee2::/48

Step 2: create networks from this prefix

Step 3: assign addresses from these networks (e.g. manually instead of generated IID)

Address Types

Scope vs Type:

- Address Scope: where the address is used

- Address Type: wherefore the address is used

Address Types

- Unicast: one-to-one

- Multicast: one-to-many

।Image summary: A diagram consisting of six colored circles and an arrow. A single red circle on the left is connected by a line that bends upward and ends in an arrow pointing to a green circle. Four yellow circles are scattered around the green circle.

Image summary: A diagram showing a red circle on the left connected by branching lines to three green circles on the right. Three yellow circles are positioned around the green circles but are not connected to any lines.

e.g. ff02::1 is “All nodes on the local network site”

- Anycast: one-to-nearest (in routing terms)

- No more broadcast ...

There are different types of I.P.V.6 addresses:

• Unicast: identify single network interface, packet is delivered to that specific computer

- Multicast: define a set of interfaces, that typically belong to different nodes instead of just one. Packets are delivered and processed by all interfaces identified by that address.

• Anycast: just like with multicast, an anycast address is assigned to a group of interfaces. A packet sent to an anycast address is delivered to just one of the member interfaces. Typically this is the nearest one, according to the routing protocol's idea of distance.

• Broadcast: broadcast is no longer present in I.P.V.6. The implication of this decision will be discussed later on.

Remark: each interface needs at least one unicast address. A single interface can be assigned multiple I.P.V.6 addresses of any type (uni, multi, any). A node can therefore be identified by the address of any of its interfaces.

Figure IPv6 X-26 summary: A diagram consisting of seven colored circles. A single red circle on the left is the origin of two arrows: one pointing towards a yellow circle in the upper center and another pointing towards a green circle in the lower right. Other unconnected circles in the space include two additional yellow circles and two additional green circles.

Multicast Address

Image summary: A network diagram showing a red circle on the left connected by lines to three green circles on the right. Three additional yellow circles are positioned in the space among the green circles but remain unconnected to any other elements.

，Image summary: A technical diagram and text explaining IPv6 multicast addressing. It features a memory map of a prefix starting with ff00::/8, divided into segments including an 8-bit prefix, a 4-bit Flags field, a 4-bit Scope field, and a 112-bit section containing the Group ID in the last 32 bits. A table defines the Scope values, ranging from 0 (Reserved), 1 (Interface-local), 2 (Link-local), 3 (Realm-local), 4 (Admin-local), 5 (Site-local), 8 (Organization-local), E (Global), to F (Reserved), citing RFC 4291 and 7346. The text provides examples of multicast groups for NTP servers using Group ID 0101, demonstrating how the scope changes the target audience from a single node (ff01::101) and link (ff02::101) to a site (ff05::101) and the entire Internet (ff0e::101).

More scopes defined than currently in use

- Multicast group for N.T.P (Network Time Protocol) servers (group I.D: 0101) - ff01::101 All N.T.P servers on the same node as the sender - ff02::101 All N.T.P servers on the same link as the sender - ff05::101 All N.T.P servers on the same site as the sender - ff0e::101 All N.T.P servers on the Internet

Multicast, the transmission of a packet to multiple destinations in a single send operation, is part of the base specification in I.P.V.6. In I.P.V.4 it is an optional although commonly implemented feature. Multicast addresses begin with the prefix ff00::/8.

The usage of multicast is more extensive in I.P.V.6. As we will see when we discuss I.C.M.Pv6, a lot of protocol functionality uses multicast messages. E.g. a D.H.C.P request is initially not broadcasted, but multicasted to the address ff02::1:2.

The address ff02::1 within a local scope is defined as “all nodes on link”, and can be used in case a (local) broadcast still would be necessary.

An overview of already defined I.P.V.6 addresses can be found in iana dot org U.R.L

The second octet identifies the multicast address scope, that is the range over which the multicast address is propagated. Currently used scopes include link-local (2), and global (E). E.g. depending on the scope, different sets of N.T.P servers can be addressed. The scopes are defined in R.F.C more scopes are defined then currently are used (e.g. Site-local has been defined, but already deprecated).

Informational: the flags field is a set of 4 flags: |0|R|P|T|. The high-order flag is reserved (and set to 0). The T flag indicates a tran-zee-unt address (1), or a permanent, well known multicast address (0). The P flag indicates a prefix. Within I.P.v 6 multicast, this flag allows part of the group address to include the source's networks Unicast prefix, which creates a globally unique Group Address. The R flag is used for multicast tree management.

Multicast, no more broadcast

- ff02::1 <=> broadcast

- – ff02::1 is “all nodes on link”

- Broadcast deprecated in I.P.V.6

- Each interface automatically joins ff02::1

- Not to be used in normal operations

: A diagram showing a red circle on the left connected by lines to three green circles on the right. Three yellow circles are positioned around the green circles but are not connected to any other elements.

Code summary: This command-line output displays the IPv6 routing table for a host to show how network traffic is directed. It identifies local link-address routing for the fe80::/64 prefix, multicast routing for ff00::/8, and establishes a default gateway via the next hop fe80::20c:46ff:fefa:ceb0 on the eth1 interface to handle all other outbound IPv6 traffic.

I.P.V.6 X-28

Where multicast in I.P.V.4 is used to sent information over large networks, but only to a select group of subscribed hosts and routers, multicast in I.P.V.6 is also used to arrange communication inside a lan.

In I.P.V.4, certain messages were broadcasted, for example a.r.p broadcast. This turned out to be very inefficient in larger networks, as each host was receiving numerous (a.r.p) broadcasts per second – each triggering an interrupt for the CPU.

Broadcast has been deprecated in I.P.V.6, and replaced by multicast when needed. Although not used as much as in I.P.V.4, each node shall join the ff02::1 group when a message should be delivered “in broadcast style”.

As an I.P.V.6 node joins multicast groups, a corresponding entry is added in the routing table of a host.

As we shall discuss further on, next to the all nodes, other multicast groups exist to minimize the traffic sent to all nodes as much as possible.

Anycast

“one-to-one-of-many”

multiple nodes : same anycast address

– nearest receives, others don't

Possibilities: one anycast address for

Mirror servers

– D.N.S servers

Main next-hop router, backup next-hop router

Unresolved issues

Active T.C.P connections during anycast update

Image summary: A diagram showing a red circle on the left with two arrows originating from it. One arrow points toward a yellow circle in the upper center, and the other arrow points toward a green circle in the lower right. Other unconnected yellow and green circles are scattered across the right side of the image.

I.P.V.6 X-29

Conceptually, anycast is a cross between unicast and multicast: an arbitrary collection of nodes may be designated as an anycast group.

A packet addressed to the group's anycast address is delivered to only one of the nodes in the group, typically the node with the "nearest" interface according to the routing protocol. This is in contrast with multicast services, which deliver packets to all members of the multicast group.

I.P.V.6 Anycast addresses are taken from the unicast address space, and cannot be identified when compared to unicast addresses.

Although anycast also exists in I.P.V.4, it is almost never used. Within I.P.V.6, anycast is defined in R.F.C 4786. As a new service, applications are still in development:

When popular sites are being mirrored, the choice of the mirror depends on the user's choice in I.P.V.4. An anycast address might fix the choice to the nearest.

The D.N.S server of a larger organisation can be duplicated to spread the load, but all instances can use the same anycast address.

Using anycast, an enterprise could forward packets to exactly one of the routers on its I.S.P's backbone. If all of a provider's routers have the same anycast address, traffic from the enterprise will have several redundant access points to the Internet. And if one of the backbone routers goes down, the next nearest device automatically will receive the traffic.

Anycast has one main open issue: if a new server is entered in the I.P.V.6 Internet, the nearest might change for a host who already has an open T.C.P connection with the “previous nearest”. This might lead to hanging connections.

As a result, practical implementations of I.P.V.6 anycast are not that common, due to some of these unresolved issues. An overview can be found in “Scott Weber and Liang Cheng, A survey of anycast in I.P.V.6 networks, I-triple-E Communications Magazine, volume 42, No. 1, pp. 127 to 132, January 2004”

Preserved addresses?

• No more preserved addresses - Broadcast ~ “all ones” Broadcast functions in I.P.V.4 -> Multicast in I.P.V.6 157.193.215.255/24 -> ff02::1 (all nodes) I.I.D “all ones” ffff:ffff:ffff:ffff is valid

Network address ~ “all zeros”

Network address in I.P.V.4 -> Prefix notation in I.P.V.6 157.193.215.0/24 -greater than 2001:db8:1::/64

I.P.V.6 all zeros address is valid: 2001:db8:1::/128 : router anycast address

Image summary: A diagram depicting a red circle on the left with several arrows pointing toward green circles on the right. A large red X is superimposed over the center of the diagram, crossing out the paths between the red circle and the green circles.

I.P.V.6 X-30

In I.P.V.4, two preserved addresses in the subnet, with the host portion set to all-zeros or all-ones (resp. used as network and broadcast addresses), were not allowed, as described in R.F.C.9.5.0. This exception no longer exists in I.P.V.6.

Broadcast (all-ones) in I.P.V.4 had some disadvantages (e.g. generating too much a.r.p traffic) and has been removed in I.P.V.6. When the functionality is needed, it is replaced with a special multicast address, called “All nodes on Link” (ff02::1). An I.P.V.6 address with “all ones” in the I.I.D, for example 2001:db8:1:0:ffff:ffff:ffff:ffff is now a valid address.

As most of the functionality of the I.P.V.4 broadcast has been replaced by different kinds of multicast solutions (see for example Neighbor Discovery Protocol), the address ff02::1 is rarely used.

Also the network address (all-zeros) is no longer preserved; the least significant address with all-zeros in the host portion in I.P.V.6, can be used as I.P address. However, it is required as the router anycast address, as described in R.F.C.4.2.9.1. Reserved, but it is a valid I.P.V.6 address.

The network address is no longer formed by putting the host bits to zero, but by just not writing the host bits.

• 2001:db8:1::/64 indicates the network

• 2001: db8:1::/128 indicates the router anycast address

When multiple routers exist on a lan (e.g. for redundancy), each of the routers is required to adopt the router anycast address. All routers are required to support the Subnet-Router anycast addresses for the subnets to which they have interfaces.

A mobile node, away from his home subnet, can use the router anycast address to send packets directly to any router of his home network

Address Space overview

Table summary: IPv6 address space allocations by prefix hex value. The vast majority of the space is unassigned, with the largest block from 4000 to fe7f accounting for approximately 75 percent, followed by ranges covering about 11 percent and 0.38 percent. Specific functional allocations include the 2000 to 3fff range for aggregatable global unicast and documentation, fc00 to fdff for unique-local, fe80 to feBf for link-local, and ff00 to ffff for multicast. The prefix 0000 to 00ff is IETF Reserved for the unspecified and loopback addresses.

By looking at an I.P.V.6 address, we can tell what kind of address we are dealing with. An overview of the already assigned address space, and special addresses, is depicted on the slide above.

Within the reserved address space ::/8 (the short version of 0000::/8), some useful definitions of special addresses can be found:

• :: is the Unspecified Address. It is typically used in the source field of a datagram sent by a device seeking to have its I.P address configured.

• ::1 is the Loopback Address.

The Global unicast address space has already assigned prefixes. E.g. each I.P.V.4 address can be used to create a tunnel to the I.P.V.6 Internet, and then has an I.P.V.6 network which is starting with 2002::/16 (6to4, see transition mechanisms). In Belgium, many prefixes have been assigned in 2012. University of Ghent for example has a /48 address space, received from ripe.

Another prefix, 2001:db8::/32 is intended for documentation only (and for example often used in this document).

The addresses used for link-local, u.l.a and multicast are specified at the end of the I.P.V.6 address space, ranging between fc00 and ffff.

Remark that the major part of the address space (over 80%) is unassigned, which leaves room for future assignments.

Further information: iana dot org U.R.L

Exercise 3: I.P.V.6 Addresses

Which of the following are valid I.P.V.6 addresses?

2001:6a8::d80:21::49

2001:6a8:1d80:21::49

2001:6g8:1d80:21::49

3001:6a8:1d80:21::49

4001:6a8:1d80:21::49

What is the scope/type of these addresses ff02::2 fe80::1 f8e0::1 ff02::1:ff0e:8c6c fd00:1::7

Table summary: An outline consisting of six topics, including Addressing Scheme, The IPv6 Header, ICMPv6 "Super" Protocol, IPv4 and IPv6, and Transition mechanisms.

The I.P.V.6 Header

Table summary: A side-by-side comparison of the header structures for IPv4 and IPv6, both organized in 32-bit segments. The IPv4 header includes fields such as Ver., IHL, ToS, Total Length, Identifier, Flags, Fragment Offset, TTL, Protocol, Checksum, Source Address, Destination Address, and Options. In contrast, the IPv6 header simplifies the structure with fields for Ver., Traffic Class, Flow Label, Payload Length, Next Header, Hop Limit, Source Address, and Destination Address, while allowing for optional extension headers.

The I.P.V.6 header is comparable with the I.P.V.4 header, but some significant changes have occurred. The header has doubled in size to 40 bytes, as the two fields for source and destination address are now each 128bits or 16 bytes. The header is now also fixed in size, and only 8 bytes remain for general header info and is therefore much simpler.

Some fields of the header have been retained, although some names have changed compared to I.P.V.4:

•The Version field is retained, but now contains the number 6. However, this field has a limited use because I.P.V.4 and I.P.V.6 packets are not distinguished based on the value in the version field but by the protocol type present in the layer 2 envelope.

•The ToS is renamed to Traffic Class

•Instead of the Total Length, the Payload Length is now indicated and no longer includes the size of the header (as the header size is fixed).

•The Protocol type has been renamed to Next Header, for example indicating that the content of the I.P payload starts with T.C.P as the next header.

•The T.T.L field is renamed to Hop Limit

Where I.P.V.4 could have options added to the header (increasing the header size above 20B, I.P.V.6 no longer has the options field. When options are to be added, an additional extension header can be inserted after the main header (see next slides).

Five standard fields have been removed : (I.H.L, Id, Flags, Frag offset, checksum)

•The I.H.L or Internet Header Length is no longer needed, as the size of the header is fixed.

•The checksum is no longer calculated, as this is already done in other layers.

•I.D, Flags and Fragment Offset have been removed, as fragmentation is no longer part of the main header, but has been moved towards an optional extension header

One field has been added to the header: Flow Label. This may be used by a source to label sequences of packets. Otherwise, the host just sets this field to zero.

The I.P.V.6 header is defined by tools dot ietf dot org U.R.L

I.P.V.6 Header: Better Processing

• I.P.V.6 Has a Fixed Header Length

- Options field and I.H.L (Header Length) field are removed

- – Options functionality -> Extension headers (see next slide)

• Header Checksum is removed from I.P.V.6

- – No recalculation due to T.T.L value change by router

- – Checksum at the datalink & transport layer (Ethernet, U.D.P, T.C.P)

• Fragmentation: moved to an Extension header (see next slide)

- – Routers do not fragment packets anymore

- => Path M.T.U Discovery !!!

- Identifier. Flags. Fragment Offset are removed

• Flow Label

- Group packets for same treatment

I.P.V.6 X-35

However, mostly unused by the majority of operating systems

By simplifying the I.P.V.6 header, I.P.V.6 packets are a lot easier to process for a router. Several of the changes on the previous slides lead to this better processing.

First, the I.P.V.4 header can be extended up to 60 bytes. The router looks at the value of I.H.L, and then decides how many bytes of header it needs to process. The I.P.V.6 header has a fixed length, so this step in processing can be skipped.

This implies that the main I.P.V.6 header doesn't contain any options; options are moved into the Extension headers (next slide).

(re)Calculating a checksum is an expensive operation, and this was needed every time the T.T.L was decreased. As I.P is actually a best-effort delivery protocol, this checksum was no longer adopted to I.P.V.6. Furthermore, it doesn't make sense today to checksum I.P packets:

- Link quality has improved drastically (e.g. by using fibre optic connections)

- In most cases the datalink layer already performs check summing; there is also a checksum at the transport layer (U.D.P/T.C.P).

I.P.V.6 fragmentation is now the task of the sending host; routers will not be fragmenting during the travel of a packet through the network. As fragmentation "on the path" no longer will be done, I.P.V.6 hosts are expected to perform Path M.T.U Discovery to find the smallest link M.T.U of all links from source to destination.

Fragmentation may still be needed when the upper layer protocol cannot handle the size of datagrams delivered to the I.P.V.6 layer; therefore a Fragment extension header can be inserted when needed. The Next Header value is set to 44 to indicate that a Fragment extension header follows.

Compared to I.P.V.4, the Identifier, Flags and Fragment offset are thus removed from the main header.

A flow label can identify a flow of packets in I.P.V.6, without the need for looking into the upper layer protocol to determine whether a packet belongs to a certain flow. The router then can use this information to decide the treatment of the packet.

The flow label should be unique, in combination with the same source and destination I.P.V.6 address. The exact function of the flow label is still under discussion; the proposed standard can be found in R.F.C 6437

I.P.V.6 Extension Headers

Image summary: A diagram illustrating the chaining of IPv6 headers. It shows three scenarios of how the Next Header field links subsequent headers to data. In the first row, the IPv6 Header identifies the Next Header as TCP, leading directly to a TCP Header and data. In the second row, the IPv6 Header identifies Routing, which leads to a Routing Header, which then identifies TCP as the Next Header, leading to a TCP Header and data. In the third row, the IPv6 Header identifies Routing, which leads to a Routing Header, which identifies Fragment as the Next Header, leading to a Fragment Header, which then identifies TCP as the Next Header, leading to a TCP Header and data.

Contrary to I.P.V.4, which covered options the header, options in I.P.V.6 are covered by using Extension Headers when needed. Extension headers are always aligned at 8 bytes; there is no fixed number of extension headers. Together, they form a chain of headers.

The next header field specifies the following extension header; the chain typically ends with a next header pointing to the application layer protocol.

There are several extension headers defined, and new extension headers may be defined in the future. A table overview:

Table summary: The sequencing and identification of IPv6 headers. The process begins with the Basic IPv6 Header, followed by optional extension headers in a specific order. These include Hop-by-Hop Options with a next header code of 0, Destination Options with Routing Options code 60, Routing Header code 43, Fragment Header code 44, Authentication Header code 51, Encapsulation Security Payload Header code 50, Destination Options code 60, and finally the Mobility Header with code 135.

Extension headers are to be examined and processed at the packet's destination only, except for Hop-by-Hop Options, which need to be processed at every intermediate node on the packet's path, including sending and receiving node.

The order of the extension headers is important. If more than one header is used, they have to be sorted as in the table. Also, the Extension headers must also strictly be processed in the order in which they appear in the packet.

Types of Extension Headers

Hop-by-Hop Options header - Router Alert: contains important information about forwarding (M.L.D, R.S.V.P - Jumbogram: contains a Payload Length field of 32 bits => datagram greater than 64kB

2. Destination Options header (1) – Optional information to be examined by the routers listed in the Routing header

3. Routing header – List of routers to cross

4. Fragmentation header

5. Authentication header (ipsec)

6. Encrypted Security Payload header (ipsec)

7. Destination Options header (2) – Optional information to be examined by the destination node only (e.g. Mobile I.P.v 6)

Processed by every router

Processed by routers listed in

Routing extension

Processed only by the destination

I.P.V.6 X-37

Lets have a look at the functionality of extension headers that already has been standardised.

The Hop-by-Hop header is a container structure, it is able to hold a number of different options, for example

•Router Alert: warn the router that it should also interpret the content of the I.P.V.6 datagram, as it might make changes to the router state. Used for example by Multicast Listener Discovery (M.L.D) and the Resource Reservation Protocol (R.S.V.P,

•Jumbo-gram: the payload of the I.P.V.6 packet is bigger then 64kB ; the packet length is set in this additional header. Only useful on paths where every link supports a M.T.U greater than 64kB.

The Routing Header is used to list one or more intermediate nodes to be "visited" on the way to a packet's destination. Upon receiving the packet, each intermediate router in the list will process the routing header by swapping the destination address to the next router in the list. I.P.V.4 had a similar option, but it was never really used.

The Fragmentation Header contains the fields needed to perform fragmentation.

•With I.P.V.6 the content of a packet is split into a fragmentable part and an unfragmentable part

•The unfragmentable part contains the extension headers that have to be processed by the intermediate nodes, and should be repeated in each fragment.

Remark: fragmentation is no longer done by routers on the path, but only by the end nodes.

The A.H and E.S.P header are ipsec headers; this is explained in the Security chapter

The Destination Options Header is, just like the Hop-by-Hop header, a container header, which is able to hold multiple options. Depending on whether it is in front of the Routing header or not, it should be processed by the routers on the path, or only by the final destination. Mobile I.P.V.6 uses this extension for example to include the home address of a device.

The advantage of this architecture is that it is very flexible for developing new headers.

Outline

Addressing Scheme

The I.P.V.6 Header

I.C.M.Pv6 "Super" Protocol

– I.C.M.P.v.4 functions

– Neighbour Discovery (N.D)

– AutoConfiguration

– Path M.T.U Discovery

– … and more

I.P.V.4 and I.P.V.6

I.P.V.6 X-38 a.r.p, D.H.C.P, ... are separate protocols in I.P.V.4. I.P.V.6 defines the predecessors of all of these as subprotocols of the general I.C.M.Pv6 protocol – a “super” protocol.

Image summary: A diagram illustrating that ICMPv6 is a "super" protocol that incorporates the functions of several separate IPv4 protocols. On the left, a large vertical block labeled "ICMPv6 messages" maps to various functions including signaling, Address Resolution, Duplicate Address Detection (DAD), Address AutoConfiguration, Router+Prefix Detection, Neighbor Unreachability Detection (NUD), Multicast Listener Discovery (MLD), and Path MTU Discovery. On the right, corresponding separate IPv4 protocols are listed: ICMPv4 for signaling, ARP for Address Resolution, and DHCP for Address AutoConfiguration.

I.C.M.Pv6 still has the functionality that was included in I.C.M.P.v.4: reporting error conditions (Destination Unreachable, Packet Too Big, Time Exceeded), information conditions or diagnostic functions (Echo Request & Reply).

But I.C.M.Pv6 is much more powerful than I.C.M.P.v.4, and is used as transport protocol for the I.P.V.6 implementations of the functionality of Address Resolution and D.H.C.P, and for some new protocols that don't exist in I.P.V.4 (such as dad, N.L.D, M.L.D).

Discussing all of these protocols would be very elaborative; we will discuss the ones corresponding with a.r.p and D.H.C.P in I.P.V.4, starting with a.r.p.

Remark: A main difference between I.C.M.P.v.4 and I.C.M.Pv6 is that the latter can use the ipsec extension headers. Like this, I.C.M.Pv6 can use authentication and even encryption. Where firewalls often block I.C.M.P.v.4 messages, this allows I.C.M.Pv6 to work around firewalls when needed.

Other protocols such as Mobile I.P.V.6, Router Renumbering, Multicast Router Discovery (M.R.D), use I.C.M.Pv6 as a basis.

Address Resolution I.P.V.4 : a.r.p

- Goal of address resolution:

- – mapping between Layer 3 and Layer 2

- – Destination I.P address to Link-Layer (mac) address

• Recalling a.r.p for I.P.V.4:

- – 192.168.0.1 tries to resolve 192.168.0.2 ("what is mac address of 192.168.0.2 ?")

- — a.r.p request is broadcasted

Table summary: Networking header details showing an Ethernet Header with destination 00-08-B3-1E-83-29 and source 00-00-00-00-00-00-29, alongside an ARP Header with a target MAC of 00-00-00-00-00-00 and a target IP of 192.168.0.2.

— a.r.p reply is sent in unicast to src mac

Table summary: Network header information showing a correspondence between Ethernet and ARP layers. The Ethernet header lists a source MAC address of 00-11-2F-CF-76-78, while the ARP header identifies the sender MAC as 00-11-2F-CF-76-78 and the sender IP as 192.168.0.2.

I.P.V.6 X-40

In I.P.V.4, a.r.p or the Address Resolution Protocol is a separate protocol, not using I.C.M.P. It is the process that happens when a node wants to determine the link-layer of an interface for which it knows the I.P address.

a.r.p typically consists of two messages:

- The host who tries to find the mac address of a known I.P address, sends out an a.r.p request by broadcasting this to every node which is in the same broadcast domain.

- When a host has the I.P.V.4 address that is mentioned in the request, it sends an a.r.p reply containing his mac address to the sender of the broadcast packet. This response is unicast.

As each host frequently needs to resolve for example the address of its gateway, a.r.p broadcast on a network are not an exception. These frequent broadcasts however have a drawback.

a.r.p Broadcast : Inefficient

• a.r.p broadcast : interrupt each host

– Decision in application layer -> CPU!

Bad scalability

Image summary: A network diagram illustrating an Address Resolution Protocol (ARP) request and response process. A computer with IP 157.193.122.1 sends an ARP request to find the Ethernet address for IP 157.193.122.11. The request is broadcast across a shared network line to multiple devices: a printer with IP 157.193.122.10 and three computers with IPs 157.193.122.11, 157.193.122.12, and 157.193.122.15. Red arrows indicate the direction of the request and the resulting ARP decisions made by the receiving devices.

Although the a.r.p protocol has the advantage of being quite simple, the usage of broadcast messages interrupts all hosts on the network. a.r.p lacks scalability in larger Ethernet based networks – such as in most company environments.

a.r.p uses broadcasts to send an a.r.p Request to the broadcast address F.F:F.F:F.F:F.F:F.F, which is received by all stations on the local link. Although only one station—the one being queried—would need to respond, the other stations still have to process and discard the request. The a.r.p application is making this decision.

This interruption can cause problems on networks if the amount of broadcast traffic becomes excessive, especially for devices with small processing power (such as print servers or sensor nodes).

Regarding this problem from a T.C.P/I.P protocol stack perspective, we could say that the decision if the packet is intended for the host or not, is taken in the Application Layer, which is not the most efficient layer to detect if traffic is not for your own client.

Solicited-node multicast

I.P.V.6 Address Resolution : multicast

- — All-nodes : ff02::1 (~ broadcast): not preferred!

- Solicited-node multicast address a link-local scope multicast address that is computed as a function of the solicited target's address (the I.P.V.6 Unicast address) Prefix ff02::1:ff00:0/104 + last 24 bits of the unicast address => pseudo unicast multicast without interrupting all nodes

I.P.V.6 Unicast 2001:db8:1:0:20c:46ff:fe0e:8c6c

Solicited-node multicast: ff02::1:ff0e:8c6c

33:33:F.F:0E:8C:6C

In I.P.V.6, the broadcast functionality can be addressed by using the all-nodes multicast address: the link-local scope address to reach all nodes - ff02::1. However, a solution that does not interrupt all nodes would be preferred.

Therefore, a solicited-node multicast address is defined: a link-local scope multicast address that is computed as a function of the solicited target's address.

A Solicited-Node multicast address is formed by taking the low-order 24 bits of an address and appending those bits to the prefix ff02::1:ff00:0/104.

A solicited-node multicast address functions as a pseudo-unicast address: typically, your own node is the only one who has joined the multicast group. However, this group allows to perform Address Resolution based on multicast (next slide).

The multicast feature needs to be mapped to the data-link layer as well, to be able to bind. I.P.V.6 bound Ethernet multicast addresses always start with the sequence “33:33” (rfc2464). By appending the same low-order 32 bits, an Ethernet multicast address is linked to the solicited-node multicast address.

Using the complete 64bit I.I.D in a solicited-node address would not make sense, as on the current Ethernet layer only 48 bits are supported. Using the last 24 bits allows to use them both on the network and data-link layer.

The solicited-node address appends only the latter part of the I.P.V.6 address (24 bits), so addresses that differ only in the most significant bits, for example, a link-local and global address with the same I.I.D, will map to one and the same solicited-node address. This reduces the number of multicast addresses a node must join at the data-link layer.

This usage of multicast addresses on both the network and data-link layer allows to work without broadcast – but implies that both layers need to adopt to working with multicast.

– I.C.M.Pv6 multicast/unicast

– Neighbor Solicitation (N.S) message multicasted by A to Solicited-node multicast address (ff02::1:ff...)

using Ethernet multicast (33 to 33-)

Image summary: A technical diagram illustrating an IPv6 Neighbor Solicitation process. At the top, a packet structure shows nested headers: an Ethernet Header with destination 33-33-ff-0e-8c-6c, an IPv6 Header with destination ff02::1:ff0e:8c6c, an ICMPv6 Header, and a Neighbor Solicitation Header targeting fe80::20c:46ff:fe0e:8c6c. Below, two computers, A and B, are shown. Computer A, with IPv6 address fe80::20c:46ff:feb2:a5b0 and MAC address 00-0c-46-b2-a5-b0, sends a Neighbor Solicitation packet to find the MAC address of Computer B, which has IPv6 address fe80::20c:46ff:fe0e:8c6c and MAC address 00-0c-46-0e-8c-6c.

: Table summary: A network packet capture showing a Neighbor Solicitation request. The transmission originates from source MAC address 00-0c-46-b2-a5-b0 and source IPv6 address fe80::20c:46ff:feb2:a5b0. It is directed to destination MAC address 33-33-ff-0e-8c-6c and destination IPv6 address ff02::1:ff0e:8c6c, targeting the specific address fe80::20c:46ff:fe0e:8c6c via an ICMPv6 Neighbor Solicitation header.

The Address Resolution mechanism is using I.C.M.Pv6 in I.P.V.6, and is not a separate protocol. The solicited-node multicast address is used instead of broadcast.

Nodes accomplish Address Resolution by multicasting a Neighbor Solicitation (N.S) that asks the targeted node to return its link-layer address. As destination address, the N.S message uses the solicited-node multicast address of the target address. The target returns its link-layer address in a unicast Neighbor

Advertisement (N.A) message. The information learned is stored in a table called the Neighbor Cache – the I.P.V.6 version of the a.r.p table.

A single request-response pair of packets is sufficient for both the initiator and the target to resolve each other's link-layer addresses: the initiator includes its link-layer address in the Neighbor Solicitation, and the target stores this link-layer address in his own Neighbor Cache.

Including Address Resolution into I.C.M.Pv6 is a cleaner design compared to a.r.p(v4), because no separate Ethernet protocol number needs to be allocated. Furthermore, by moving a.r.p from Ethernet to I.P, we should be able to secure address resolution with ipsec when needed.

But is Address Resolution actually needed in I.P.V.6? I.P.V.6 addresses, where the host portion I.I.D is based on the E.U.I-64 format, contain all the bits of the layer 2 address - as the address is constructed from the mac address. Can we not directly deduct the mac address from the I.I.D?

Recall that not all I.P.V.6 addresses are based on E.U.I-64 formatting, for example because of a privacy hashed address (Microsoft), or a manually configured I.I.D. As the link-layer only sometimes can be deduced from the I.P.V.6 address, Address Resolution has been made mandatory.

– I.C.M.Pv6 multicast/unicast

– Neighbor Solicitation (N.S) message multicasted by A to Solicited-node multicast address (ff02::1:ff...)

IMPORTANT: a node has a solicited-node multicast address (L3) and an Ethernet (IPv6) multicast address (L2)

using Ethernet multicast (33 to 33-)

: Table summary: Network packet details for a Neighbor Solicitation request. The Ethernet header lists source address 00-0c-46-b2-a5-b0 and destination 33-33-ff-0e-8c-6c. The IPv6 header shows source fe80::20c:46ff:feb2:a5b0 and destination ff02::1:ff0e:8c6c. The packet contains an ICMPv6 header and a Neighbor Solicitation Header targeting fe80::20c:46ff:fe0e:8c6c.

– Neighbor Advertisement (N.A) replied in unicast by B

Table summary: A network packet consisting of an IPv6 Header with destination fe80::20c:46ff:feb2:a5b0 and source fe80::20c:46ff:fe0e:8c6c, an ICMPv6 Header, and a Neighbor Solicitation Header with target fe80::20c:46ff:fe0e:8c6c and mac address 00-0c-46-0e-8c-6c.

Ethernet Header dst: 00-0c-46-b2-a5-b0 src: 00-0c-46-0e-8c-6c

Image summary: A diagram illustrating a network communication process. An icon of a computer, labeled A, is associated with an IPv6 address (fe80::20c:46ff:feb2:a5b0) and a MAC address (00-0c-46-b2-a5-b0). Two vertical arrows indicate the flow of data, with a label identifying a Neighbor Solicitation message. This message specifies a destination address (dst: ff02::1:ff0e:8c6c) and a target address (target: fe80::20C:46ff:fe0e:8c6c).

Neighbor Solicitation dst: ff02::1:ff0e:8c6c target: fe80::20C:46ff:fe0e:8c6c fe80::20c:46ff:fe0e:8c6c

00-0c-46-0e-8c-6c

Neighbor Advertisement dst: fe80::20C:46ff:feb2:a5b0 link-layer: 00-0.C-46-0.E-8.C-6.C

[ Text continued from previous slide ]

ff02::1:ff0e:8c6c

33 to 33-ff-0e-8c-6c

A asks: who has mac address of B?

Note: In case the I.P.V.6 address is not based on E.U.I-64 formatting, the I.P.V.6 Ethernet multicast address may be programmed in the N.I.C based on the last 3 bytes of the I.P.V.6 address. Example: Ethernet address: 00-0c-46-0e-8c-6c, I.P.V.6 address: fe80::a00:20ff:fe18:964c (I.I.D is a hash of the Ethernet address), I.P.V.6 solicited node address: ff02::1:ff18:964c, Ethernet Multicast Address: 33 to 33-ff-18-96-4c (last 4 bytes based on I.P.V.6 solicited node address).

^{*} Modern Network Interface Cards (or N.I.C's) support programming of the Ethernet address (or Ethernet Multicast address).

Note: As described in (R.F.C.7042), 48-bit mac addresses (Ethernet) in the range 33-33-00-00-00-00 to 33 to 33-F.F-F.F-F.F-F.F are used for I.P.v 6 multicast.

Pseudo-unicast?

- – Solicited-node multicast address might not be unique -> last 24 bits identical by coincidence

- Both P.C B and P.C C receive the multicast N.S

- Only P.C B has a matching target I.P address -> only P.C B sends unicast reply

: Image summary: A network diagram illustrating IPv6 Neighbor Discovery Protocol communication between three computers, PC A, PC B, and PC C. PC A sends a Neighbor Solicitation message to a multicast address ff02::1:ff0e:8c6c, targeting the link-local address fe80::20C:46ff:fe0e:8c6c. PC B responds with a Neighbor Advertisement directed to PC A's link-local address fe80::020C:46ff:feb2:a5b0, including the link-layer address 00-0C-46-0E-8C-6C. Each PC is associated with specific IPv6 addresses shown above them.

In general, an I.P.V.6 node generates for each of his addresses a solicited-node multicast address, and hence joins this multicast group. In the example, only link-local I.P addresses have been assigned to the interfaces.

As only the last 24bits of an I.P.V.6 address are used to generate the multicast address, two network cards of different vendors with identical last 24 bits might generate the same solicited-node multicast address.

In this case, when computer A sends a Neighbor Solicitation message to the multicast group, both computer B and C accept the solicitation at the link-layer and network-layer addresses. Upon reception, the nodes look at the target in the N.S and hence only computer B will create a reply.

Computer C will also accept the frame on the data-link layer, but the I.P.V.6 network layer will discard this as there is no match with the I.C.M.Pv6 target.

To send a Neighbor Advertisement as reply, computer B is able to reply directly to computer A using the link-layer source address found in the first N.S packet, and use this as a destination address for his N.A (without initiating a new Address Resolution).

Image summary: A technical diagram comparing ICMPv6 messages to their IPv4 equivalents. The diagram lists several ICMPv6 functions on the left: signaling (time exceeded, ping), Address Resolution, Duplicate Address Detection (DAD), Address AutoConfiguration, Router+Prefix Detection, Neighbor Unreachability Detection (NUD), Multicast Listener Discovery (MLD), and Path MTU Discovery. On the right, corresponding IPv4 functions are shown, with ICMPv4 mapping to signaling, ARP mapping to Address Resolution, and DHCP mapping to both Address AutoConfiguration and Router+Prefix Detection. A red box specifically highlights the Duplicate Address Detection (DAD) function within the ICMPv6 list.

Nodes have the possibility and responsibility to generate their own I.I.D in I.P.V.6, based on their mac address (or using a hashed value of this mac). This offers the advantage that nodes can communicate without a central server managing the addresses, or static entries made by an administrator.

However, this comes with the responsibility of the nodes to avoid duplicate use of the address they have generated. Before an I.P.V.6 address is put in use, the I.P.V.6 node must verify its uniqueness.

The same I.C.M.Pv6 messages used in Address Translation can be used in a mechanism called Duplicate Address Translation (dad).

IPv6 X-46

Duplicate Address Detection (dad)

Node: Generate a New I.P.V.6 Address

- Unique address?

- – use Neighbor Solicitation to verify Responsibility of the node!

• Duplicate Address Detection (dad)

- Assign the address tentative

- Verify with Neighbor Solicitation (N.S) message

- – If address already in use, a Neighbor Advertisement (N.A) message will be replied by the other host => duplicate, no address configured

- Else,

- after time-out.

- tentative => preferred

I.P.V.6 X-47

A function called Duplicate Address Detection (dad) is included in I.C.M.Pv6 to check if nobody else is using the just generated address:

1. The I.P.V.6 node assigns the new I.P.V.6 address to its interface, but marks it as a tentative address, this means that it is not yet able to use it.

The node joins the corresponding Solicited-node multicast group, and also the all-nodes group ff02::1.

2. Just like in Address Resolution, it sends a Neighbor Solicitation message to this Solicited-node multicast address. As his address is tentative, hence not in use, the source address is set to the "unspecified address" (see below).

3. If there is no answer to the Neighbor Solicitation, after a certain time-out, it is safe to use the address.

The state of the address changes from “tentative” to “preferred”.

The unspecified address is a reserved address value that indicates the lack of an address (e.g., the address is unknown). It is never used as a destination address, but may be used as a source address if the sender does not (yet) know its own address.

The unspecified address has a value of 0:0:0:0:0:0:0 - or short noted “:”.

Image summary: A technical diagram illustrating IPv6 Duplicate Address Detection using a Wireshark packet capture and a network sketch. The top section shows a packet frame where a Neighbor Solicitation is sent from an unspecified source address (::) to a solicited-node multicast address (ff02::1:ff13:1210). Red annotations identify the destination address as the solicited-node multicast address and the target address (fe80::a07:8ff:fe13:1210) as the specific address being checked for duplicates. The bottom section shows two computers, PC A and PC B, with a blue arrow indicating a Neighbor Solicitation message sent from PC A, targeting the address fe80::A07:8ff:fe13:1210 to determine if it is tentative.

A node performing dad has been monitored using Wireshark, as depicted above. The following steps occur on host "P.C A".

1. The host generates a new link-local address. fe80::a07:8ff:fe13:1210. The address is marked tentative.

2.The host joins the multicast group ff02::1:ff13:1210; that is the Solicited-node multicast address, and also the all-nodes group.

3.A Neighbor Solicitation message is send to this Solicited-node multicast group. The neighbor solicitation message contains the new link-local address that the host wants to set as target. As the address isn't already used by any neighbor on the same link-local scope: there is no neighbor advertisement message as a reply to the neighbor solicitation.

4. After a time-out period, the I.P.V.6 address changes from tentative to preferred and the host can use the address.

Note that because the host doesn't have an address yet during the first three steps, the source address of the I.P packet is set to :: (i.e. the unspecified address).

The host uses the Solicited-node multicast address instead of the “all-nodes” multicast address: the latter would be too similar with broadcasting. The first normally interferes with no other node then itself – or a possible duplicate. Host “P.C B” never receives information about the check P.C A performed.

>• Image summary: A technical diagram illustrating the Duplicate Address Detection (DAD) process in IPv6. The top half shows a packet capture log with messages for

Again, a node performing dad has been monitored using Wireshark. However, the new node "P.C C" wants to assign the same link-local address as host "P.C A".

As another node (P.C A) is already using the address, this receiving node will reply with an Neighbor Advertisement packet. Because the source address of the N.S from “P.C C” was not specified, a unicast answer is not possible. Node “P.C C” doesn't have an I.P.V.6 address yet!

The reply from node "P.C A", a Neighbor Advertisement (N.A) I.C.M.Pv6, is sent to the All-nodes multicast address ff02::1. The originating node, although it doesn't have an address yet, is already member of this multicast group. On receipt of the N.A, the address is marked as a duplicate address, and will never be used.

Remark that host C remains without link-local address, and hence cannot communicate without an administrator solving the problem. The node does not have a mechanism that tries to recover after dad.

The all-nodes address ff02::1 is hence only used in the exception, and the amount of broadcast-like traffic is very small compared to I.P.V.4 a.r.p broadcasts.

The usage of a duplicate address might seem very rare. An I.I.D is calculated from the mac address, and should be unique as the mac address is unique. However, when using the privacy extension in an I.I.D, the hashed version could lead to an identical result, although with very small odd (1/2 superscript 64) .

A more realistic scenario happens when dealing with virtual mac addresses – for example from virtual computers. When duplicated, two Virtual Machines might have identical mac addresses – and I.P.V.6 dad will prevent further issues in the network layer.

Image summary: A diagram comparing ICMPv6 Neighbor Discovery Protocol (NDP) functions with corresponding IPv4 protocols. The chart lists various NDP message types, including Address Resolution, Duplicate Address Detection, Address AutoConfiguration, Router and Prefix Detection, Neighbor Unreachability Detection, Multicast Listener Discovery, and Path MTU Discovery. It highlights that Address AutoConfiguration and Router and Prefix Detection in IPv6 correspond to DHCP in IPv4, while Address Resolution in IPv6 corresponds to ARP in IPv4, and general ICMPv6 signaling corresponds to ICMPv4.

The definitions of Address Resolution and dad can be found in one standard, R.F.C.4861, called the Neighbor Discovery Protocol (N.D.P). This protocol replaces the functionality of a.r.p in I.P.V.4, and extends the usage to also allow Duplicate Address Detection.

I.P.V.6 nodes on the same link use N.D.P to learn about their Neighbors, but also use Neighbor Discovery to discover routers.

Discovering routers is described in the section “Router & Prefix Discovery” of N.D.P, and uses other I.C.M.Pv6 messages then before. Combined with AutoConfiguration (R.F.C.4862), it allows a mechanism that is the successor of D.H.C.P.v.4.

Neighbor Discovery Protocol

Neighbor Discovery Protocol (N.D.P)

– defines 5 types of I.C.M.Pv6 packets

1. Neighbor Solicitation (N.S)

2. Neighbor Advertisement (N.A)

3.

4.

Link-layer Address Resolution (similar to "a.r.p")

Duplicate I.P Address Detection (dad)

Router Solicitation (R.S)

Router Advertisement (R.A) Address AutoConfiguration Router Discovery

5. Redirect message

Global Addresses without D.H.C.P server

I.P.V.6 X-51

Neighbor Discovery defines five different I.C.M.P packet types: a pair of Router Solicitation and Router Advertisement messages, a pair of Neighbor Solicitation (N.S) and Neighbor Advertisements (N.A) messages, and a Redirect message.

N.S and N.A messages are used for Address Resolution and dad, as described in previous slides.

The Router Advertisement (R.A) message is only used by routers to advertise their presence together with various link and Internet parameters. This is done either periodically, or in response to a Router Solicitation (R.S) message (sent by a host). They are used for AutoConfiguration and Router Discovery.

The Redirection messages are sent by routers, to inform a node of a better first-hop node on the path to a given destination. It can also be used to inform the node that the destination is in fact a neighbor on the same link. Redirection will not further be elaborated (see I.C.M.P.v.4 redirect for a detailed mechanism), we will continue with the details of AutoConfiguration.

AutoConfiguration

AutoConfiguration:

- Nodes automatically generate link-local I.P.V.6 addresses

- No manual configuration!

- without central server (<> I.P.V.4 D.H.C.P server)

• Stateless AutoConfiguration

- Minimal router configuration

- Global addresses on nodes without host configuration

- No D.H.C.P like server needed!

• Stateless / Stateful D.H.C.P.v.6 After

AutoConfiguration

- – D.H.C.P.v.6 optional after Stateless AutoConf

- Providing more information: for example D.N.S server

- Explicitely set an I.P.V.6 address (optionally)

I.P.V.6 X-52

I.P.V.6 hosts can generate their own addresses, and automatically configure themselves to participate in the network in which they become active. In I.P.V.4, you should determine if an address is set statically or dynamically; in I.P.V.6 dynamic is the default option – called AutoConfiguration.

There are two ways to do AutoConfiguration of an I.P.V.6 address: stateless AutoConfiguration and stateful AutoConfiguration.

Allowing global addresses in I.P.V.6, doesn't always need a D.H.C.P.v.6 server. A router is sufficient to distribute global prefixes. Stateless AutoConfiguration is a mechanism that doesn't require servers dealing with I.P address assignment. It allows a host to create its I.P.V.6 address by using minimal information received from the router, and combining it with its own link layer address. The host doesn't need configuration; only the router needs to be configured with some minimal settings.

The most familiar method is Stateful AutoConfiguration, as it resembles the D.H.C.P.v.4 protocol. D.H.C.P.v.6 offers additional information to the I.P.V.6 hosts, such as the D.N.S server to use. But for certain applications D.H.C.P is to complicated (e.g. a remote control and television).

AutoConfiguration applies only to hosts, not to routers: routers should be configured in a different way (e.g. manually).

Autoconfiguration – step 1

:Image summary: A technical slide detailing Step 1 of generating an IPv6 link-local address. The process involves: serving as a prerequisite for router communication, generating an Interface Identifier (IID) using EUI-64 to create a tentative address, joining multicast groups such as all-nodes (ff02::01) and solicited-node, and performing Duplicate Address Detection (DAD) to transition a tentative address to a preferred address. The slide illustrates a network diagram with two computers and a router connected to a common line, showing a neighbor solicitation link-local message being sent from one computer. Examples of IPv6 addresses and a MAC address are listed, including fe80::A07:8ff:fe13:1210.

Step 1: generate a link-local address

- Pre-requisite to communicate with router: link-local!

- Generate I.I.D using E.U.I-64 -> tentative address

- Join multicast groups:

- all-nodes (ff02::01)

- solicited-node

- Perform dad (Duplicate Address Detection)

ff02::1 ff02::1:ff13:1210 tentative address -> preferred address fe80 double colon A.0.7 colon 8ff colon fe13 colon 1210

08:07:08:13:12:10

Before a host can use stateless or stateful AutoConfiguration, it needs to create a link-local address to start up communication with a router or a D.H.C.P.v.6 server. This first step includes...

1. First, the host generates a link-local address by using the E.U.I-64 format, based on his mac address. This address is marked as a tentative address.

2. The host joins two multicast groups: all-nodes (ff02::01) and the solicited-node multicast group, corresponding to the link-local address that was just generated.

3. Using these multicast addresses, dad for the tentative address can be performed by sending a Neighbor Solicitation. If someone would already be using this I.P.V.6 address, a Neighbor Advertisement would be received preventing the address to be used.

4. If the address is safe to use (no one responds to the N.S), the state of the address is updated to preferred.

The host can now use this link-local address to start communications with other nodes on the lan, and for example start stateless AutoConfiguration.

- Router Solicitation

:Image summary: A technical diagram illustrating the IPv6 address acquisition process. It lists three main steps: Router Solicitation to the all-routers multicast address ff02::2; Router replies with a Router Advertisement containing the network prefix and parameters to all-nodes ff02::1; and Global Address generation using the Prefix + Interface Identifier (IID), verified with Duplicate Address Detection (DAD). Below the text, a visual flow shows two computers and a router on a network line. The router sends a Router Advertisement with prefix 2001:db8:1::/64. A computer then generates a global address (2001:db8:1:0:A07:8ff:fe13:1210) and a link-local address (fe80::A07:8ff:fe13:1210), performing a DAD solicitation to verify the address.

- to all-routers multicast ff02::2

• Router replies with Router Advertisement

- – Network Prefix and parameters (M.T.U,...) but no D.N.S info

- Default R.A goes to all-nodes ff02::1

• Global Address

- Generate an I.P.V.6 address: Prefix + I.I.D

fe80 double colon A.0.7 colon 8ff colon fe13 colon 1210

Stateless AutoConfiguration allows a host to join the domain of a router, by using the prefix that the router announces on the network, without the need for an extra server.

Using his link-local address, a node may send out Router Solicitations that request routers to generate Router Advertisements. This process has the following steps:

1. The host sends a Router Solicitation to the all-routers multicast group ff02::2.

2. All routers on the link reply with a Router Advertisement (R.A) to the host – and actually to all hosts (ff02::1). This R.A contains a list of network prefixes, and other parameters of the router (default (Router Lifetime), M.T.U, Hop Limit, ...). A router may reply in unicast to the host, but commonly always sends R.A's to all.

3. The host generates an address, combining the prefix with the Interface I.D, for each prefix with the Autonomous Configuration flag set. Before using the address, the host verifies the uniqueness of the address with the dad procedure.

This process of sending an R.S speeds up the learning of link-local routers by triggering an R.A – sent to all nodes by default periodically.

Routers configured for stateless AutoConfiguration send, at a regular time interval, a Router Advertisement packet on the all-nodes multicast group (ff02::1), in order to advertise their presence, so the initial process is renewed automatically.

)-> Image summary: A technical diagram and packet capture analysis illustrating the second step of IPv6 stateless autoconfiguration. The top section shows a Wireshark packet capture log where a Router Solicitation (RS) message is sent from source address fe80::a07:8ff:fe13:1210 to the all-routers multicast destination address ff02::2 using the ICMPv6 protocol. A red arrow points from the destination address in the packet details to a text label stating "RS: to all-routers multicast address ff02::2". The bottom section provides a visual representation of this process, showing two computer icons sending Router Solicitation requests toward a router icon over a network line.

[ Text continued from previous slide ]

The Router Advertisement provides information to the attached host about preferred configuration parameters (host configuration parameters), and the prefixes that are used on this link (on-link prefixes). The Router Advertisement packet contains a number of fields:

• Prefix information that can be used on the link, and a lifetime for this prefix

• Router Lifetime: is this router to be used as a default router, or only for a short time

• Additional information, such as the M.T.U size to be used on the link or the hop limit

Further reading:

• tools dot ietf dot org U.R.L

• cisco dot com U.R.L issues/ipj 7 to 2/ipv6 autoconfig.html

Table summary: A sequence of networking events using the ICMPv6 protocol. The activity begins at time 0.000000 with a Neighbor Solicitation for fe80::a07:8ff sent from :: to ff02::1:ff13:1210, followed shortly after at 0.000025 by a Router Solicitation from 08:07:08:13:12 sent from fe80::a07:8ff:fe13:1210 to ff02::2. A later event at 14.139469 records a Router Advertisement from 00:15:77:5d:d sent from fe80::215:77ff:fe5d:d9a5 to ff02::1.

Frame 9: 110 bytes on wire (880 bits), 110 bytes captured (880 bits)

Image summary: A network packet analysis diagram displaying an IPv6 Router Advertisement message. The top portion shows a packet trace highlighting the source address as an implicit gateway and the destination as the all-nodes multicast address ff02::1. It identifies the prefix information 2001:db8:1::/64 used to construct a global address and notes the absence of DNS information. The bottom portion illustrates a network topology with two computer icons and a router icon connected to a shared bus, with the router broadcasting the 2001:db8:1::/64 prefix.

Ethernet 2, Src: AlliedTe 5d:d9:a5 (00:15:77:5d:d9:a5), Dst: ipv6mcast 00:00:00:01 (33:33:00:00:00:01)

The example in the previous and this slide illustrates the first two steps of AutoConfiguration in a Wireshark trace.

Step 1 in AutoConfiguration is generating a link-local address, and verify its uniqueness, as discussed in Duplicate Address Detection (frame #1).

In frame #2 we can see the node using this link-local address to send out a router solicitation to the all-routers multicast group ff02::2. A router replies (frame #9) using its local-link address. In this router advertisement, among other things, the router prefix is supplied.

A router advertisement (R.A) is always sent to the ff02::1 group: whenever a host triggers an R.A, it is multicasted to all nodes.

The client now can use this prefix and its I.I.D to generate a new global I.P.V.6 address. The next step would be to do dad again for this new address.

Image summary: A diagram illustrating step two of stateless IPv6 autoconfiguration using two command-line interface outputs. The top section shows an Ethernet adapter with only a link-local IPv6 address. A downward arrow points to the bottom section, where the adapter now includes a global IPv6 address and a default gateway, both highlighted in red boxes. The global address is labeled as the global address, and the default gateway is labeled as the sender address in a router advertisement.

After the second step in AutoConfiguration, the interface of our computer has a global I.P.V.6 address, next to the link-local address. The interface's default gateway is also set to the router that responded to our Router Solicitation request.

The default gateway is not a R.A option, but it is deduced from the source address from the R.A. As this was sent from the link-local address of the router, the default gateway on the host is represented by a link-local address (R.F.C 4861, 6.3.4).

Although we now have a global address and a gateway to connect to the I.P.V.6 Internet, a last part of configuration is needed: to be able to translate U.R.L's into I.P.V.6 addresses, we need a D.N.S server. As information regarding the address of a D.N.S server is not a part of router advertisements, we need an extra step to be fully configured.

Autoconfiguration – Step 3-D.H.C.P?

- D.H.C.P.v.6

- Step 2: If Router Advertisement in step 2 sets flag -> there is a D.H.C.P.v.6 server

- Step 3: Contact D.H.C.P.v.6 server on multicast ff02::1:2

• D.H.C.P.v.6 Can Provide...

- Additional information (e.g. D.N.S, N.T.P) next to stateless address

- Additional information and address

fe80 double colon A.0.7 colon 8ff colon fe13 colon 1210 (e.g. not based on E.U.I-64 I.I.D)

Image summary: A network diagram illustrating a DHCPv6 configuration process. A computer on the left sends a Contact DHCPv6 server request on an IPv6 X-58 network. A router on the right responds with a Router Advertisement containing a flag directing the client to use DHCPv6.

Where D.H.C.P.v.4 used broadcast messages to find out who the servers were, D.H.C.P.v.6 makes use of multicast messages:

1. First the host sends a Router Solicitation to the all-routers multicast group (ff02::2), as in stateless configuration. A Router Advertisement is received.

2. When one of the flags is set, the host then tries to contact the D.H.C.P server on the All_D.H.C.P_Relay_Agents_and Servers multicast address: ff 0 2 double colon 1 colon 2

Depending on the type of Router Advertisement, the client either acquires an I.P.V.6 address and configuration info using the D.H.C.P.v.6 protocol, or asks only configuration information using the D.H.C.P.v.6 protocol.

Remark that options as D.N.S and N.T.P can be delivered by the D.H.C.P server; the default gateway however must be learned using stateless AutoConfiguration. Stateful AutoConfiguration always needs Stateless AutoConf first.

D.H.C.P.v.6 – Stateless vs Stateful

D.H.C.P.v.6

Step 2: If Router Advertisement in step 2 sets flag -> there is a D.H.C.P.v.6 server

Step 3: Contact D.H.C.P.v.6 server on multicast ff02::1:2

• D.H.C.P.v.6 can provide...

Image summary: A diagram illustrating the capabilities of DHCPv6. It shows two categories, Stateless DHCPv6 and Stateful DHCPv6. Stateless DHCPv6 is linked by a line to a list of provided services: additional information like DNS and NTP next to a stateless address, and additional information and address inclusive of those not based on EUI-64 IID.

Additional information (e.g. D.N.S, N.T.P) next to stateless address

Additional information and address

Stateless D.H.C.P.v.6 (e.g. not based on E.U.I-64 I.I.D)

Stateful D.H.C.P.v.6

I.P.V.6 X-59

Depending on the type of Router Advertisement, the client either acquires an I.P.V.6 address and configuration info using the D.H.C.P.v.6 protocol, or asks only configuration information using the D.H.C.P.v.6 protocol.

A Router Advertisement has a field called the Managed flag (M flag). When set, addresses are available via D.H.C.P.v.6.

It also contains the O flag: Other Configuration. It indicates that other configuration information (e.g. D.N.S) is available via D.H.C.P.v.6, except the address (which was already obtained stateless).

Both flags can be set by the routers R.A's independently from one another.

Where stateless AutoConfiguration allows every node access to the network, D.H.C.P.v.6 allows admission control policies.

D.H.C.P.v.6 is defined in R.F.C 3315 An example of stateful AutoConfiguration – a third step after stateless autoconf - is depicted in the Wireshark trace above. Some non-relevant frames have been filtered out.

: Table summary: A sequence of network packets for stateful autoconfiguration. The process begins with ICMPv6 Neighbor and Router solicitations and advertisements within the first 15 milliseconds. This is followed by a DHCPv6 handshake starting at approximately 31 seconds, consisting of a solicit, advertise, request, and reply exchange between fe80: a07:8ff:fe13:1210 and fe80:215:77ff:fe5d:d9a5. The sequence concludes at 31.49 seconds with another ICMPv6 Neighbor solicitation.

When the managed flag is set in a router advertisement (R.A), the client uses D.H.C.P.v.6 to obtain an address and other information - such as D.N.S servers.

1. In D.H.C.P.v.6, the client first sends a D.H.C.P.v.6 Solicit message (frame #17) to the multicast group ff02::1:2 (All_D.H.C.P_Relay_Agents_and Servers). Possibly, multiple D.H.C.P servers could reply.

2. The D.H.C.P server responds to the client using his link-local address. The response is a D.H.C.P.v.6 Advertise message (frame #18).

3.The client then requests an I.P.V.6 address from this D.H.C.P server: a D.H.C.P.v.6 Request message (frame #19). Again, this is sent to the multicast address of the server, also informing possible other D.H.C.P.v.6 servers.

4. The D.H.C.P server replies with a D.H.C.P.v.6 Reply message (frame #20), containing an assigned I.P.V.6 address for the host, and the D.N.S servers to be used. These details are indicated in the figure.

The steps are very similar to the well known D.H.C.P(v4).

Autoconfiguration – step 3-stateful

Connection-specific D.N.S Suffix : I.P.V.6 Address ..... : 2001:db8:1:0:a07:8ff:fe13:1210 Link-local I.P.V.6 Address ..... : fe80::a07:8ff:fe13:1210:x10 Default Gateway ..... : fe80::215:77ff:fe5d:d9a5x10

Ethernet adapter eth1:

Connection-specific D.N.S Suffix : example dot com

I.P.V.6 Address: 2001:db8:1:0:a02:8ff:fe13:1210

I.P.V.6 Address: 2001:db8:2:0:66ad:d578:4c5:cd34

Link-local I.P.V.6 Address: fe80:a07:8ff:fe13:1210x10

Default Gateway: fe80:215:27ff:fe5d:d9a5x10

D.N.S Servers: 2001:db8:2::1

I.P.V.6 X-61

In the first configuration, we can see the Ethernet adapter (eth1) already had addresses obtained from stateless AutoConfiguration, and a link-local address. Windows also use a temporary I.P.V.6 address obtained from stateless AutoConfiguration for security reasons. See also: technet dot microsoft dot com U.R.L).aspx

After restarting the router, now with the M flag set, stateful configuration is the default. Afterwards the Ethernet adapter has an extra address obtained from the D.H.C.P.v.6 server. It also received the address of a D.N.S server.

As I.P.V.6 is still in transition, also the definitions are changing. D.N.S servers for a long time were presumed reachable using a multicast address (like routers and possible D.H.C.P servers). Therefore, they were not an option in stateless AutoConfiguration. However, as D.N.S servers in current definitions are not multicast per say, one would be obliged to use stateful AutoConf to find a suitable D.N.S server address.

slaac with D.N.S?

- Not including D.N.S as an option in R.A / slaac = historical error

• Repaired as of 2017 in R.F.C 8106

• If both R.A and D.H.C.P based D.N.S: the I.P.V.6 host Should keep some D.N.S options from all sources

I.P.V.6 X-62

Not providing D.N.S as an option in a Router Advertisement (R.A) has proven to be a historical error in the design of I.P.V.6. As the mechanism had been standardized (and implemented in many first version of Operating Systems), it was not altered that easily.

However, as of 2017, Router Advertisements have been expanded to also include D.N.S as an option. The intention is to enable the full configuration of basic networking information for hosts without requiring D.H.C.P.v.6.

More information: R.F.C 8106 With I.P.V.6, nodes are required to keep track of active and reachable connections. Neighbor Unreachability Detection detects the failure of a neighbor or the failure of the forward path to the neighbor. Doing so requires positive confirmation that packets sent to a neighbor are actually reaching that neighbor and being processed properly by its I.P layer. N.U.D is specified in R.F.C 4861, section-7.3

Image summary: A diagram comparing ICMPv6 messages to their counterparts in IPv4. ICMPv6 signaling maps to ICMPv4, Address Resolution (NDP) maps to ARP, and Address AutoConfiguration and Router+Prefix Detection map to DHCP. A red box encompasses Neighbor Unreachability Detection (NUD), Multicast Listener Discovery (MLD), and Path MTU Discovery, labeled as Not Discussed.

I.P.V.4 knows a protocol that manages multicast group memberships, called the Internet Group Management Protocol (I.G.M.P). As I.P.V.6 uses multicast much more than I.P.V.4, this I.G.M.P protocol has been incorporated into I.C.M.Pv6: M.L.D. I.P.V.6 routers use this Multicast Listening Discovery (M.L.D) to know which multicast addresses have listeners on each link, and hence which multicast traffic they should be forwarding or not. The current definitions of M.L.D.v.2 (version 2) can be found in R.F.C.3810.

When an I.P.V.6 node joins a multicast group (e.g. when it adapts a new I.P.V.6 address), it must send out a Listener Report indicating the join. In M.L.D.v.2, the destination is ff02::16, a multicast address all routers are required to listen on. If the node does not have a valid address yet, it can use the unspecified address (::) as a source address.

In general, Multicast Listener Reports are sent by I.P nodes to report (to neighboring routers) the current multicast listening state, or changes in the multicast listening state, of their interfaces. If the node leaves the group, it must send out a Listener Report again indicating the change.

The details of these two protocols would take us further then an introduction into I.P.V.6.

A last definition in I.C.M.Pv6 defines that I.P.V.6 nodes should implement Path M.T.U Discovery in order to discover and take advantage of best P.M.T.U that can be found along the path. This P.M.T.U is discovered by using I.C.M.Pv6 Packet Too Big messages.

Les 20+21: laatste 50 min

Path M.T.U Discovery

- P.M.T.U adapted instead of fragmentation

- – “smallest link” == P.M.T.U of your connection

- – Find the P.M.T.U greater than min. M.T.U (1280 B)

P.M.T.U Discovery Process:

- >– Try with the M.T.U of first hop link M.T.U 1

- Link i with M.T.U i less than M.T.U 1

- => router i sends I.C.M.Pv6 Packet Too Big

- => contains M.T.U

- – Resend new packet with M.T.U

- Repeat until destination reached

I.P.V.6 X-64

I.P.V.6 requires that every link in the internet has a minimum M.T.U of 1280 bytes. However, if all the links along the path support a bigger M.T.U, but these are not equal for every link of the path, how can a node know the optimal M.T.U for the path? The optimal Path M.T.U can be discovered, as described in R.F.C.1981.

A host assumes that the Path M.T.U is the same as the M.T.U of the first hop link and it uses that size. If the packet is too big for a certain router along the path to deliver the packet to the next link, the router discards the packet and sends back an I.C.M.Pv6 Packet Too Big message to the host. This message type includes the M.T.U size of the next hop link.

This new Path M.T.U is stored, with the destination, in the Destination Cache.

The host now uses this M.T.U for sending a first (and further) packets to the same destination. The process of receiving a Packet Too Big message and reducing the size of the packets can happen more than once before the packet reaches its destination. The discovery process ends when the packets arrive at the final destination.

The path from a given source to a given destination can change, and so can the Path M.T.U. Smaller M.T.U sizes are discovered by getting Packet Too Big messages. An I.P.V.6 host will try to increase the M.T.U size from time to time in order to be able to detect a larger Path M.T.U

However, a common issue in the Internet is that firewalls tend to block all I.C.M.P traffic, hence preventing the forwarding of I.C.M.Pv6 Packet Too Big messages. As a result, packets which cannot travel a certain link, keep on being sent without the P.M.T.U being adapted. This is known as black holes – as described in R.F.C.2923.

An extension to I.C.M.Pv6 based P.M.T.U has been defined in R.F.C.4821 to address this.

Outline

Addressing Scheme

The I.P.V.6 Header

I.C.M.Pv6 "Super" Protocol

I.P.V.4 and I.P.V.6

Dual-stack networks

– D.N.S for I.P.V.6

Transition mechanisms

I.P.V.6 X-65 - Use I.P.V.4 and I.P.V.6

- – I.P.V.4 and I.P.V.6 I.S.P's

- Packet to I.P.V.4: use your I.P.V.4 address

I.P.V.6/v4 network

Table summary: A single network transmission from source IP 157.193.214.191 to destination IP 209.85.227.103, containing a TCP payload for HTTP www.google.com.

• Local: I.P.V.6 next to I.P.V.4

:Table summary: A single network transmission record from source 2001:db8:1:0:208:b3ff:fe1e:8329 to destination 2a00:1450:8003::69, consisting of a TCP HTTP payload for ipv6.google.com.

When all nodes in your local network are both I.P.V.4 and I.P.V.6 capable, one can just enable I.P.V.6. By adding an I.P.V.6 router in the existing I.P.V.4 local network, stateless AutoConfiguration will provide all nodes with the prefix of the router its I.P.V.6 connection. In most cases, this implies upgrading the existing router to also support I.P.V.6, next to current I.P.V.4 operations. Most routers are already I.P.V.6 capable – but it's simply not enabled.

With I.P.V.4 also still active, this scenario is called Dual Stack. When a host wants to communicate with an I.P.V.6 node, it behaves like an I.P.V.6-node. In communication with an I.P.V.4 node, it behaves like an I.P.V.4 node.

Of course, the same upgrade operation needs to be supported by the I.S.P connection your Local network uses to connect to the Internet: a dual stack I.S.P can connect you to servers who are also Dual stack server, or are I.P.V.6 only.

All recent operating systems have Dual Stack turned on by default: Windows Vista and 7, Linux, Mac O.S X. Dual Stack are described in R.F.C 4213.

- Allows to incrementally introduce I.P.V.6 in already existing networks

IPv4 & IPv6 LAN

2a00:1450:8003::69

IPv6 X-66

।Figure X-65 summary: A network diagram illustrating connectivity between devices and two different internet environments. At the top, a computer is identified by MAC address 00-08-b3-1e-83-29, IPv4 address 157.193.214.191, and two IPv6 addresses: fe80::208:b3ff:fe1e:8329 and 2001:db8:1:0:208:b3ff:fe1e:8329. This device connects through a switch and routers to an IPv6/v4 Internet containing a server with IP 209.85.227.103, as well as to a separate IPv6 Internet containing a server with address 2a00:1450:8003::69.

• Challenges:

- All applications should be I.P.V.4 and I.P.V.6 compliant

- – I.P.V.6 support from your I.S.P

- All tables have to be maintained twice: routing table, firewall, ...

Modern hybrid dual-stack implementations of I.P.V.4 and I.P.V.6 allow programmers to write networking code that works transparently on I.P.V.4 or I.P.V.6. The software may use hybrid sockets designed to accept both I.P.V.4 and I.P.V.6 packets.

However, just turning it on is not a trivial job:

•Not all software has been written to be I.P.V.6 compliant or being capable of working with hybrid stacks. Some software (e.g. old F.T.P servers) might not work on I.P.V.6/I.P.V.4 nodes.

•Next to software binaries, a lot of developed configurations might depend on the I.P.V.4 address. E.g. databases might track your I.P address, and if the field to store this information is only 32bits... it is I.P.V.6 incompatible.

Next to software development, also network design and configuration should be revised completely:

•You can enable I.P.V.6 within your local network, but as long as your I.S.P doesn't support I.P.V.6, dual stack doesn't allow you to connect to other I.P.V.6 networks – or the I.P.V.6 Internet

•A disadvantage is that everything has to be configured and maintained twice. Next to more overhead, this might lead to not-matching configurations and possible security issues. E.g. the firewall rules for I.P.V.4 and I.P.V.6 might have different configurations, allowing certain traffic in the I.P.V.6 range which wasn't allowed in the I.P.V.4 range before.

।Figure X-67 summary: A diagram illustrating a Dual Stack network architecture. At the top, an IPv4/IPv6 Application connects to both TCP and UDP transport layers. These transport layers, in turn, connect to both an IPv4 and an IPv6 network layer. The IPv4 layer connects to the Ethernet layer with Protocol ID 0x0800, and the IPv6 layer connects to the Ethernet layer with Protocol ID 0x86DD.

D.N.S and I.P.V.6: A.A.A.A Record

D.N.S Extended With a New Resource Record Type: A.A.A.A

Similar to A record in I.P.V.4

– Dual stack D.N.S server: both A and A.A.A.A record

E.g. forward zone file iMinds.be

iminds dot be. in A 193.191.148.35 ; I.P.V.4 in A.A.A.A 2001:6a8:1d80:21::35 ; I.P.V.6

Extra Reverse D.N.S Zone for I.P.V.6:

193.191.148.0 -> iminds.be ; original reverse I.P.V.4

2001:6a8:1d80:21:: -> iminds.be ; new reverse I.P.V.6 zone

I.P.V.6 X-68

Allowing I.P.V.6 connections in your network allows client-server communication, but most applications use server names instead of addresses. The D.N.S system, linking names and addresses, needs to be adopted to I.P.V.6 as well.

In I.P.V.4, a D.N.S record of type A is defined to map a hostname to an I.P.V.4 address. To add support for I.P.V.6 addresses a new D.N.S record type, {A.A.A.A} , has been defined for I.P.V.6 hosts (R.F.C 3596).

An A.A.A.A record is similar to an A record, but maps the U.R.L also to an I.P.V.6 address.

A dual stack host will have usually both an A and A.A.A.A record defined in D.N.S. However, it is possible for an I.P.V.6 supporting D.N.S server to only have an A.A.A.A record. New entries in I.P.V.6 only domains don't have an I.P.V.4 address anymore, for example in Asia this is already often the case as I.P.V.4 is completed in that region.

In order to support reverse D.N.S lookups, to determine the domain name associated with a certain I.P address, a new reverse zone is needed. Next to having a reverse zone for the already used I.P.V.4 range of addresses, an extra zone is needed to map the new I.P.V.6 range to the same D.N.S domain.

In I.P.V.4, the in-addr.arpa zone is used for reverse mappings. In I.P.V.6, these are called ip6.arpa zones.

D.N.S server: I.P.V.4 or I.P.V.6

• A or A.A.A.A : application layer

Transport layer: U.D.P

Network layer: I.P.V.4 or I.P.V.6

=> A.A.A.A record can be queried over I.P.V.4 or I.P.V.6

Image summary: A network diagram illustrating a dual-stack DNS server that communicates with three different clients. The DNS server is located within a yellow cloud labeled Dual stack IPv4/IPv6. It connects via IPv4 to a Client IPv4 in a blue cloud, via IPv6 to a Client IPv6 in another blue cloud, and via either IPv4 or IPv6 to a Client IPv4/IPv6 located within the same yellow cloud.

D.N.S communication between a host and a D.N.S server consists of requests and responses, containing A or A.A.A.A records in the application layer.

The U.D.P protocol is used at the transport layer, regardless of the underlying network layer protocol that is used: I.P.V.4 or I.P.V.6.

Regarding the network layer, in the I.P.V.4 only world, a D.N.S server only had an I.P.V.4 address. Obviously, I.P.V.6 only hosts have no knowledge of I.P.V.4 addresses, so it is indispensable for a dual stack D.N.S server to also have an I.P.V.6 address if they want to support I.P.V.6 clients.

From both worlds, I.P.V.4 clients will request A records via I.P.V.4, and I.P.V.6 clients will request A.A.A.A records via I.P.V.6.

Dual stack clients can either choose to communicate with the D.N.S server via I.P.V.4 or I.P.V.6. Remark that it is eligible for a dual stack client to request an A record over I.P.V.6, or to request an A.A.A.A records over I.P.V.4.

Remark: when a dual stack host has both an I.P.V.4 and I.P.V.6 address configured for the D.N.S server, the order in which they are configured will determine whether the host will contact the D.N.S server via I.P.V.4 or I.P.V.6. If the I.P.V.4 D.N.S server is primary, and the I.P.V.6 secondary, I.P.V.4 will be used for queries. There is no preference for I.P.V.6.

Code summary: DNS: Request AAAA demonstrates a DNS lookup using the dig tool to resolve the domain www.iminds.be. The process sends a query for a AAAA record to the default DNS server at 157.193.214.2 to retrieve the associated IPv6 address, resulting in the resolution of 2001:6a8:1d80:21::35.

Command line tools like nslookup or dig are supporting dual stack operations, and A.A.A.A requests can be forced, as shown in the example.

The D.N.S server with I.P.V.4 address 157.193.214.2 is contacted over I.P.V.4 (in our client, only an I.P.V.4 address for the D.N.S server was configured), but only asks for A.A.A.A records.

An A.A.A.A request for the U.R.L 'iminds dot be' is done over I.P.V.4. An A.A.A.A response is returned, implying that the U.R.L already has a corresponding I.P.V.6 address: 2001:6a8:1d80:21::35.

Dual Stack Host: D.N.S Resolver

- Dual stack host: D.N.S resolver should be able to handle both A and A.A.A.A records

- Dual stack resolver sends both an A and A.A.A.A request for U.R.L in parallel (*)

- Both A and A.A.A.A responses are received

- – Resolver can choose protocol to use, or let application make the choice

- – When both A and A.A.A.A response is received,

generally I.P.V.6 is preferred

Asterisk Some O.S/apps send in sequence, and not in parallel

I.P.V.6 X-71

Every host has a resolver that handles the name resolution. In a dual stack host, the resolver should both support A and A.A.A.A request and responses, and domain names are resolved by sending both A and A.A.A.A requests to the D.N.S server. The A and A.A.A.A requests in general are sent in parallel. However, as I.P.V.6 is still in development, there are O.S's and applications that send them in sequence.

Applications normally use hostnames when setting up connections. From an application point of view, name resolution is a system-independent process. Applications call functions in a system library (the resolver), typically getaddrinfo() (or gethostbyname(). (R.F.C.3493))

In dual stack hosts, the resolver will usually return a list of addresses (possibly both I.P.V.4 and I.P.V.6) in a certain order*. It is then up to the application to select which addresses are tried and in which order. Normally, I.P.V.6 is preferred (R.F.C.3484). However, the algorithm that is described in the R.F.C takes into account several parameters, such as unreachable addresses, matching scope, avoid deprecated addresses, prefer home address...The algorithm is rather complex, but if a global I.P.V.6 address is available, it is preferred above I.P.V.4.

$ ^{*} $ Note that it still possible that an application specifically asks for an IPv4 or IPv6 address.

Dual stack resolving: example

Image summary: A technical diagram illustrating the DNS resolution process for a dual stack client attempting to connect to www.google.com. The sequence shows the client sending both an A request and an AAAA request to a DNS server. The server responds with an IPv4 address (173.194.78.106) and an IPv6 address (2a00:1450:400c:c00::68). The resolver returns both addresses to the client, prioritizing the IPv6 address on top. Consequently, the application connects using the first available address, initiating an HTTP connection over IPv6.

An example of interaction between application and a D.N.S resolver is illustrated above.

A dual stack client wants to surf to google dot com. So the browser will ask the resolver to do name resolution for the U.R.L.

The resolver sends out {A and A.A.A.A} requests in parallel. For this U.R.L, both an A and A.A.A.A record exist and are returned to the host. The resolver will now return a list of both the addresses to the application, and it will order them. I.P.V.6 is preferred in this case, so first the I.P.V.6 address and then the I.P.V.4 address.

The application still has the choice to use I.P.V.4 or I.P.V.6, but here it will respect the order and first tries the I.P.V.6 address. A connection can be established to this I.P.V.6 address, and the browser will surf via I.P.V.6 to the resolved U.R.L.

: Table summary: An outline of topics covering IPv6, starting with its addressing scheme, the IPv6 header, and the ICMPv6 super protocol. It also addresses the relationship between IPv4 and IPv6, including transition mechanisms such as tunneling and translation techniques, and discusses practical considerations regarding ISP IPv6 enablement and the continued need for global IPv4 addresses.

I.P.V.6 X-73

)-> Image summary: A technical diagram explaining IPv6 tunneling. The diagram shows an IPv6/v4 network connected to an IPv4-only Internet, which then connects to an IPv6 Internet. A packet structure illustration at the bottom shows an IPv6 packet (containing IPv6 source and destination and TCP/UDP payload) being encapsulated as the payload within an IPv4 packet (with its own IPv4 source and destination). Text highlights that tunneling occurs when an ISP does not support IPv6, allowing IPv6 packets to be transported as payloads within IPv4 packets across an existing IPv4 network.

Transition: Tunneling

- Tunneling

- – I.S.P doesn't support I.P.V.6.

- – I.P.V.4 packets as before

- Tunnel interconnection using existing I.P.V.4 network

- – I.P.V.6 packet becomes payload of I.P.V.4 packet

Payload = entire I.P.V.6 packet

- Example protocols:

- – 6to4 tunneling

- Teredo

2a00:1450:8003::69

More and more deprecated as native I.P.V.6 becomes dominant I.P.V.6 X-74

When you enable I.P.V.6 in your own network, next to your I.P.V.4 addresses, the problem might arise that the I.S.P providing your uplink does not (yet) support I.P.V.6. In order to reach the I.P.V.6 Internet, an isolated host or network can use the existing I.P.V.4 infrastructure to carry I.P.V.6 packets as a payload.

This is done using a technique known as tunneling which consists of encapsulating I.P.V.6 packets within I.P.V.4, in effect using I.P.V.4 as a link layer for I.P.V.6. As the new network does not have a direct connection to the I.P.V.6 Internet, it is often called an I.P.V.6 island.

Tunneling allows you to migrate to I.P.V.6 just the way you like, because no specific upgrade order needs to be followed in your complete infrastructure:

- You could enable I.P.V.6 in certain parts of the network while the backbone is still I.P.V.4. The I.P.V.6 islands would be connected with tunnels.

- Tunneling mechanisms can be used to deploy an I.P.V.6 forwarding infrastructure while the overall I.P.V.4 infrastructure is still the basis and either should not or cannot be modified or upgraded.

A common used protocol to encapsulate I.P.V.6 directly into I.P.V.4 packets is 6to4 (see next slide). This direct encapsulation of I.P.V.6 datagrams within I.P.V.4 packets is indicated by I.P protocol number 41.

Of course, one needs an I.P.V.4 end point to which a tunnel can be set up. Multiple relay routers supporting I.P.V.6 tunnels are available on the Internet; to avoid the (re)distribution of such a list of possible endpoints, an I.P.V.4 anycast address has been created: 192.88.99.1

I.P.V.6 can also be encapsulated within U.D.P packets for example in order to cross a router or nat device that blocks protocol 41 traffic. A common used protocol operating like this is the Teredo protocol. Due to its complexity, Teredo will not be further elaborated.

Transition: Translation

- Translation

- – Your lan is I.P.V.6 only

- Tunnel to I.P.V.6 (or direct link) but how to reach I.P.V.4?

- nat-like translation solution: I.P.V.6 payload becomes payload of I.P.V.4 packet

Image summary: A network diagram illustrating the connection between different network protocols. An IPv6 only network, containing a computer and a router, connects via an intermediate router to an IPv4 only Internet, which contains a server with the IP address 209.85.227.103. The IPv4 only Internet is further connected through another router to an IPv6 Internet, which contains a server with the IP address 2a00:1450:8003::69.

Table summary: A mapping of network traffic components where the first row associates IPv6 SRC and IPv6 DST with TCP or UDP and a payload, and the second row relates IPv4 SRC and IPv4 DST to a payload termed IPv6 payload.

- Drawbacks

- Scalability

- – No one-on-one mapping of all features of I.P.V.6 (e.g. I.C.M.P.v.4<>I.C.M.Pv6, extensions headers, multicast)

I.P.V.6 X-75

In addition to tunneling, {translation} mechanisms have been defined. The goal is to provide transparent routing for nodes in the I.P.V.6 network to communicate with nodes in the I.P.V.4 Internet, and vice versa.

The mechanism for going from I.P.V.6 to I.P.V.4 is not trivial, but is similar to the nat mechanism in I.P.V.4. The protocol translator uses a pool of public I.P.V.4 address for assignment to I.P.V.6 nodes. Compared to tunneling, not the entire I.P.V.6 packet is encapsulated in an I.P.V.4 packet, but only the payload is put into an I.P.V.4 packet. However, a binding between I.P.V.6 and used I.P.V.4 addresses needs to be organised. Going from I.P.V.4 to I.P.V.6 is rather simple: the protocol translator removes the I.P.V.4 header and replaces it with an I.P.V.6 header.

Next to translating the I.P address, we also need to translate U.R.L's between the I.P.V.6 and I.P.V.4 domain. An additional D.N.S Application Layer Gateway (A.L.G) is needed: U.R.L's leading to I.P.V.4 only addresses will be bound to a translation I.P.V.6 address of the local network (see next slide).

Translation has the huge advantage, that it allows you set up a new I.P.V.6-only network (without updating your existing network to dual stack), and also provides connectivity to the already existing I.P.V.4 network (which tunneling can not provide). However, as with nat, only a limited number of hosts can be supported. Furthermore, basic protocols allow translation through N.A.T.6.4, like a basic HTTP/T.C.P request. Some payloads or I.P.V.6 features however can't be simply translated:

The really hard thing is the translation of I.C.M.P.v.4 and I.C.M.Pv6 messages.

• I.P.V.4 options and I.P.V.6 extension headers are not translated.

• Translation cannot be used for multicast traffic: there is no mapping between I.P.V.4/I.P.V.6 multicast addresses

Image summary: A sequence diagram and network architecture illustration explaining the NAT64 and DNS64 translation process. The diagram depicts an IPv6-only client querying a DNS64 server, which interacts with a regular DNS server to translate an IPv4 address into an IPv6 address using the well-known NAT64 prefix 64:ff9b::/96. The process shows the DNS64 server receiving an A record for minerva.ugent.be and returning an AAAA record to the client, facilitating communication between an IPv6-only network and the IPv4-only internet via a NAT64 gateway.

Suppose a client has only I.P.V.6 connectivity, and wants to reach a server on the I.P.V.4 Internet only (U.R.L minerva.ugent.be), which doesn't have an I.P.V.6 address. The only host connected to the I.P.V.4 internet is the N.A.T.6.4 gateway, which also works as a D.N.S.6.4 server.

The first task to tackle is resolving the U.R.L of the I.P.V.4-server into an I.P.V.6-like address. Just using the I.P.V.4 address is not an option, as our client is I.P.V.6 only.

The client will send out a D.N.S query for the A.A.A.A record of the U.R.L. This query is received by the D.N.S.6.4 local resolver, which by default forwards this as a regular A.A.A.A query to a regular D.N.S server (e.g. of an I.S.P). As the U.R.L minerva.ugent.be only has a corresponding A record, the response will be empty.

The D.N.S.6.4 service will then re-query the D.N.S server for the A record. The corresponding I.P.V.4 address is sent back. As the client has requested an A.A.A.A record, the D.N.S.6.4 will generate a fake A.A.A.A record, 64:ff9b::157.193.43.9, consisting of the following two elements:

a N.A.T.6.4 specific I.P.V.6 prefix 64:ff9b::/96, called “the Well-Known N.A.T.6.4 Prefix” the I.P.V.4 address of the destination, appended to this prefix. Note that this part can be simply written in I.P.V.4 format dot-decimal notation.

The client has now received a valid result for its D.N.S query, A.A.A.A which he can understand – although there isn't a real corresponding I.P.V.6 address.

The "Well-Known N.A.T.6.4 Prefix" is configured by the network administrator on the D.N.S.6.4 server, and needs to correspond with the settings of the N.A.T.6.4 router.

[ Remark that we presume that the D.N.S 64 server is able to communicate with a regular D.N.S server in the Internet: an I.P.v 6 capable D.N.S server, or by using nat 64 as explained on the next slide for D.N.S communication.]

Image summary: A technical diagram illustrating the translation process between IPv6 and IPv4 using NAT64 and DNS64. The flow begins with an IPv6 Client sending a DNS query for minerva.ugent.be, which is processed by DNS64 and NAT64. The DNS64 server synthesizes an IPv6 address (64:ff9b::157.193.43.9) from the IPv4 address (157.193.43.9) of the target IPv4 Server. A NAT64 binding entry is created, mapping an IPv6 address and port to the IPv4 address 157.193.215.195:1026. The final communication path shows TCP traffic moving from an IPv6-only network, through a NAT64 gateway, into an IPv4-only Internet to reach the server at 157.193.43.9.

The well-known prefix 64:ff9b:: is not routed towards the I.P.V.6 Internet, but sent directly to the N.A.T.6.4 service on a gateway. A first I.P.V.6 packet, arriving at this gateway, will be translated into an I.P.V.4 packet. The I.P.V.4 packet contains the original payload – but without I.P.V.6 headers.

When changing the source address, the N.A.T.6.4 gateway will allocate a N.A.T.6.4 binding, linking the original I.P.V.6 address and port number of the client to a public I.P.V.4 address of the outside interface of the gateway, for example 157.193.215.195, and a chosen port number on the I.P.V.4 side (as in I.P.V.4 nat).

The I.P.V.4 destination address was embedded into the I.P.V.6 gateway, so a binding isn't necessary.

Returning packets will arrive at the N.A.T.6.4 gateway. As each I.P.V.6 client is mapped to his own I.P.V.4 address/port, the gateway can now transform the packet again to its I.P.V.6 equivalent and forward the resulting packet to the I.P.V.6 client. The operation is quite similar to traditional nat.

Every I.P.V.6 client will get a one-to-one mapping of its I.P.V.6 address to an I.P.V.4 address + port number, so the technique cannot be applied to large I.P.V.6 networks without sufficient I.P.V.4 addresses. The same limitations of nat are still applicable.

This solution provides the possibility for an I.P.V.6 host to connect to an I.P.V.4 server, which is not yet I.P.V.6 capable. The other way round is of course not possible: there are not enough I.P.V.4 addresses to make one-on-one fixed translations to make the entire I.P.V.6 Internet available to I.P.V.4.

>(Image summary: A technical diagram illustrating IPv6-IPv4 mapped communication via NAT64. The top portion shows a packet capture log with protocols including DNS, TCP, and HTTP, detailing a request to minerva.ugent.be and the subsequent IP address resolution. The bottom schematic depicts an IPv6-only network connected to an IPv4-only Internet through a NAT64 gateway, which translates an IPv6 address (2002:9d1:d7c3:0:e990:b28f:f0e:1912) to an IPv4 address (157.193.215.195).)}} Optics: The image depicts a network translation process from an IPv6-only network to an IPv4-only Internet using NAT64, supported by a packet capture log showing the DNS and HTTP traffic involved in reaching the host minerva.ugent.be.

The interworking of D.N.S.6.4 and N.A.T.6.4 is depicted in the trace above.

The client tries to contact the minerva.ugent.be website, which is not I.P.V.6 enabled. The reply of the D.N.S.6.4 resolver (frame #2) contains the I.P.V.6 address 64:ff9b::9dc1:2b09, which consists of the Well-Known Prefix and the I.P.V.4 address in hex notation (original 157.193.43.9).

Using this I.P.V.6 address 64:ff9b::9dc1:2b09, the client can setup a T.C.P connection with the Minerva website, although this website is not I.P.V.6 capable. The conversation (in the I.P.V.6 domain) is depicted in frames #3 to #12.

The Well-Known Prefix is defined in R.F.C.6146, containing all details on N.A.T.6.4 and D.N.S.6.4.

Remark: the Well-Known Prefix is not used in every D.N.S.6.4/N.A.T.6.4 setup; sometimes a /64 prefix is chosen within the allocated I.P.V.6 range of the organization, which is not yet in use. This is then dedicated to N.A.T.6.4, because these packets need to be sent directly to the N.A.T.6.4 gateway for processing – and not directly to the I.P.V.6 Internet.

When the company has a /48 prefix: 2001:db8:1::/48, and 2001:db8:1::/64 is used as the clients network, for example 2001:db8:1:0064::/64 can be used for N.A.T.6.4.