Computer network technologies and services/IPv6

Internet Protocol version 6 (IPv6) is a new protocol aimed to overcome IPv4 limits: the main reason for introducing a new protocol is to have a larger address space with respect to the IPv4 one.

Comparison to IPv4

IPv6 expands ICMP protocol by integrating the following protocols:

• ARP: called 'neighbor discovery' for address configuration process;
• IGMP: called 'Multicast Listener Discovery' to manage multicast group memberships.

With IPv6 some protocols need just to be upgraded, mainly due to the fact that they all deal with addresses (these protocols are not layer-3 independent):

• DNS protocols;
• routing protocols: RIP, OSPF, BGP, IDRP;
• transport protocols: TCP, UDP;
• socket interfaces.

IPv6 additional features

The additional features listed below were originally designed as add-ons for IPv4, then they were ported to be embedded into IPv6.

Deployment on LANs

It is more efficient, thanks to an efficient usage of multicast and anycast addresses:

• multicast: each multicast address identifies a group of stations, and the packet is forwarded to all the nodes in the group;
• anycast: each anycast address identifies a group of stations, but the packet is forwarded just to the closest node in the group.

Data security and privacy

Security mechanisms such as IPsec are included in the IPv6 protocol.

Policy routing

It is the possibility to forward packets by using policies different than the destination address (e.g. forwarding by source address).

Plug and play

Autoconfiguration protocols are defined:

• stateless: only link-local access is guaranteed without contacting any server;
• stateful: it is possible to have access to the Internet by using a DHCP server.

Traffic differentiation

Not all data flows are equal (e.g. phone calls require less delays).

Mobility

It is the capability of moving the device across different networks while keeping available all services (e.g. mobile devices that use GSM/LTE moving around different cells).

Nomadicity

It is the capability of moving the device across different networks without needing to grant the services active → less strict than mobility.

Better scalability with routing

As a general rule aggregation is required to make routing easier but it requires a waste of addresses. IPv6 routing uses almost the same techniques as IPv4 but it can reduce the routing tables, if the addresses are given in an efficient way.

Addressing

Address format

Each IPv6 address is 128-bit-long, and the prefix replaces the netmask:

prefix

interface identifier

Links

The concept of link in IPv6 is the same as the concept of subnetwork in IPv4:

• in IPv4 a subnetwork is a set of hosts with the same prefix;
• in IPv6 a link is the actual physical network.

All the hosts in the same subnetwork belong to the same link and vice versa:

• on-link hosts have the same prefix, so they can communicate directly;
• off-link hosts have different prefixes, so they can communicate through a router.

Addressing space organization

Global unicast addresses

Aggregatable global unicast addresses

They are equivalent to the IPv4 public addresses, and they begin with the three bits '001':

3	16	48	64	88	96	104	128
001	ID TLA	ID NLA	ID SLA	OUI ('universal' bit = 1)	FF	FE	manufacturer-selected MAC portion
prefix				interface identifier (EUI 64)

• Prefix: it must be the same as the one assigned to the link which the host is connected to.

Assignment criterion for prefixes is topology-based: they are assigned according to the service provider hierarchy:

• Top Level Authority (TLA): a large service provider;
• Next Level Authority (NLA): an intermediate service provider;
• Subnet Level Authority (SLA): the organization.

• Interface identifier: it identifies the host interface.

Optionally it can be in EUI-64 format: the 64-bit IPv6 interface identifier derives from the host's 48-bit MAC address:

24	48
OUI ('universal' bit = 0)	manufacturer-selected MAC portion

where the 'universal' bit is the seventh bit in the OUI and it is changed from 0 to 1.

Addresses for IPv4 interoperability

They are to be used during the transition phase, and they begin with 80 bits set to zero:

• IPv4-mapped addresses: the first 80 bits are zeros and the next 16 bits are set to one:

0000

0000

0000

0000

0000

FFFF

...

• IPv4-compatible addresses: the first 80 bits are zeros and the next 16 bits are set to zero (e.g. the IPv6 address '::10.0.0.1' maps the IPv4 address '10.0.0.1'):

0000

0000

0000

0000

0000

0000

...

Local unicast addresses

Link local addresses

They refer to the 'automatic' private addresses, generated by autoconfiguration, which is the process where a station automatically generates an address to connect to an IPv6 link:

FExx

...

Site local addresses

They are equivalent to the IPv4 private addresses:

FDxx

...

Multicast addresses

A multicast address identifies a group of stations and it has the following format:

8	12	16	128
FF	Flag (000T)	Scope	Group ID

where the fields are:

• Flag field (4 bits): it is used to mark a multicast group:
  • T = 1: the multicast group is temporary (e.g. user-defined conference call);
  • T = 0: the multicast group is permanent (e.g. address of all the hosts in the network, it can not be overwritten);
• Scope field (4 bits): it is used to limit the diffusion of the multicast (better than IPv4 TTL):
  • 1 = node local: the packet can not go outside the host;
  • 2 = link local: the packet can not go outside the layer 2 network;
  • 5 = site local: the packet can not go outside e.g. the campus network;
  • 8 = organization local: the packet can not go outside the organization network;
  • E = global: the packet can go everywhere;
• Group ID field (112 bits): it identifies the multicast group, and the packet is forwarded to all the nodes in the group.

If a host wants to belong to a multicast group, it needs to ask for it by using the ICMP protocol; once it is added to the multicast group, it will receive all the packets sent to that particular multicast address. It is very important to notice that the hosts that will receive a multicast packet are not defined by the source, but they are 'decided' by the destinations.

Solicited node multicast addresses

Every operating node by default belongs to a solicited node multicast group whose address derives from its IPv6 address:

96	104	128
FF02::1	FF	24 least significant bits from the IPv6 address

There may be more than one host in the same multicast group, but generally there are not since the multicast address is generated from the IPv6 address.

Mapping IPv6 over Ethernet

Each multicast packet is delivered through an Ethernet frame with a specific MAC address derived from the IPv6 multicast address, so that the packet is processed just by the interested hosts:

16	48
3333	32 least significant bits from the target IPv6 address

Advanced topics related to IPv6 addresses

Renumbering

As the prefixes for global addresses are assigned according to the service provider hierarchy, if a company wants to change from a service provider to another one, all the links in the company network will have to change their prefixes. IPv6 is meant to support easy renumbering for both hosts and routers:

• hosts: routers gradually stop advertising the old prefix (deprecated) and start advertising the new one (preferred) → each host will have during the migration phase two addresses with different prefixes for the same interface;
• routers: Router Renumbering is a standard which allows the border router to notify the other internal routers of the new prefix.

However renumbering still has some unsolved problems, related to how to automatically update e.g. the DNS entries, firewall filters, address-based corporate policies, etc.

Multi-homing

A big company may decide to buy Internet connectivity from two different service providers because it wants to keep being connected to the Internet even if one of the service providers has some problems.

As the prefixes for global addresses are assigned according to the service provider hierarchy, each host inside the company network will have two global addresses with different prefixes for the same interface → the host will have to select which address to use for every outcoming packet. This may cause some non-trivial configuration problems:

• routing based on destination address: the host should be able to select the right prefix for outcoming packets, otherwise let us suppose the host selects the provider A's prefix but the destination is in the provider B's network → the border router thanks to its routing mechanisms will forward the packet directly into the provider B's network → the provider B will block that packet because the source address has a different prefix;
• double registration in DNSes: the host should be registered in DNSes by two different addresses for the same alias;
• automatic renumbering: renumbering mechanisms should dynamically support a change from a provider B to a provider C.

Scoped addresses

A host can have two interfaces (e.g. an Ethernet interface and a wi-fi one) which can be connected to two different links at the same time. When the host wants to send a packet to a link local target address, it does not know whether to make the packet exit the interface A or the interface B, because both the links have the same prefix; moreover, as each link local address is unique within its link, a host in the link A may have the same link local address as another host in the link B.

In IPv6 the host needs to specify in the target IPv6 address an identifier called scope which is used to identify the physical interface (e.g. FE80::0237:00FF:FE02:A7FD%19). The values for the scopes are selected by the operating system according to its internal criteria.

Standard IPv6 header

The standard IPv6 header has the following fixed-size (40 bytes) format:

4	12	16	24	32
Version (6)	Priority	Flow label
Payload length			Next header	Hop limit
Source
address
Destination
address

where the most significant fields are:

• Version field (4 bits): it is not really used, because the packet discrimination is made by the layer 2 → this enables the dual-stack approach ( Computer network technologies and services/Migration to IPv6#Migrating operating systems);
• Priority field (8 bits): equivalent to the IPv4 'Type of Service' field, it allows to distinguish different kinds of services for quality of service ( Computer network technologies and services/Quality of service#Architecture);
• Flow label field (20 bits): it allows to distinguish different flows for quality of service;
• Next header field (8 bits): it refers to the packet payload, that is a header at upper layer (e.g. TCP/UDP) or the first extension header in the chain ( #Extension headers);
• Hop limit field (8 bits): it is equivalent to the IPv4 'Time To Live' field;
• Source address field (128 bits): it contains the sender's IPv6 source address for the packet;
• Destination address field (128 bits): it contains the addressee's IPv6 destination address for the packet.

Some IPv4 fields have been removed:

• Checksum field: error protection is delegated to layer 2 (frame check sequence);
• Fragmentation field: fragmentation is delegated to the 'Fragment' extension header;
• Header length field: IPv6 header is fixed-size, as additional features are optionally offered by extension headers.

Extension headers

There are six extension headers, added only when needed and processed in the following order:

1. Hop by hop option: it includes optional information to be processed by every hop;
2. Routing: it enables source routing, that is the source decides which route the packet needs to take;
3. Fragment: it manages fragmentation;
4. Authentication Header (AH): it allows to authenticate the sender;
5. Encapsulating Security Payload (ESP): it allows to encrypt the packet contents;
6. Destination option: it includes optional information to be processed just by the destination.

Routers always process only up to the 'Routing' extension header.

All the extension headers have the same generic format (the length must be a multiple of 64 bits):

8	16	32
Next Header	Header Length
Extension data :::

where the fields are:

• Next Header field: it specifies the following extension header in the chain, or the header at upper layer (e.g. TCP/UDP) if this is the last extension header;
• Header Length field: it specifies the length of the current extension header.

As new extension headers can be standardized over time, old devices may not be able to process recent extension headers → they can look at the 'Length' field to skip the unknown extension header.

The 'Header Length' field may be not in some extension headers (such as the 'Fragment' extension header) which the IPv6 standard defines as having fixed length.

Hop by hop option and Destination option

The Hop by hop option and Destination option extension headers can include multiple additional options:

• Hop by hop option: it includes options which every router the packet goes through has to process;
• Destination option: it includes options which just the destination has to process.

For example, if there are two options with 8-bit-long values, the extension header will have the following format:

8	16	24	32
Next Header	Header Length	Type1	Length
Value1	Type2	Length2	Value2

where each option always has the three following fields:

• Length field (8 bits): it specifies the length of the current option, so that routers unable to recognize the option can just skip it;
• Type field (8 bits): it identifies the current option.

The first two bits always specify the action to be executed in case the option is not recognized, while the third bit specifies whether the option can be changed on-the-fly:

• 00 = the current option can be ignored and it is possible to proceed to the next one;
• 01 = the packet must be discarded;
• 10 = the packet must be discarded and an ICMPv6 Parameter Problem must be generated;
• 11 = the packet must be discarded and an ICMPv6 Parameter Problem must be generated, unless the destination address is a multicast one;
• xx0 = the option can not be changed;
• xx1 = the option can be changed on-the-fly;

• Value field (variable length): it contains the value of the option.

Routing

The Routing extension header allows the source to decide decides which route the packet needs to take (source routing), and it has the following format:

8	16	24	32
Next Header	Header Length	Routing Type	Segment Left
(reserved)
Router
Address 1
...
Router
Address N

where the fields are:

• Routing Type field (8 bits): it specifies the type of routing (currently '0' for classical source routing);
• Segment Left field (8 bits): it specifies the number of remaining hops to the destination;
• Router Address fields (128 bits each one): they are the list of the IPv6 addresses of the routers which the packet should go through.

Example of usage for the 'Routing' extension header.

In the example in the side figure, source S sends the packet towards destination D, adding a 'Routing' extension header which forces the packet to go through intermediate routers R1 and R2. So at first the packet apparently has router R1 as destination, while real destination D is specified as last step in the router list specified by the 'Routing' extension header. When the packet arrives at router R1, this recognizes it as apparently addressed to it; in fact, its address appears in the 'Destination Address' field in the IPv6 header. Router R1 checks the next headers and it discovers the packet contains a 'Routing' extension header, realizing that the final destination for the packet is another host (in particular the 'Segment Left' field says that two hops should be traversed before arriving at the final destination). Router R1 finds the IPv6 address of the next hop to which it should send the packet and replaces it with its IPv6 address, then it sends the packet with destination set to R2. The process will continue hop by hop, until destination D will receive an IPv6 packet whose 'Routing' extension header contains the 'Segment Left' field set to 0, which means that the packet has reached the final destination. Destination D is able to know all the hops the packet passed through because they are all written in the 'Routing' extension header, so it can forward the reply to source S by specifying the same (reversed) list of hops.

Fragment

The Fragment extension header allows to send a packet in smaller parts called 'fragments', and it has the following format:

8	16	29	31	32
Next Header	(reserved)	Fragment Offset	(reserved)	M
Identification

where the fields are:

• Fragment Offset field (13 bits): it specifies the byte number at which the fragment starts within the fragmented section in the original packet;
• More Fragments (M) flag (1 bit): if it is set to 0 the current packet is the last fragment;
• Identification field (32 bits): all the fragments of a specific packet have the same identifier.

Each packets includes two sections:

• a section that can not be fragmented, so it is repeated in all fragments: it includes the IPv6 header and all the extension headers preceding the 'Fragment' extension header;
• a section that can be fragmented: it includes all the extension headers following the 'Fragment' extension header and the packet payload.

Example of usage for the 'Fragment' extension header.

In contrast to IPv4, only the sender node is allowed to fragment the datagrams, while IPv6 routers do not support fragmentation. Moreover, the IPv6 standard strongly suggests to use Path MTU Discovery instead of fragmentation for performance reasons: #Packet Too Big.

IPsec

The solutions developed for IPv6 have been ported from IPv4-IPsec protocol suite. In IPv6 IPSec is an integrated protocol suite that defines two headers:

• Authentication Header (AH): it authenticates the whole packet, but the fields which are changed on passing from one hop to another (e.g. 'Hop limit' field), by guaranteeing that no one has tempered the contents of the packet;
• Encapsulating Security Payload (ESP): it authenticates and encrypts the packet payload for data privacy.

SA

IPsec does not define which algorithms are to be used for encryption and authentication, but the two parties have to agree on which ones to use for exchanging IPsec-protected information → flexibility: algorithms are chosen according to the current needs.

A Security Association (SA) can be defined as the set of agreements between two parties A and B on the private keys and algorithms to be used for ESP authentication and encryption and AH authentication. Each SA is identified by an identification tag called Security Parameter Index (SPI), included in the AH and ESP headers, and it is a one-way logical channel: A and B have to open a SA to agree on keys and algorithms for messages going from A to B, and they have to open another SA to agree on them for messages going from B to A. Often a SA is opened for each TCP port.

IKE

How can A and B agree on secrete keys avoiding that extraneous people know them? There are three main strategies:

• static configuration: the keys are configured manually in A and B → key negotiation is not required at all;
• Diffie-Hellman method: it allows to agree on a key without exchanging it → nobody can discover the secret keys by sniffing the traffic between A and B;
• Internet Key Exchange (IKE) protocol: it uses digital certificates and asymmetrical cryptography to send secret keys in a secure way.

The IKE protocol specifies that an IKE SA has to be established from A to B to agree on the secret keys for the child SA from A to B, and vice versa another one for the child SA from B to A. The IKE SA from A to B consists of the following operations based on asymmetrical cryptography:

1. B asks A for a secret key to be used for the child SA from A to B;
2. A asks a trusty certification authority for B's digital certificate, in order to know if B is really who he is telling to be;
3. the certification authority provides A with B's digital certificate, encrypted by using the certification authority's private key, containing B's signature, that is the association between B and a public key;
4. A decrypts the digital certificate by using the certification authority's public key and learns the public key associated to B;
5. A sends the secret key for the child SA to B, encrypting the message by using the public key associated to B so that it can be decrypted only by knowing B's private key;
6. B receives the message from A, decrypts it by using its private key and learns the secret key decided by A for the child SA;
7. the child SA using the agreed secret key can be opened from A to B.

Some extraneous people may look at the traffic exchanged between A and B and guess the secret keys after a while, by performing brute-force attacks or analyzing some deduced statistical information. Internet Security Association Key Management Protocol (ISAKMP) is a sub-protocol of IKE to periodically renegotiate the secret keys in a secure way, so that extraneous people do not have time to guess them.

AH

The Authentication Header (AH) guarantees connectionless integrity and data origin authentication for IP packets: it authenticates the \ul{whole packet}, but the fields which are changed on passing from one hop to another (e.g. 'Hop limit' field), by guaranteeing that no one has tempered the contents of the packet.

AH has problems dealing with NATs, because it also authenticates the addresses and the ports.

Key concept: no one can change the packet, everyone can read it.

The Authentication Header has the following format:

8	16	32
Next Header	Payload Length	(reserved)
SPI
Sequence Number
Authentication Data :::

where the fields are:

• Next Header field (8 bits): it specifies the next encapsulated protocol;
• Payload Length field (8 bits): it specifies the Authentication Header length in 32-bit words − 2 (it may be cleared to zero);
• Security Parameters Index (SPI) field (32 bits): it identifies the Security Association for this datagram (if cleared to zero, a Security Association does not exist; values in the range 1 to 255 are reserved);
• Sequence Number field (32 bits): it contains a monotonically increasing counter value;
• Message Digest field (variable length): it summarizes the contents of the packet by using a secret key: everyone who wants to change the contents of the packet has to know the key in order to recompute the message digest (similar to the error detection field).

ESP

The Encapsulating Security Payload (ESP) header provides origin authenticity, integrity and confidentiality protection for IP packets: it authenticates and encrypts the packet payload for data privacy.

Though ESP can authenticate, it does not perform the same functionality of AH: ESP does not authenticate the whole IPv6 packet.

Key concept: no one can read the packet, therefore no one can change it.

The ESP header is always the last one in the header chain and it has the following format:

16	24	32
SPI				authenticated
Sequence Number
Payload Data :::			encrypted
Padding :::
	Payload Length	Next Header
Authentication Data :::

where the fields are:

• Security Parameters Index (SPI) field (32 bits): it identifies the Security Association for this datagram;
• Sequence Number field (unsigned 32 bits): it contains a monotonically increasing counter value.

The 'Sequence Number' field is mandatory for the sender and it is always present even if the receiver does not select to enable the anti-replay service for a specific SA, but processing of this field is at the discretion of the receiver;

• Payload Data field (variable length): it contains the data described by the 'Next header' field;
• Padding field (variable length 0 to 255 bits): padding may be required, irrespective of encryption algorithm requirements, to ensure that the resulting ciphertext terminates on a 4-byte boundary;
• Padding Length field (8 bits): it specifies the size of the 'Padding' field (in bytes);
• Next Header field (8 bits): an IPv4/IPv6 protocol number describing the format of the 'Payload Data' field;
• Authentication Data field (variable length): it contains an Integrity Check Value (ICV) computed over the ESP packet minus the 'Authentication Data' field.

The 'Authentication Data' field length is specified by the selected authentication function. The 'Authentication Data' field is optional: it is included only if the authentication service has been selected for the SA at issue. The authentication algorithm specification must specify the ICV length and the comparison rules and processing steps for validation. Note that the 'Authentication Data' field is not encrypted.

Two usage modes are possible for ESP (optionally in combination with AH):

• transport mode: ESP does not encrypt the IPv6 header → anybody in the middle is able to see the source and destination IP addresses in the IPv6 header:

IPv6 header	other extension headers	ESP header (for encryption)	TCP/UDP header	payload	ESP authentication
			encrypted data
		authenticated data

• tunnel mode: the IPv6 packet is encapsulated into another IPv6 packet having ESP → the IPv6 header of the original packet, containing the source and destination IP addresses, is encrypted and nobody can see it:

IPv6 header	ESP header (for encryption)	IPv6 header	other extension headers	TCP/UDP header	payload	ESP authentication
		encrypted data
	authenticated data

ICMPv6

Internet Control Message Protocol version 6 (ICMPv6) is an integral part of the IPv6 standard, and it in turn integrates the functionalities of ARP and IGMP protocols expanding them.

All the ICMPv6 messages are put just after the extension headers in the packet, and they have the same generic format:

8	16	32
Type	Code	Checksum
Message Body :::

where the 'Type' field identifies the type of ICMPv6 message:

• diagnostics messages: like in ICMPv4, they allow to report errors or problems in the network:
  • 1 = Destination Unreachable
  • 2 = Packet Too Big
  • 3 = Time Exceeded
  • 4 = Parameter Problem
• messages used by the ping command:
  • 128 = Echo Request
  • 129 = Echo Reply
• Multicast Listener Discovery messages: they expand the IGMP functionality:
  • 130 = Multicast Listener Query
  • 131 = Multicast Listener Report
  • 132 = Multicast Listener Done
• Neighbor Discovery messages: they expand the ARP functionality:
  • 133 = Router Solicitation
  • 134 = Router Advertisement
  • 135 = Neighbor Solicitation
  • 136 = Neighbor Advertisement
  • 137 = Redirect

Packet Too Big

When a router receives a packet having a too large size, it performs a technique called Path MTU Discovery: it discards the packet and sends back an ICMPv6 message of type Packet Too Big in order to notify the sender of the allowed Maximum Transmission Unit (MTU) size and force it to send again the packet itself (and the next packets) with a size not exceeding the MTU specified by the router. This technique has the goal to avoid fragmentation as much as possible.

Multicast Listener Discovery

Multicast Listener Discovery is the component in ICMPv6 which expands the functionality of the IPv4 IGMP protocol to manage multicast group memberships:

• Multicast Listener Query:
  • General Query: the router asks hosts if they are interested in joining some of multicast groups;
  • Multicast Address Specific Query: the router asks hosts if they are interested in joining a particular multicast group;
• Multicast Listener Report: the host notifies the router it wants to join a particular multicast group to receive all the multicast packets addressed to the multicast address corresponding to the specified multicast group;
• Multicast Listener Done: the host notifies the router it wants to stop receiving the multicast packets for a particular multicast group.

Neighbor Discovery

Neighbor Discovery is the component in ICMPv6 which expands the functionality of the IPv4 ARP protocol:

• Neighbor Solicitation: the host sends a multicast packet having, as the target IPv6 address, the solicited node multicast address corresponding to the IPv6 address of which it wants to learn the MAC address;
• Neighbor Advertisement: the host having the specified IPv6 address sends back its MAC address;
• Router Solicitation: the host sends a multicast packet to solicit the router sending back a 'Router Advertisement' message containing details for the given network (as Prefix associated to the Link, flag of autoconfiguration/DHCP, default device);
• Router Advertisement: the router advertises its presence within the link reporting the prefix(es) associated to the link and a flag which states if the hosts should auto-configure themself or query a DHCP server.

'Neighbor Discovery' ICMPv6 messages are used to autoconfigure the IPv6 addresses for a host connecting to a link: firstly the host has to get a link local address in order to be able to contact the other hosts within the link, then it has to get a global address in order to be able to exit the link and access the Internet by a globally unique address.

Link local address autoconfiguration process

The link local address is autoconfigured by using 'Neighbor Solicitation' and 'Neighbor Advertisement' ICMPv6 messages:

1. the host generates by itself an IPv6 address candidate to be its link local address:
   • prefix: it is always 'FE80::';
   • interface identifier: it can be generated either based on MAC address (EUI-64 format) or randomly for privacy reasons (traceability);
2. the host sends via multicast a 'Neighbor Solicitation' message to the Multicast Solicited Node corresponding to the candidate linklocal address chosen, specifying as target IPv6 address its self-generated address and asking if a host whose link local address is the same as the specified IPv6 address exists in the link (Duplicated Address Detection);
3. if a host having the sender's link local address already exists in the link, it sends back a 'Neighbor Advertisement' message to the sender, which will have to generate randomly another candidate address and send via multicast another 'Neighbor Solicitation' message;
4. if no one replies, the address is unique within the link and the host is able to contact every other host within the same link by using its link local address, but it is not able to access the Internet yet because it needs a global address.

Global address autoconfiguration process

The global address is autoconfigured by using 'Router Solicitation', 'Router Advertisement', 'Neighbor Solicitation' and 'Neighbor Advertisement' ICMPv6 messages:

1. the host sends via multicast a 'Router Solicitation' message to solicit the router sending back a 'Router Advertisement' message containing the interface identifier associated to the link;
2. the router sends back a 'Router Advertisement' message containing the two flags 'Managed Address Configuration' (M) and 'Other configuration' (O):
   • M = 1: the host has to contact the DHCP server for the prefix of the link and the other network configuration parameters (such as the DNS address), without caring of 'Router Advertisement' messages from the router (stateful configuration);
   • M = 0: the host has to look at the 'O' flag:
     • O = 1: the host can take the prefix of the link from the 'Router Advertisement' message, but it still has to contact the DHCP server for the other network configuration parameters (such as the DNS address);
     • O = 0: the host can take the prefix of the link from the 'Router Advertisement' message, and no other configuration information is available from the DHCP server (stateless configuration) → either the other network configuration parameters (such as the DNS address) will have to be configured by hand on the host, or the host can get the DNS address via IPv4 ( Computer network technologies and services/Migration to IPv6#Migrating DNSes);
3. the host generates by itself an IPv6 address candidate to be its global address:
   • prefix: it is equal to the prefix of the link, taken either from the 'Router Advertisement' message or by contacting the DHCP server;
   • interface identifier: it can be generated either based on MAC address (EUI-64 format) or randomly for privacy reasons (traceability);
4. the host sends via multicast a 'Neighbor Solicitation' message to all the hosts within the link, specifying as target IPv6 address its self-generated address and asking if a host whose global address is the same as the specified IPv6 address exists in the link (Duplicated Address Detection);
5. if a host having the sender's global address already exists in the link, it sends back a 'Neighbor Advertisement' message to the sender, which will have to generate randomly another candidate address and send via multicast another 'Neighbor Solicitation' message;
6. if no one replies, the address is globally unique and the host is able to access the Internet by using its global address.

Another implementation proposed by Microsoft consists in the possibility for the host to contact the DNS server without knowing its address: the host sends packets to a fixed anycast address, and the network takes care of delivering the packet to the DNS server. However this implementation is not really used:

• implementations for anycast address management are rare;
• this solution is not supported by GNU/Linux operating system.

Autoconfiguration is based on the MAC address, so if the network card breaks and needs to be replaced the host will have to change its address, but the caches (e.g. the DNS cache) can not update immediately → static configuration is still possible, especially for fixed machines (e.g. servers for public websites) which need to avoid changing their addresses in order to keep being reachable as much continuously as possible.