ress Autoconfiguration procedures after detecting the M-bit on a Router Advertisement (see Section 3.4.3). Effectively, before this happens, a host already has autoconfigured a link-local address for itself with SLAAC. The first DHCPv6 protocol step that the host performs is to send a DHCPv6 SOLICIT multicast message containing indications about the client interest to configure addresses for itself. The indication is given by the client including 'Identity association for non- temporary addresses (IA_NA)', or 'Identity association for temporary addresses (IA_TA)', or both, options in the SOLICIT message. If the client prefers to use a single message exchange, it may include a Rapid Commit option in the SOLICIT message [54]. DHCPv6 servers that receive the SOLICIT message sent by a client may respond with a DHCPv6 ADVERTISE message. From the ADVERTISE messages the client learns what DHCPv6 servers are available and what addresses they could provide for the client. Introduction to IPv6 Once the client has chosen which DHCPv6 server to use, the client sends a DHCPv6 REQUEST unicast message to the DHCPv6 server. The client may populate the REQUEST with information it has earlier received in a DHCPv6 ADVERTISE message. After receiving the DHCPv6 REQUEST the DHCPv6 server will respond with a DHCPv6 REPLY message that contains addresses allocated to the client and possible other configuration information. The client needs to perform DAD to offered addresses similarly as for any other IPv6 address candidate that a host ends up with. If the DAD fails, the client has to send a DECLINE message to the server. The DHCPv6 framework allows a DHCPv6 server to be located at a different link than DHCPv6 clients. In such a case, the link that the client is connected to has a DHCPv6 relay entity, which forwards messages between the DHCPv6 client and the server. In addition to the messages used in the four-way handshake for address configuration (SOLICIT, ADVERTISE, REQUEST, and REPLY), a number of additional DHCPv6 messages have bee