How are you doing DHCPv6 ?

Mon Jan 23 22:23:30 UTC 2012

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 at 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 at 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/