title: IPv6 Address Assignments
body: <p>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.  </p>
  
  <p>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.</p>
  
  <p><strong>Edit:</strong> 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. </p>
  
  <hr>
  
  <p>The methods for obtaining an IPv6 address are:</p>
  
  <ol>
  <li>StateLess Address Auto-Config (SLAAC)</li>
  <li>Stateful DHCPv6</li>
  </ol>
  
  <h2>SLAAC</h2>
  
  <p>SLAAC is used in small networks to generate an IPv6 address for an interface.  It requires (almost) no configuration and basically works as follows:</p>
  
  <ol>
  <li>When the interface comes online, the client will generate a link-local IPv6 address using its interface ID address and the link-local prefix (<code>FE80::/10</code>). </li>
  <li>To verify this address is unique, a Neighbour Solicitation (<code>NS</code>) 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.  <strong><em>Question 1a: Is there really no fall back here?</em></strong> </li>
  <li><p>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.</p>
  
  <p><strong>Now the node has connectivity to all other nodes on this link</strong></p></li>
  <li><p>The node either waits to receive a Router Advertisement (<code>RA</code>), or sends a Router Solicitation (<code>RS</code>) message to the multicast group for all routers.  When an <code>RS</code> is received by a router, it will respond with an <code>RA</code>.  The <code>RA</code> will contain a prefix.</p></li>
  <li>The node will generate a global unicast address with the prefix and its interface ID. </li>
  <li>Similar to when the link-local address was created, the node will send a message to the address to determine if it is unique.  <strong><em>Question 2: Is this also an <code>NS</code> message?</em></strong>  If there is a reply, then the address is already in use, address assignment must proceed manually.  <strong><em>Question 1b: Again, is there any automated way to recover?</em></strong></li>
  <li>Assuming there was no reply within the timeout, then the address is then assigned as the global IPv6 address to the interface.</li>
  </ol>
  
  <p><strong><em>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?</em></strong></p>
  
  <h2>Stateful DHCPv6</h2>
  
  <p>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 <code>::/128</code> (unspecified) as its source address in DHCP requests until it is assigned an address.  </p>
  
  <p>There are two methods of obtaining an address - normal and rapid-commit.  Normal is a 4 message exchange (<code>Solicit</code>, <code>Advertise</code>, <code>Request</code>, <code>Reply</code>), and Rapid is a 2 message exchange (<code>Solicit</code>, <code>Reply</code>).  Rapid-commit is done when the client requests it with a <code>Rapid-Commit</code> option in the <code>Solicit</code> 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.</p>
  
  <p>Also, it is possible that messages are proxied through relays.  Messages sent to a server from a relay are <code>RELAY_FORW</code> messages, and messages sent from the server to the relay are <code>RELAY_REPL</code> messages.  The actual dialog between the client and server is encapsulated in its entirety within an <code>OPTION_RELAY_MSG</code> 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.</p>
  
  <p>Address assignment takes place as follows:</p>
  
  <ol>
  <li>The client sends a <code>Solicit</code> 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.</li>
  <li>A DHCP server responds with an <code>Advertise</code> message to the local multicast address.</li>
  <li>The client sends a <code>Request</code> message directly to the DHCP server with options indicating that it would like to have an IP address. <strong><em>Question 4: In the PCAP files I've seen, it looks like this message is still sent to the multicast address <code>ff02::1:2</code>.  Any reason that this is not sent directly to the DHCP server from which the Advertise was received?</em></strong></li>
  <li>The DHCP server responds with a <code>Reply</code> containing the IP address.</li>
  <li>The client should perform duplicate address detection similar to step 6 in the SLAAC method.</li>
  <li>The node assigns this address to the interface and can begin using it.</li>
  </ol>
  
  <p>This is the general method by which addresses are assigned, but more specifically, there are 3 ways that this can be done:</p>
  
  <ol>
  <li>Non-temporary address assignment (<code>IA_NA</code>)</li>
  <li>Temporary address assignment (<code>IA_TA</code>)</li>
  <li>Prefix Delegation (<code>PD</code>)</li>
  </ol>
  
  <p>All three methods are accomplished by including an option in the <code>Request</code> which is then populated by the server and returned in the <code>Reply</code>.  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 <code>RA</code> in the SLAAC method.  This prefix is then used with the interface identifier to create a complete global IPv6 address.</p>
  
  <p><strong><em>Question 5: In my pcap captures, I am seeing that the <code>Solicit</code> and <code>Advertise</code> often contain these options as well.  This seems redundant in the non-rapid case since the <code>Request</code> and subsequent <code>Reply</code> must also contain the option.  What is the purpose for including this option in the <code>Solicit</code>?  And what is the purpose of the DHCP server creating the IP address (or prefix) in the <code>Advertise</code> before being <code>Request</code>ed to do so?</em></strong></p>
  
  <p><strong><em>Question 6: The RFCs indicate that multiple instances of the <code>IA_NA</code> (or <code>IA_TA</code>) 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 <code>Request</code> to get multiple addresses?  What happens if a DHCP server can supply some, but not all of the addresses?  Does the entire <code>Reply</code> indicate a failure?  Or are some addresses given?</em></strong></p>
  
  <hr>
  
  <h2>Releasing Addresses</h2>
  
  <p>For DHCPv6, an address in use can be released with a <code>Release</code> message.  An address assigned by the server in a <code>Reply</code> can be declined by the client with a <code>Decline</code> message instead of being used.</p>
  
  <p>If a client fails to send the <code>Release</code> or <code>Decline</code>, the server will continue to hold the address for the client until it expires.</p>
  
  <p><strong><em>Question 7: If a client can't send the <code>Release</code> (or <code>Decline</code>) 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?</em></strong></p>
  
  <p>I am not sure how addresses created by SLAAC or DHCP <code>PD</code> are released, if ever.  Perhaps the release of these addresses is only done internally and no external device need know of the event.  </p>
  
  <hr>
  
  <p>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:</p>
  
  <ul>
  <li>Create a map indexed by address which stores the client to which it is assigned (DUID).</li>
  <li>On the receipt of a DHCPv6 <code>Reply</code> to a <code>Request</code>, <code>Confirm</code>, <code>Renew</code>, <code>Rebind</code>, or <code>Solicit</code> with <code>Rapid-Commit</code>, do the following:
  
  <ul>
  <li>Extract the <code>Client-DUID</code> option</li>
  <li>For each <code>IA_NA</code> or <code>IA_TA</code>
  
  <ul>
  <li>For each <code>IA</code>, set <code>map[address]=Client-DUID</code></li>
  <li>Store the expiry time of the address</li>
  </ul></li>
  </ul></li>
  <li>On the receipt of a <code>Decline</code> or <code>Reply</code> to a <code>Release</code>, do the following
  
  <ul>
  <li>For each <code>IA_NA</code> or <code>IA_TA</code>
  
  <ul>
  <li>For each <code>IA</code>, set remove <code>map[address]</code></li>
  </ul></li>
  </ul></li>
  <li>When an address expires, it will be removed from the map</li>
  </ul>
  
  <p><strong><em>Question 8: How do I detect SLAAC generated addresses or DHCP <code>PD</code> 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.</em></strong></p>
  
  <p>Is this sufficient to maintain a list of IP addresses assigned to clients?  </p>