I just started working with IPv6, so I read a lot over the last couple of days. Unfortunately, some of my questions have not been answered in my research.
My goal is to keep track of which addresses are assigned and to which interface they are assigned. From what I read, there are several ways the interface can get the IPv6 address, which I listed below in the subsections. I highlighted what I have discovered so far and asked some questions in these sections. If someone can make any corrections to what I found out, or if you have answers to questions, please do so. If anyone knows about a place where I can find more information, I don't mind studying it anymore.
Edit: I found that delegating a prefix does not actually result in an address assignment. It is used by DHCP servers to obtain prefixes for use with another DHCP server.
Ways to get an IPv6 address:
- Status Address Autosave (SLAAC)
- Stateful DHCPv6
SLAAC
SLAAC is used in small networks to create an IPv6 address for an interface. It requires a (almost) lack of configuration and basically works as follows:
- When the interface connects to the network, the client will generate a local IPv6 address using the interface address and the local channel prefix (
FE80::/10 ). - To ensure that this address is unique, a Neighbor Neighbor (
NS ) message is sent to the address. If there is an answer, then the address is used and cannot be used. Autoconfiguration is interrupted, and tuning must be done manually. Question 1a: is there really no return? Assuming no response is received at the end of the waiting period, the address is considered unique and is assigned as the local communication address for the interface.
Node now has a connection to all other nodes on this link
A node is expected to receive a router advertisement ( RA ) or send a group request ( RS ) message to a multicast group for all routers. When RS received by the router, it will answer RA . RA will contain a prefix.
- node will generate a global unicast address with a prefix and its interface identifier.
- Similar to how a local link address was created, 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 an answer, then the address is already in use, the address assignment must be done manually. Question 1b: Again, is there any automated way to recover? - Assuming there was no response during the timeout, then the address is then assigned a global IPv6 address for the interface.
Question 3: It is possible to have more than one address for an interface. In fact, at the end of the process described above, one interface will have 2 addresses - local-local and global unicast. Can I get additional addresses for this interface using SLAAC? Or should another method be used (e.g. DHCPv6)?
Stateful DHCPv6
A node can get the local link address using steps 1-3 above. I believe that this is optional and that it can simply use ::/128 (unspecified) as the source address in DHCP requests until it is assigned an address.
There are two methods for obtaining an address - regular and quick-fix. Normal is messaging ( Solicit , Advertise , Request , Reply ), and Rapid is messaging ( Solicit , Reply ). Rapid-commit is executed when the client requests it with the Rapid-Commit option in the Solicit message. This is essentially the same as Normal, and since it does not matter for my use, I will ignore it for now.
In addition, it is possible that messages are proxied through a relay. Messages sent to the server from the relay are RELAY_FORW messages, and messages sent from the server to the relay are RELAY_REPL messages. The actual dialogue between the client and server is fully encapsulated within the OPTION_RELAY_MSG option. In the following cases, I only deal with non-relay messages. If the message was relayed, then it is easy to get the original message, and is still saved.
The address assignment is as follows:
- The client sends a
Solicit message to the "All DHCP Servers and Relays" multicast address. The purpose of this message is to locate the DHCP server identifier from a local link. - The DHCP server responds to the
Advertise message to the local multicast address. - The client sends a
Request message directly to the DHCP server with parameters indicating that it would like to have an IP address. Question 4: In the PCAP files I saw, it looks like this message is still being sent to the multicast address ff02::1:2 . Any reason this is not sent directly to the DHCP server from which the advertisement was received? - The DHCP server responds with a
Reply containing the IP address. - The client must re-discover the address, similar to step 6 in the SLAAC method.
- node assigns this address to the interface and can start using it.
This is a general method for assigning addresses, but more specifically, there are three ways to do this:
- Continuous Address
IA_NA ( IA_NA ) - Temporary Address
IA_TA ( IA_TA ) - Delegation Prefix (
PD )
All three methods are performed by including an option in Request , which is then populated by the server and returned to Reply . For the first two, the full IPv6 address is returned, which can then be assigned as the IP address for the interface. For the third, the prefix is returned similarly to RA in the SLAAC method. This prefix is then used with the interface identifier to create the full global IPv6 address.
Question 5: In my pcap captures, I see that Solicit and Advertise often contain these parameters. This seems unnecessary in the non-quick case, since Request and the subsequent Reply must also contain this option. What is the purpose of including this option in Solicit ? And what is the purpose of the DHCP server creating the IP address (or prefix) in Advertise before Request ed does this?
Question 6: RFCs show that multiple instances of the IA_NA (or IA_TA ) parameter can be included. I assume that this means that the interface will have multiple addresses. Does the client simply include multiple instances of the option in the Request to receive multiple addresses? What happens if a DHCP server can provide some, but not all, addresses? Do all Reply indicate a failure? Or are some addresses indicated?
Address exemption
For DHCPv6, the address that is being used can be released by the Release message. The address assigned by the server in Reply may be rejected by the client with a Decline message instead of being used.
If the client does not send Release or Decline , the server will continue to hold the address for the client until it expires.
Question 7: If the client cannot send Release (or Decline ) and reboots, it initiates a new DHCP request. Will the DHCP server return the old address? Or suppose this is a request for an additional IP address and assignment of a new one?
I don’t know how the addresses created by SLAAC or DHCP PD , if ever. Perhaps the release of these addresses is carried out only internally, and no external device should be aware of this event.
As I said at the beginning, my goal is to keep track of all the assigned addresses that are currently valid. My plan was as follows:
- Create a card indexed at the address where the client to which it is assigned (DUID) is stored.
- If you receive DHCPv6
Reply before Request , Confirm , Renew , Rebind or Solicit using Rapid-Commit complete the following steps:- Retrieve the
Client-DUID parameter - For each
IA_NA or IA_TA- For each
IA set map[address]=Client-DUID - Saves address expiration time
- If you receive
Decline or Reply before Release follow these steps:- For each
IA_NA or IA_TA- For each
IA set remove map[address]
- When the address expires, it will be removed from the card
Question 8: How to determine the generated SLAAC addresses or DHCP PD addresses? Is there any field in the messages that I can use to restore the full IP address? I will already have a prefix, but the interface identifier is unknown.
Is it enough to maintain a list of IP addresses assigned to clients?