IPv6 Address Assignments

Question

I have just started working with IPv6, so I've done a lot of reading in the last couple of days. Unfortunately, some of my questions have not been answered in my research.

My goal is to keep track of what addresses are assigned, and to what interface they are assigned. From what I've read, there are a few ways that an interface can get an IPv6 address, which I've listed below in sub sections. I've highlighted what I've discovered so far, and posed some questions in these sections. If anyone can make any corrections to what I've learned, or have answers to the questions, please do so. If anyone knows of a place I can find more information, I don't mind researching it more myself.

Edit: I've discovered that Prefix Delegation does not actually result in address assignment. It is used by DHCP servers to get the prefixes to use from another DHCP server.

---

The methods for obtaining an IPv6 address are:

1. StateLess Address Auto-Config (SLAAC)
2. Stateful DHCPv6

SLAAC

SLAAC is used in small networks to generate an IPv6 address for an interface. It requires (almost) no configuration and basically works as follows:

1. When the interface comes online, the client will generate a link-local IPv6 address using its interface ID address and the link-local prefix (FE80::/10).
2. To verify this address is unique, a Neighbour Solicitation (NS) message is sent to the address. If there is a reply, then the address is in use and cannot be used. Auto-config is aborted and configuration should proceed manually. Question 1a: Is there really no fall back here?

3. Assuming no reply is received by the end of the timeout period, the address is assumed to be unique and it is assigned as the link-local address to the interface.

   Now the node has connectivity to all other nodes on this link

4. The node either waits to receive a Router Advertisement (RA), or sends a Router Solicitation (RS) message to the multicast group for all routers. When an RS is received by a router, it will respond with an RA. The RA will contain a prefix.

5. The node will generate a global unicast address with the prefix and its interface ID.
6. Similar to when the link-local address was created, the node will send a message to the address to determine if it is unique. Question 2: Is this also an NS message? If there is a reply, then the address is already in use, address assignment must proceed manually. Question 1b: Again, is there any automated way to recover?
7. Assuming there was no reply within the timeout, then the address is then assigned as the global IPv6 address to the interface.

Question 3: It is possible to have more than one address for the interface. In fact, at the end of the above process, a single interface will have 2 addresses - a link-local one and a global unicast one. Is it possible to get additional addresses for this interface using SLAAC? Or must another method (e.g. DHCPv6) be used?

Stateful DHCPv6

A node may obtain a link-local address using steps 1-3 from above. I believe this is optional and that it can simply use ::/128 (unspecified) as its source address in DHCP requests until it is assigned an address.

There are two methods of obtaining an address - normal and rapid-commit. Normal is a 4 message exchange (Solicit, Advertise, Request, Reply), and Rapid is a 2 message exchange (Solicit, Reply). Rapid-commit is done when the client requests it with a Rapid-Commit option in the Solicit message. It is essentially the same as Normal, and since it doesn't make a difference for my usage, I am going to ignore it for now.

Also, it is possible that messages are proxied through relays. Messages sent to a server from a relay are RELAY_FORW messages, and messages sent from the server to the relay are RELAY_REPL messages. The actual dialog between the client and server is encapsulated in its entirety within an OPTION_RELAY_MSG option. For the following, I am dealing only with non-relay messages. If a message was relayed, then it is easy to obtian the original message and the following still holds.

Address assignment takes place as follows:

1. The client sends a Solicit message to the "All DHCP Servers and Relays" multicast address. The purpose of this message it to discover the identity of a DHCP server on the local link.
2. A DHCP server responds with an Advertise message to the local multicast address.
3. The client sends a Request message directly to the DHCP server with options indicating that it would like to have an IP address. Question 4: In the PCAP files I've seen, it looks like this message is still sent to the multicast address ff02::1:2. Any reason that this is not sent directly to the DHCP server from which the Advertise was received?
4. The DHCP server responds with a Reply containing the IP address.
5. The client should perform duplicate address detection similar to step 6 in the SLAAC method.
6. The node assigns this address to the interface and can begin using it.

This is the general method by which addresses are assigned, but more specifically, there are 3 ways that this can be done:

1. Non-temporary address assignment (IA_NA)
2. Temporary address assignment (IA_TA)
3. Prefix Delegation (PD)

All three methods are accomplished by including an option in the Request which is then populated by the server and returned in the Reply. For the first two, a complete IPv6 address is returned which can then be assigned as an IP address for the interface. For the third, a prefix is returned similar to the RA in the SLAAC method. This prefix is then used with the interface identifier to create a complete global IPv6 address.

Question 5: In my pcap captures, I am seeing that the Solicit and Advertise often contain these options as well. This seems redundant in the non-rapid case since the Request and subsequent Reply must also contain the option. What is the purpose for including this option in the Solicit? And what is the purpose of the DHCP server creating the IP address (or prefix) in the Advertise before being Requested to do so?

Question 6: The RFCs indicate that multiple instances of the IA_NA (or IA_TA) option can be included. I assume this means that the interface will then have multiple addresses. Does the client simply include multiple instances of the option in the Request to get multiple addresses? What happens if a DHCP server can supply some, but not all of the addresses? Does the entire Reply indicate a failure? Or are some addresses given?

---

Releasing Addresses

For DHCPv6, an address in use can be released with a Release message. An address assigned by the server in a Reply can be declined by the client with a Decline message instead of being used.

If a client fails to send the Release or Decline, the server will continue to hold the address for the client until it expires.

Question 7: If a client can't send the Release (or Decline) and reboots, it will initiate a new DHCP request. Will the DHCP server give back the old address? Or will it assume this is a request for an additional IP address and assign a new one?

I am not sure how addresses created by SLAAC or DHCP PD are released, if ever. Perhaps the release of these addresses is only done internally and no external device need know of the event.

---

As I stated at the beginning, my goal is to keep track of all the address assignments that are currently valid. My plan was to do the following:

• Create a map indexed by address which stores the client to which it is assigned (DUID).
• On the receipt of a DHCPv6 Reply to a Request, Confirm, Renew, Rebind, or Solicit with Rapid-Commit, do the following:
  • Extract the Client-DUID option
  • For each IA_NA or IA_TA
    • For each IA, set map[address]=Client-DUID
    • Store the expiry time of the address
• On the receipt of a Decline or Reply to a Release, do the following
  • For each IA_NA or IA_TA
    • For each IA, set remove map[address]
• When an address expires, it will be removed from the map

Question 8: How do I detect SLAAC generated addresses or DHCP PD addresses? Is there some field in the messages I can use to regenerate the complete IP address? I will already have the prefix, but the interface ID is unknown.

Is this sufficient to maintain a list of IP addresses assigned to clients?

Answer 1

OK - so I've done some more research and I have most of the answers now.

First of all, a correction. Addresses are not obtained via PD with DHCP. That is how DHCP servers obtain a network prefix to use for the DHCP clients they host. There is another DHCP server which deals with handing out these prefixes. Thus, PD can be ignored as a method for obtaining IP addresses.

---

Question 1a/b: Is there really no fall back here?

Answer: There is no automated fallback mechanism. One can be implemented, but it would be custom.

Question 2: Is this also an NS message?

Answer: Yes

Question 3: It is possible to have more than one address for the interface. In fact, at the end of the above process, a single interface will have 2 addresses - a link-local one and a global unicast one. Is it possible to get additional addresses for this interface using SLAAC? Or must another method (e.g. DHCPv6) be used?

Answer: Multiple addresses can be generated with SLAAC. A client can use the Router Advertisements from multiple routers, and each router may advertise multiple prefixes. Each prefix can be used by the host to create a global unicast address.

Question 8 (modified): How do I detect SLAAC generated addresses? Is there some field in the messages I can use to regenerate the complete IP address? I will already have the prefix, but the interface ID is unknown.

Answer: The only way to detect them is to listen for NS messages. Since these messages are optional, there is no guaranteed way to detect SLAAC generated addresses.

---

I still don't have answers for questions 4-7, but I am not too concerned with them at the moment.

Thanks!!