The requirement of the DUID is a big hurdle to DHCPv6 adoption, I agree. Currently, a DUID can be generated in 1 of 3 ways, 2 of which include _any_ MAC address of the system at the time of generation. After that, the DUID is stored in software. The idea is that the DUID identifies the system and the IAID identifies the interface, and that over time, the system will keep its DUID even if the network adapter changes. This is obviously different from how we use DHCP for legacy IP. There are a few problems as a result: 1. Systems that are built using disk images can all have the same DUID unless the admin takes care to remove any generated DUID on the image (already see this on Windows 7 and even Linux). 2. Networks where the MAC addresses for systems are already known can’t simply build a DHCPv6 configuration based on those MACs. If someone were to modify DHCPv6 to address these concerns, I think the easiest way to do so would be to extend DHCPv6 relay messages to include the MAC address of the system making the request (DHCPv6 servers on local sub-networks would be able to determine the MAC from the packet). This would allow transitional DHCPv6 configurations to be built on MAC addresses rather than DUID without client modification (which is key). Perhaps this is already possible through the use of RFC 6422 (which shouldn’t break anything). I think more important, though, is a good DHCPv6 server implementation with verbose logging capabilities, and the ability to specify a DUID, DUID+IAID, or MAC for static assignments. I know there are people from ISC on-list. It would be great to hear someone who works on DHCPd chime in. How about we start with modifying ISC DHCPd for IPv6 to have proper logging and support for configuring IAID, then work on the MAC awareness piece. ISC DHCPd makes use of RAW sockets, so it should always have the MAC for a non-relayed request. Then we just need to work with router vendors on adding MACs as a relay option. On Mon, Jan 23, 2012 at 2:44 PM, Randy Carpenter <rcarpen@network1.net> wrote:
We have also recently realized that the DUID is pretty much completely random, and there is no way to tie the MAC address to a client. This pretty much makes it impossible to manage a large customer base.
-Randy
----- Original Message -----
This is a problem that would be nice for ISC to resolve (or another dependable FOSS implementation).
For a while now (about 20 years I believe) we've used ISC DHCPd in a distributed model for our public IPv4 space. In a nutshell, each DHCP server is configured only with static assignments, their log files are monitored (simple event correlator), and scripts are fired off to perform tasks like new assignments against a centralized database (MySQL). The database is responsible for keeping track of address assignments centrally and is used to generate configuration files for DHCPd. Dynamic updates are made using OMAPI.
Unfortunately, the ISC DHCPv6 implementation makes replicating this impossible due to the lack of information logged.
Another problem with the ISC DHCPv6 implementation is that it doesn't allow you to assign fixed-address information based on the DUID _and_ IAID, which becomes a problem when a host has more than one active adapter.
The only options are hacking the source code if you feel comfortable doing so, or waiting for ISC to make the change (if they ever plan to).
For now, we get by with static assignments made in the database and no dynamic allocation via DHCPv6, which does OK in a dual-stack environment where IPv6 isn't considered necessary yet, but in the near future that will change.
On Tue, Jan 17, 2012 at 5:04 PM, Randy Carpenter <rcarpen@network1.net> wrote:
I am wondering how people out there are using DHCPv6 to handle assigning prefixes to end users.
We have a requirement for it to be a redundant server that is centrally located. DHCPv6 will be relayed from each customer access segment.
We have been looking at using ISC dhcpd, as that is what we use for v4. However, it currently does not support any redundancy. It also does not do very much useful logging for DHCPv6 requests. Certainly not enough to keep track of users and devices.
So, my questions are:
How are you doing DHCPv6 with Prefix Delegation?
What software are you using?
When DHCPv6 with Prefix Delegation seems to be about the only way to deploy IPv6 to end users in a generic device-agnostic fashion, I am wondering why it is so difficult to find a working solution.
thanks, -Randy
-- | Randy Carpenter | Vice President - IT Services | Red Hat Certified Engineer | First Network Group, Inc. | (800)578-6381, Opt. 1 ----
-- Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
-- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/