• Host autoconfiguration
• Router autoconfiguration
• DNS autoconfiguration
• Service autoconfiguration

IPv6 aims at becoming a plug & play protocol, meaning that it will be sufficient to connect a machine physically to the network for it to configure itself automatically so that it is able to communicate with other machines. Four types of autoconfiguration are needed in order to achieve this type of capability: host autoconfiguration, router autoconfiguration, DNS autoconfiguration, and service autoconfiguration.

Host autoconfiguration is a mechanism whereby addresses and other parameters can be assigned to network interfaces. This can be done in two different ways, known as stateful and stateless autoconfiguration.

In the stateful model, a host obtains the address (and other parameters) for an interface by querying a server using DHCPv6, the IPv6 extension of the DHCP protocol (Dynamic Host Configuration Protocol) specified for IPv4. The server maintains an updated database with information concerning the addresses that have already been assigned. This type of autoconfiguration is recommended for large sites, as it provides better address utilization and more effective guarantees on security.

IPv6 introduces a new type of automatic configuration which is activated as soon as the interface is enabled, and has the major advantage of not requiring action on the part of special servers; in addition, it is no longer necessary to configure the nodes with the server's address. This new mechanism is called stateless autoconfiguration and is part of the Neighbor Discovery protocol, which is based on information provided by each router to its neighbors. It is a basic protocol for IPv6, and will be described in detail in the next paragraph.

The messages sent by the routers are at the basis of the Neighbor Discovery protocol and of the mechanisms for automatic station configuration: consequently, these messages must be updated first if changes occur within a site. Keeping a router updated means ensuring that it has an exact knowledge of the organization of the subnet to which it is connected, which in turn means assigning the correct prefixes to each link with which the router has an interface.

Handling prefixes manually is extremely burdensome, both because of the size of IPv6 addresses, and because of the frequency with which an IPv6 site may need renumbering. For this reason, the Router Renumbering (RR) protocol is now being developed. This protocol is a new ICMPv6 mechanism whereby prefixes on the routers can be configured automatically through the exchange of packets whose general format is shown in Figure 27.

ICMPv6 assigns a type value of 138 to RR. There are two types of message, distinguished by the contents of the code field: zero for Command messages and one for Result messages.
The message body of an RR Command contains a sequence of Prefix Control Operations (PCO ), each specifying an operation (ADD, CHANGE or SET GLOBAL), a Match-Prefix and zero or more Use-Prefix.

A router which receives an RR Command processes each PCO in sequence, checking whether there is a correspondence between the addresses of each of its interfaces and a Match-Prefix. If there is, it applies the specified operation, which may consist of adding, removing or changing the prefix. The Use-Prefix field indicates the prefixes to be added/and or changed. Subsequently, the router forwards an RR Result message to the sender indicating the outcome of the operation.
Because of the potential of this mechanism, the Authentication Data and sequence number have been added to provide anti-replay protection, i.e., assurance that captured packets cannot be retransmitted and accepted as valid data, especially after fragmentation, as well as protection against unauthorized prefix changes.
Given the keen interest in the Router Renumbering protocol, work is now being carried out to bring it to the level of a proposed standard.

To facilitate man-machine interfacing, applications generally handle domain names rather than numerical addresses. An address is obtained by looking it up in the Domain Name System (DNS), the distributed database containing name-address mappings for each Internet domain.
Addresses are stored in data structures called "resource records" and identified by type: IPv4 addresses are stored in type A records which consequently contain 32-bit addresses. For IPv6, the new AAAA or quad A record type containing 128-bit addresses has been defined.

Updating the DNS is a time-consuming operation, as it is necessary to process each record whose contents must be changed and then propagate this information from the primary server to the other network servers. With IPv6, this operation is even more laborious because of address size and the fact that renumbering must be carried out more frequently. It is thus essential that a mechanism be developed for automatic DNS updating and configuration.

Though no protocol is available at the moment which permits DNS autoconfiguration, a new record type called A6 has been defined which replaces the AAAA record and will facilitate the adoption of an automatic DNS management mechanism. The new A6 record is shown in Figure 28.

The A6 record contains three fields: the prefix length, an IPv6 address suffix, and the prefix domain name. In order to understand how this information can be used to obtain a 128-bit address, take the case of a host belonging to site X and served by provider A. If AAAA records are used, it is necessary to store a name-to-address mapping of the following type:

hostIPv6.site-X.providerA.net <-> 2345:00C1:CA11:0001:1234:5678:9ABC:DEF0

using a single record. With A6 records, on the other hand, the following mappings must be created:p> hostIPv6 <-> 64 :: 1234:5678:9ABC:DEF0 site-X
site-X <-> 48 : 00C1:CA11:0001:: providerA.net
providerA.net <-> 0 2345::

To obtain this host's IPv6 address, a DNS client must acquire the complete chain of three A6 records. The last record in the chain is identified by a prefix length of zero.
The advantage of a system of this kind is the simplicity with which updating can be performed in the event of site renumbering: only the record relating to the site (e.g., site-X) need be changed, while the records for its stations need not be touched.
For reverse resolution (i.e., determining a name given the address), the IP6.INT domain has been defined. An IPv6 address is expressed in dotted decimal notation, with the sequence of digits coded in inverse order. Example:

4321:0:1:2:3:4:567:89AB
   becomes
B.A.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.1.2.3.4.IP6.INT

This representation method requires that one record be memorized for each address assigned to an interface. This, however, significantly complicates the problem of updating, which is even more serious than in the previous case because reverse resolution queries outnumber direct resolution queries. The proposed solution consists of using a recursive mechanism similar to that described for the A6 record. In the case examined above, for example, there will be one IP6.INT record containing the prefix for the provider, one with that assigned to the site, and one containing the address assigned to the station written in the following type of format:

0.F.E.D.C.B.A.9.8.7.6.5.4.3.2.1.sito-X.providerA.net.IP6.INT

Traditionally, to make use of the services available on the network, users must know at least the name of the network host on which they are installed. This does not comply fully with the plug & play paradigm, which calls for being able to use everything the network has to offer while knowing nothing whatsoever about its configuration.
This is the reason underlying the development of the Service Location Protocol (SLP), which provides a flexible and scalable structure whereby hosts can access information concerning the existence, location and configuration of network services.
SLP eliminates the need for a user to know the name of a network station which supports the desired service, as it is sufficient that the user be able to describe its type and a set of attributes, and SLP will resolve the service's network address for the user on the basis of this description. In addition, the protocol offers a dynamic configuration mechanism for local area network applications.

This protocol is still in the process of standardization for both IPv4 and IPv6. Operation is identical for both, and is based on message exchange by three processes: User Agent, Service Agent (SA) and Directory Agent (DA).
User Agent (UA) is a process which works on a user's machine in order to send a Service Request message constructed on the basis of user application needs. This request can be made directly to the SA using a multicast message, or can be made to a DA through a unicast message.
In the former case, the Service Agent involved, which is located on the machine provided with the service, will respond with a Reply message sent to the unicast address of the UA that made the request.
Directory Agent is a process that may be located on any machine in the network, and operates like a cache memory containing information about the Service Agents and their announced services. The User Agent can thus use unicast messages addressed to a particular DA to obtain the desired information.
The other two processes detect the presence of a Directory Agent both when they are started up, and by periodically sending multicast Service Request messages to which the DA responds with a multicast Advertisement. It is important that the SAs know that the DAs are present, as the information that the latter contain are provided by the SAs and kept up to date by these processes.
In general, services are grouped by type using a special label called the scope string. This can indicate a location, an administrative group or other characteristics, and is always assigned to the SAs and DAs. Thus, if a scope string is also assigned to the UA, the search scope can be limited.
The differences between the IPv4 and IPv6 versions of SLP are chiefly at the implementation level, and arise from the differences between the two protocols, including their dissimilar address format.