Almost this entire page may be a large result of various copy-and-paste from internal notes made earlier. Much of this may still need a decent amount of verification to be considered useful/reliable.

(Perhaps some phrases to Router Advertisements should be changed to the more generalized term of Router Discovery Messages.)

Overview of key technologies used for IPv6 automatic addressing

The standardized recommended approach

First, this overview provides some details about how various things fit together, and then this overview describes what those things are.

The standard approach for a host (such as a typical computer, or a device like a phone) using IPv6 autoconfiguration is for the host to send out a “router solicitation”. What is being solicited (meaning: sought, asked for) is a “router advertisement”. After sending the “router solicitation”, the host checks for a “router advertisement”. Routers respond to “router solicitation” requests by providing a “router advertisement”. If the host does receive a “router advertisement”, then the host will check the details from that available router advertisement. Those details should contain instructions to either use DHCPv6, or to use an IPv6 address that is calculated by using a process known as SLAAC. (If SLAAC is used, then additional information from the “router advertisement” will also be getting used.)

Okay, that brief overview contained a few terms that even seasoned IPv4 Internet experts may not be familiar with, so elaboration is needed. First, though, here is another brief overview of how things work:

With IPv6 automatic addressing, there are certain procedures that most devices are generally expected to support. Unlike IPv4 where most clients simply supported just one protocol, which was DHCP for IPv4, there are multiple automatic addressing methods that IPv6 clients are generally expected to support. Documentation (including not just this guide, but also the official documentation of software that implements IPv6 automatic addressing) will often/usually discuss SLAAC and NDP and “router advertisements” in the same documentation. Therefore, understanding the basic roles of each of these technologies will be helpful when reading the specific guides on how to implement even one of these technologies. The least painful approach is likely to first learn what all of these processes are, and to do that before trying to implement them.

Here is a brief overview of an understanding about what these things are, and how they may work together.

Router advertisements (brief overview)

One of the first techniques to become aware of is the use of “router advertisements”. Basically, a “router advertisement” is a message containing certain details about the network. The information in these router advertisements includes details that participating devices should use when performing autoconfiguration.

One example of some information that router advertisements contain is the size of the subnet. That's a rather funny statement because, as described later, the size of the subnet is often rather standardized (by the SLAAC process). However, despite being standardied, the subnet size is a detail that does get included in the information of router advertisements.

The router advertisements also include information about what process/protocol is used to specify the Internet (IPv6) address that a device should assign to itself.

The routing advertisements might also include details about a route supported by the router. (That detail may be related to how this information got the name of “routing advertisement”.) A client might also use details from a routing advertisement to determine which subnet is used. This would include not only the subnet size, but also the “subnet prefix”, which specifies what bits get used for the first part of each IPv6 address within the subnet. As noted by RFC 4862 (SLAAC) page 9, routing advertisements carrying information about a subnet prefix will also include “lifetime values, indicating how long addresses created from the prefix remain preferred and valid.” So, addresses using this information do effectively have an expiration time that is determined when the address starts to be used.

Specifically, a “router advertisement” in IPv6 is an ICMPv6 packet using ICMPv6 Message Type number 134. (This is documented by IANA ICMPv6 Parameters.) With IPv4, a “router advertisement” is an ICMP packet that is identified with ICMP Message Type number 9. (This is documented by IANA's list of ICMP (for IPv4) Parameters.)

Technet: ICMP Router Discovery is about IPv4, but the following sentences may apply to this similar process used with IPv6: “ICMP router discovery is not a routing protocol. Routers only advertise their existence, not the best way to reach a given destination network. If a host uses a non-optimal route, ICMP Redirect messages redirect the host to the better route.”

[#ndpvsrta]: Neighbor Discovery Protocol (“NDP”) (difference from router advertisements)

The “router advertisements” are basically a collection of information. If it helps, think of a routing advertisement like an informative document. The routing advertisement contains details in a specific format that can be understood by software.

However, a “routing advertisement” is simply a collection of data. What needs to happen, in order for that router adverisement to be useful, is that the data needs to get transferred.

These router advertisements get transmitted between computers using a protocol called the Neighbor Discovery Protocol (“NDP”). The rules of the Neighbor Discovery Protocol (“NDP”) cover details about what data is in the “router advertisements”, as well as additional rules like when that data gets sent over the network. Details/specifications that describe a “router advertisement” are focused on what data is in the packet, while the details of Neighbor Discovery Protocol (“NDP”) is a broader topic that also provides details about how computers share necessary details (including the contents of the routing advertisements).

(Note: in addition to being different from “router advertisements”, also true is that NDP is different than SLAAC.)

Finally, it should be noted that NDP is designed to deliver messages, and NDP does deliver messages other than just “router advertisements”. One of the ways that NDP is used is automatic address assignment. Another purpose that NDP fulfills is to help with translating “layer 3”/“logical” addresses (which are the IPv6 addresses) with the “layer 2”/“physical” addresses (which are the MAC addresses). With IPv4, that process was handled by a protocol called ARP. So NDP is involved in multiple different types of tasks. Automatic address assignment is just one of the tasks that uses NDP.

Assigning an address
[#ndpovw]: The role of NDP and the “router advertisements” it transmits

For automatic addressing to occur, the computer needs to know what IPv6 address to start using. The exact IPv6 address that will be assigned is only partially provided by the router advertisements that get delivered using Neighbor Discovery Protocol (“NDP”). Two specific and important details that are included in the the router advertisements are the “prefix length” and the “subnet ID”. The “prefix length” specifies how many bits at the start of the IPv6 address will certainly match the “subnet ID”. So, if the “prefix length” was /126 (which is not the most common prefix length), then the first 126 bits of the IPv6 will match the first 126 bits of the “subnet ID” that is provided in the router advertisements. However, IPv6 addresses are always a specific length (which is 128 bits long), so there are typically some remaining bits that need to come from some process other than using just the information in the routing advertisements.

The 41st bit of a router advertisement (which is bit number 40 if using a zero-based count) determines where the bits at the end of the IPv6 come from. The two choices are using SLAAC or using the DHCPv6 protocol. (Earlier versions of the NDP standard may have been less clear that the official alternative to SLAAC was DHCPv6, but that has been made more clear by RFC 4861 section 4.2.)

So, two main purposes of the router advertisements (transmitted using a protocol called NDP) are to provide the early bits of the IPv6 address, and to specify how the remaining bits are supposed to be figured out. A computer is not supposed to just start asking for an IPv6 address from DHCPv6 because that is just not the proper way to do things. The proper way for a computer to do things is to first start out by participating in NDP and then using the 41st bit of the router advertisement to determine whether DHCPv6 is supposed to be used. DHCPv6 should be used only when that 41st bit is set to a value of 1.

Now some people might ask why the router advertisement doesn't just provide the entire IPv6 address. In fact, the “prefix size” could be as long as /126 or perhaps even /128, and so the “subnet ID” has the capabilitiy of being as long as an IPv6 address. There is no technical limitation, such as a scarcity of available bits within a specific packet structure, that prevents the ability of including the entire IPv6 address in the packet. The simple and short answer is: computers don't look for the entire IPv6 address in the “router advertisement” people some people decided that is not how things will be done. The truth is that transmitting only the “subnet ID” does seem to simplify the actions required by the router. Granted, that may be more-than-offset by the costs of performing “DAD” (“duplicate address protection”) and especially the additional traffic if the same router is also performing DHCPv6. However, despite that apparent shortcoming, the truth is that the router can create a valid router advertisement without needing to keep track of which IPv6 addresses in a subnet has been used up. This simplifies the process of creating the router advertisement.

People who are used to thinking about DHCP/IPv4 may find this next bit interesting: if the 41st bit of the router advertisement is zero, then SLAAC is performed and the computer will figure out the ending bits of the IPv6 address on its own, without needing to get those bits from any server. So that really seems to simplify network communications.


This section is mostly just summarizing what was just covered.

[#ndpvslac]: (The prior “Differences between NDP and SLAAC” section has been replaced by this summary, which is briefer and provides an even broader understanding.)

router advertisement

A router advertisement is a type of message. It contains a “prefix length” and a “subnet ID”. The “subnet ID” contains the first bits of the IPv6 address that will be used.

Neighbor Discovery Protocol (“NDP”)

NDP is a protocol that is used to transmit information over the network. One type of information that NDP transmits is a “router advertisement”.


The really important detail to know about the process known as SLAAC, and the process of using the DHCPv6 protocol, is that these processes will supply whatever bits are still needed for the computer to have a full IPv6 address. Also, the proper and courteous action for a computer to take is to not start by using either DHCPv6 or SLAAC, but instead to start by using NDP to get a router advertisement. Then, one of the bits in the router advertisement will specify whether the computer should proceed to use SLAAC or whether the computer should proceed to use DHCPv6.

If the things just mentioned can be kept straight, then that will help with clarity when trying to understand all of IPv6's automatic addressing methods.

[#slaacovw]: “Stateless Address Autoconfiguration” (“SLAAC”) (overview)

The general expectation is that IPv6 clients will support not only NDP, but also a series of procedures known as “Stateless Address Autoconfiguration”. The phrase “Stateless Address Autoconfiguration” is actually commonly abbreviated as “SLAAC”. (The SLAAC RFC might not use this exact abbreviation, but the term “SLAAC” is indeed used. Examples of this name/abbreviation being used are Kohno document on IPv6 prefix length section 6: Appendix). The term “stateless” basically means that the server is not keeping track of a state, as opposed to “stateful autoconfiguration” (“SAC”)) (e.g. document on DHCPv6 section 4.1 refers to SAC).

In contrast to NDP, which is a network protocol that describing details about the bits that get sent over the network, SLAAC is a set of rules/procedures. This set of rules/procedures describes some further expected behavior of a device using IPv6 auto-configuration.

For example, SLAAC provides details about creating rather random-ish network addresses that are likely to be unique on a network, and performing “duplicate address detection” (“DAD”). These techniques may be used when coming up with a link-local address. These techniques may also be used when starting to use another IPv6 address, such as a publicly-accessible IPv6 address.

Unlike addresses that are received with DHCPv6, with SLAAC the device never does need to receive the entire IPv6 over the network. The device does use NDP to receive a “router advertisement” from the network, and that advertisement includes information about a subnet, which is a group of IPv6 addresses. The device will select an address from that subnet, and will prepare to use that address for further communications. The device makes the initial decision regarding which specific address to use, and this decision is made without needing any further information from the network. (The only information needed from the network is to identify the subnet to use, which is accomplished using the “subnet ID” and “prefix length” that are part of the router advertisement that is received by NDP. A process for choosing an address is described throughout RFC 4193: “Unique Local IPv6 Unicast Addresses”, section 3.2: “Global ID”, and most especially the sub-section 3.2.2.) Then, since the device is using a locally assigned address, the device performs “duplicate address detection” (“DAD”) to make sure that address will not cause problems. And then, the device uses the IPv6 address that the device decided upon. The address doesn't need to be delivered to the device by any remote system.

SLAAC is not just a networking protocol: it is a process that may contain details like what behaviors are done to a NIC's state of being enabled/up/down/disabled/etc. For example, if the “Duplicate Address Detection” process actually does detect a duplicate address, then SLAAC would shut down the NIC. (That was a hypothetical example, which might or might not accurately describe SLAAC.) Such changes are expected behavior by the operating system's network support, for any system that is using SLAAC.

More details about SLAAC are available.

[#dupadrdt]: Duplicate Address Detection (“DAD”)

RFC 4862 (IPv6 SLAAC) section 5.4: “Duplicate Address Detection” updates RFC 2462: IPv6 SLAAC, section 5.4: “Duplicate Address Detection, which also may have been updated by RFC 4429: “Optimistic Duplicate Address Detection (DAD) for IPv6.

It is believed/speculated that this is how DAD works, in a nutshell: The device tries to communicate with the address that it wants to use. If it succeeds (e.g., if it can get a “physical”/“MAC” address (like what ARP/IPv4 does)), then the address is considered to be unavailable. The device that intended to use the address will avoid using the address, in order to prevent duplicate address usage. (If SLAAC is being used, the device can try again to perform the SLAAC procedure, and hopefully be successful with a new address.)

However, RFC 4291: “IPv6 Addressing Architecture” section 2.5.1: “Interface Identifiers” describes the “universal/local bit”. Towards the bottom of page 8, the standard states, “IPv6 nodes are not required to validate that interface identifiers created with modified EUI-64 tokens with the” universal/logal bit “set to universal are unique”. So, if the eighth bit is set to one, DAD may be unnecessary. (Note that the standard says the “nodes are not required”. It does not say that “nodes are prohibited”. So, nodes still could perform DAD, but simply are not required to.)

[#slaacpsz]: SLAAC's Required subnet “prefix length”/size: /64

One thing to note about SLAAC: SLAAC may simply refuse to work unless the subnet's “prefix length” is exactly 64. (This means that the subnet is a /64 subnet.)

For most IPv6 addresses, the subnet “prefix length” cannot be a number that is larger than 64, or else the first paragraph of RFC 4291 (IPv6 Addressing Architecture) page 10 may/will be violated. SLAAC implementations may decide that possibility will not be allowed.

Furthermore, it seems that SLAAC limitations may insist on an interface ID being exactly 64-bits, not being “at least” 64-bits. Although the figure from RFC 4291: “IPv6 Addressing Architecture”, section 2.5.4: “Global Unicast Addresses” seems to indicate a variable-length “interface ID” length, the first paragraph on RFC 4291 (IPv6 Addressing Architecture) page 10 does say “64 bits long”, not “at least 64 bits long”. People may be interpreting that as an exact length, with no flexibility.

There does not seem to be much strong reasoning why SLAAC needed to be limited to exactly a 64 bit prefix length. However, that limit does seem to be implemented by at least some SLAAC implementations. Now, the good news is that SLAAC is largely definine local behavior, so other devices could easily follow some relaxed restrictions and the change should not break any other devices.

Regardless of whether or not this limitation is a good limitation, the limitation is certainly known to exist. So, in order to achieve success when working on existing devices/computers, being aware of the limitation is a good thing. Realize that using other subnet sizes may lead to struggles with SLAAC compatability.

SLAAC does not reserve addresses

The SLAAC specification does not really provide details about using reserved addresses, and this is not commonly done.

In theory, an address could be reserved simply by having a device claim the address is in use whenever DAD is performed. (No directions, about implementing this concept, are provided here.) However, RFC 4862 section 5.4.5 does indicate a case where a device may respond to DAD by disabling the device, so expecting a device to retry the SLAAC process is definitely not a universally safe expectation.


A DHCPv6 server may be used to hand out addresses. One feature about using this method is that the server may choose to reserve one or more IPv6 addresses, and so the DHCPv6 server may then hand out a reserved address to a specific client.

Note that a DHCPv6 server does not need to provide details about the prefix length. In fact, not providing the prefix length may be a quite common behavior for a DHCPv6 server (unlike the approach that was common practice with DHCP for IPv4). The simple reason for this difference (from IPv4's implementation) is that devices are expected to be using NDP and routing advertisements, and devices may get the subnet details that way. (With IPv4, DHCP was the only method that was both widely deployed, and DHCP was also a method that routinely provided the “prefix length”, which was more commonly referred to as a “subnet mask” size.)

Order of operations

Compared to IPv4 where DHCP was of prominent importance, DHCPv6 is reduced down to essentially being a secondary approach which may or may not be used. Many/most guides have people first participating in SLAAC. Setting up SLAAC makes sense because SLAAC requires rather little manual configuration once the other recommended technologies are deployed. Using router advertisements and NDP is recommended, whether or not SLAAC is being used. If for no other reason, the router advertisements and NDP should be used to provide some details, to clients, about what DHCPv6 should be used for. (Possible answers could include: assigning the IPv6 address for a device to use, also assigning additional information such as the IPv6 address of name resolution (DNS) servers. Or, another possible answer might even be: nothing. Some networks may specify that DHCPv6 should be used for nothing, simply meaning that DHCPv6 should not be used at all.) Once router advertisements and NDP are set up, customized to contain the minimum amount of information that they should be using, then SLAAC deployment is simpler than DHCPv6. (There is no need to set up a server for SLAAC, and setting up DHCPv6 clients has been a challenge, at least sometimes historically.)

Some people may be wondering why IPv6 deployments start with router advertisements and NDP. In theory, another approach could have been the standard: theoretically the standard could have started with trying to use DHCPv6, and then fall back to the other technologies if DHCPv6 failed. This guide provides no particular insights as to whether or not that theory could/would have worked out better. However, despite whether the reasons were good or not, the standard that eventually got embraced was a general recommendation to have router advertisements optionally direct clients to use DHCPv6, and not the other way around. The recommended approach, for the smoothest possible experience (compatible with the largets number of devices), is to use the standard that exists.

Pushing possibilities: Some miscellaneous notes

Some people like to understand limits, and may be interested in what happens if people ignore unnecessary assumptions and see what is technically possible. These notes were written while working on this document, so they are related to the topics of this document. However, they seemed sufficiently off the topic of how to easily understand the technologies and make them work easily, so these notes were extracted and placed in this separate section.

Further SLAAC-related theory

For people who are just trying to understand how to make these technologies work, this “theory” section may be skippable. This is largely meant to help satisfy people who are interested in “all” cases (including “corner cases”).

Trying to use DAD to use a specified address

This ends up being a terrib(The rest of this section simply discusses theory, without changing the conclusion that had just been stated.)

However, if a router simply reserved an address (so that other devices would not use the address), that still wouldn't inform the device that the address is reserved. So, if that device is relying on SLAAC then that device will statistically not end up quickly using the reserved address.

Some people might contemplate forcing a device to use a desired IPv6 address by simply using the DAD process to prohibit the use of addresses other than the authorized address(es). However, that would use up a lot more resources (network bandwidth, and time) than what seems reasonable for such a task. Keep in mind that SLAAC has implemented a rule regarding the size of the subnet, so these IPv6 subnets will have many possible addresses. A /64 subnet would have 18,446,744,073,709,551,616 addresses (including the “subnet ID”). The device would need to choose each potential address using its rather random approach, so an implementation of psuedo-randomness might even skip the needed address. Many psuedo-random number generators repeat results, and avoiding repeats would require the device to use a lot of memory to store all of the potential failure (up to approximately 295,147,904 Terabytes of RAM (18,446,744... x 16 bytes) to support a /64 subnet. That amount of RAM greatly exceeds the amount of 4 GB, which was a common/typical amount of RAM for a desktop PC in the year 2013. Keep in mind that one goal of IPv6 was to be able to support lots of devices, so requiring a computer with unrealistically huge amounts of memory is not going to be a good network design. So, if memory and network bandwidth and time were super-abundant (such as being infinitely abundant), then such a terribly inefficient approach might technically work (as long as the PRNG doesn't skip the desired address), but this approach actually ends up just being unrealistic.

DAD failure

RFC 4862 section 5.4.5 specifies what should happen if the “Duplicate Address Detection” does actually detect a duplicate address.

The specification notes a case when “an interface identifier based on the hardware address” was used to form a tentative address. That probably really should refer to “an interface identifier based only on the hardware address”. Conceivably the use of NTP in RFC 4193: “Unique Local IPv6 Unicast Addresses”, section 3.2.2: Sample Algorithm could lead to different devices (using different hardware identifiers) processing the altorithm at different times and then having the same result. Such a problem would be very unlikely, but possible, and resolvable by waiting a short and unique length of time (which is random in length, or based on the hardware ID) and then re-trying.

Further notes about the NDP standard

The “Router Advertisement Message Format” has been described in section 4.2 of multiple NDP-related standards. In RFC 1970 section 4.2 and RFC 2461 section 4.2, the 41st bit (which is bit number 40 when using a zero-based count) specified whether a computer should used “stateful” address assignment, or the process described in the “ADDRCONF” document, which is the process called “autonomous (stateless) address configuration”, which is a process that is now more commonly known as “SLAAC”. The only reference to DHCPv6 was a note in parenthesis, which may have indicated that DHCPv6 was simply an example of a “stateful” way of keeping track of addresses, perhaps leaving the door open to some other possible future method of providing “stateful” automatic address assignment.

However, section 4.2 of a newer NDP-related standard document (RFC 4861 section 4.2) has more clearly noted that method to be used (when the right bit has the right value) should be DHCPv6. (This clraification was quite intentional, as it was documented by the seventh point of RFC 4861 page 94.)

With the older versions of the NDP standard, it seemed that using a “stateful” implementation other than DHCPv6 would be compliant.

For that matter, if the 41st bit is set to a value of one, then the 42nd bit has no real meaning. This is unfortunate, because the possibility could have existed to have a combination of bits reserved for future use, in case a new and preferred standard came along. As is, if the 41st bit is set to a value of one, some experience with some implementations indicates that the 42nd bit is usually given a value of zero (in practice, even if there is no reason that this is required for RFC compliance).