The basic (and possibly legal) requirement of many institutions is that they be able to authorise the access to the network, and be able to trace actions on the network to an individual (the one who requested such access authorisation).

While manual assignment of IPv6 addresses and manual configuration of the DNS remains an option to fulfill this requirement, this may be practical only at the smallest sites. Given the size of the IPv6 address space, this should anyway be accompanied by measures to only allow access to the network (LAN and/or WAN) to properly authorised hosts. (IPv6 could as well be the case to start enforcing a generalised adoption of IEEE 802.1x access, rather than IPSEC).

In case network access has been secured (e.g. via IEEE 802.1x), stateless address configuration (SLAAC) may become a viable option, with or without the use of privacy extensions. This should probably go together with automatic updates of the DNS maps.

For sites that rely on MAC addresses for access control and currently assign addresses via DHCP, there are two kinks in the move to stateful (DHCPv6) address assignment:

1. The DHCPDv6 spec (RFC3315) indicates that a client should be identified by the DUID, IAID pair. There are three types of DUID, and the default one is DUID-LLT, which combines the link-layer address with the DUID creation timestamp. The IAID uniquely identifies one of the client network interfaces. In principle, these numbers are known only once the DHCPv6 client is started. The ISC DHCPd currently provides a “synthetic” way of honoring the MAC-address way of identifying a client that is used for IPv4 (’hardware ethernet’ directive in dhcpd.conf). The mechanics are found in the find_hosts_by_duid_chaddrfunction (dhcpv6.c): the MAC address is extracted out of both DUID-LLT and DUID-LL, discarding unnecessary information. This should cover most practical cases. But there is no exact replacement for this function in Dibbler’s last stable version (0.8.2): the per-host configuration is based on the host DUID (with link-local address coming in a future version). For the time being they recommend to configure clients to use DUID-LL, which may not be a practical option.
2. The multicast of router advertisements (which reverses the DHCP model of trust for the default route info) is currently the only way that IPv6 hosts have to know the default route. No less than five different drafts were proposed to IETF in recent years to allow DHCPv6 to advertise the default route, removing the need to multicast Router Advertisements (draft-droms-dhc-dhcpv6-default-router, draft-sun-mif-address-policy-dhcp6, draft-sarikaya-mif-dhcpv6solution, draft-dec-dhcpv6-route-option, draft-ietf-mif-dhcpv6-route-option). None of these was approved, and the only one still active is the last. There is support for this last draft in the development trees for both dibbler and ISC dhcp, but support in the clients is unlikely unless this becomes an approved standard. The Router Advertisement model, which requires measures to squash rogue advertisements, is another issue requiring to implement measures at the end-link level (RA-guard or similar), as rogue RA squashing daemons may be of limited effectiveness on large networks.