DHCPv6 - Dynamic Host Configuration Protocol for IP version 6
One is tempted to exclaim "DHCPv4 is dead. Long live DHCPv6!" or worse when considerung DHCPv6. With IP address and DNS server configuration being done via autoconfiguration DHCP has lost its two most important reasons for existence. But there are still a few situations in which DHCP might help.
DHCPv6 is not compatible with DHCPv4 - while it is similiar to its older brother, it got a complete overhaul.
DHCPv6 differs from DHCPv4 in several ways. The most obvious is that the protocol is designed to work with the 128 bit addresses of IPv6 instead of the 32 bit addresses of IPv4 and that it works on a IPv6 network instead of an IPv4 network. It is also designed to work together with autoconfiguration - in fact it depends on autoconfiguration to find routers.
DHCPv6 now officially supports what was an addition in DHCPv4: relay servers. Meaning that not every network segment that needs DHCP also needs a full blown DHCP server. This helps to push the configuration to a central place, while the relay servers just make sure DHCP is reachable on their segments.
As with DHCPv4, the DHCPv6 server or relay agent does not need to be identical with the router. But it helps.
There are several implementations of DHCPv6 for Unix/Linux, which differ in style and what features they implement. To name a few full implementations:
As well as my own limited implementation TDHCP.
While DHCPv4 made associations between clients and IP addresses (the so called leases) via the hardware address of the client, DHCPv6 uses a unique identifier that is usually created during installation of the server, relay or client. There are currently three ways to generate a DUID:
LLT is the default for DHCPv6 - during the installation any link layer address (ie. a MAC) is chosen and the Unix timestamp of the installation is added. This should be reasonably unique for almost any purpose (except if the device and installation is cloned).
LL can be chosen by devices that cannot store a timestamp, but have a reasonable way of always chosing the same link layer address. This may be true for some cable or DSL routers.
EN is most likely to be found in big organisations. Any organisation can request an enterprise ID (PEN) from IANA. The admin then adds some arbitrary, but unique, value to the configuration to make each entity in the network unique.
DHCPv6 can assign IPv6 addresses to hosts, either from a pool of addresses or explicitly via the hosts DUID or (in some implementations) some other criteria. There are only very few exceptional situations in which this might be desirable:
This feature pretty much works as with DHCPv4 as far as the address assignment itself is concerned - the server needs to know the pool or direct assignment and the client needs to have a DHCPv6 client installed (which is already one more step than autoconfiguration). The routing part is different: DHCPv6 does not have a router option - the client is expected to get this through autoconfiguration (see the articles on autoconfiguration and routers on how to influence the hosts behavior).
One of the main reasons to develop DHCPv6 was that router advertisements were initially not able to transport the IP addresses of local DNS servers. Since this has been fixed DHCP server optios are more or less of academic interest.
Currently these server types can be advertised through DHCPv6:
Why anyone would bother to setup DHCP to configure NIS (which is sensitive enough to do it manually and usually needs only one central server per organisation) and NTP (which does have a fixed multicast and does not change much anyway) is beyond my understanding, but it may be nice to play with it and might be useful under some rare circumstances.
DHCP servers and relay agents can (if implemented) exchange some information with RADIUS servers.
A new and quite curious feature of DHCPv6 is prefix delegation. This feature allows two scenarios: server hierarchies and router configuration. Usually both scenarios will be combined.
In some of the bigger organisations the main DHCP server will know only the structure of some parts of the network (for example the backbone and the IT departments PCs) that it can service directly or through relays. While the DHCP servers in independent departments may know the department structure, but will be unaware of any prefix changes if for example the company decides to change providers.
With prefix delegation the main server will service its directly connected network and delegate some network prefixes to the department servers, while the department servers will ask the main server for the current prefix and then fill in the details they know about their networks structure.
A network router can use prefix delegation information to set itself up: it asks its upstream DHCP server for its own network prefix and then configures its own network devices with sub-nets of the delegated prefix.
There are two situations in which this may be helpful: the DHCP-typical scenario would be a department router that retrieves its configuration from the main company router and DHCP server. Another scenario would be a company or home router that requests its network prefix from the providers router via DHCP prefix delegation.
The example above shows a possible setup for a big organisation. I assume here that the routers are also DHCP servers - if not every yellow box must be doubled (one for the router and one for the DHCP server/agent on the same link). Arrows point from server to relay agent to client - ie. they show from where to where configuration information is pushed - requests run in the opposite direction.
PD(1) - the provider tells the company about its routable network via prefix delegation. For example the PPP link could use 2001:db8:1::1 and 2001:db8:1::2 for its two end-points and the provider could tell the company to use 2001:db8:2::/48 internally.
Main Router - in this example the main router knows about systems connected directly to the backbone (PC-1 and PC-2) and the structure of the IT network.
IT Router - if the IT network is a separate link (which it will usually be) it needs its own router and a local DHCP relay. This DHCP relay agent will look just like a regular server to its own clients (PC-3), while delegation all requests to the main server. For example the main server could be configured to hand the relay agent addresses from the 2001:db8:2:1::/64 pool while using the 2001:db8:2:0::/64 pool for its own clients.
Dep-2 Router: this is the slightly easier one - it is connected directly to the backbone and hence asks the main server for its subnet prefix. For example the main server could hand it the 2001:db8:2:300::/56 prefix - the department router is then free to split this network into 256 /64 prefixes which it can use inside its department.
Dep-1 Router: this one is connected indirectly through the IT network - hence it asks the relay agent for its prefix, which in turn asks the main server. Let's assume that the main server routes 2001:db8:2:400::/56 through the IT router to the department 1 network and also hands this prefix through the relay agent to the department server. The department server is now again free to split its prefix up into 256 subnets that it can use internally.