How are you doing DHCPv6 ?

Randy Carpenter rcarpen at
Mon Jan 23 22:26:32 UTC 2012

One major issue is that there is no way to associate a user's MAC (for IPv4) with their DUID. I haven't been able to find a way to account for this without making the user authenticate once for IPv4, and then again for IPv6. This is cumbersome to the user. Also, in the past there have been various reason why we want to pre-authenticate a client's MAC address (mostly for game consoles, and such, which have the MAC written on the outside of the machine). How can this be done with IPv6, which the DUID is not constant?


----- Original Message -----
> On Mon, 2012-01-23 at 14:44 -0500, Randy Carpenter 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.
> Not sure about that. The DUID is not random, at least not if it is
> being
> generated according to RFC 3315, which it probably should be.
> A DUID should be generated by a client[1] the first time it needs
> one,
> then be stored and never change[2]. All clients are supposed to
> provide
> a mechanism for setting the DUID to a specific value. Once generated,
> the DUID is indeed tied to the client unless something intervenes. In
> particular, a DUID is not affected by a change of NIC and is
> identical
> for all connected interfaces.
> I have to confess that we are not actually doing it, but the plan[3]
> is
> to capture new DUIDs as they happen and record the address->DUID
> mapping
> in our database. That's pretty much what we do now for boxes where
> the
> MAC address is not printed on the outside! But only where we need a
> reservation.
> The servers we use will always give the same address to the same
> Since we do not expect to use actual reserved addresses very much,
> this
> should be all we need. We are a) not really a large enterprise and b)
> not an ISP or carrier, so perhaps our needs are not the same as those
> you envisage.
> Vendors delivering pre-installed operating systems can set up
> vendor-assigned unique DUIDs and print them on the box, much as MAC
> addresses now are.
> It seems to me that DUIDs are better handles for clients than MAC
> addresses, but will require a change in the way people do things.
> Regards, K.
> [1] The algorithm for generating the DUID can include the MAC of any
> available interface, the time of day etc, but is supposed to be
> treated
> as opaque (RFC3315, section 9). Since RFC 3315 defines precisely how
> the
> DUIDs are to be generated, it should be very easy to extract the MAC
> address part, but given that the MAC address used may not actually
> exist
> on the device any more, I'm not sure that's very useful. It might be
> useful the first time a new DUID is seen, on the assumption that the
> was not changed before the machine was first run. Then one could note
> the MAC address when provisioning the machine, and recognise the DUID
> of
> that machine when it pops up on the network. Mind you, the assumption
> is
> not foolproof.
> [2] Obviously devices with no long-term storage (or no storage at al!
> -
> will use a different generation algorithm than ones that do have
> storage.
> [2] "No battle plan survives contact with the enemy" - Helmuth von
> Moltke the Elder.
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Karl Auer (kauer at
> GPG fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017
> Old fingerprint: DA41 51B1 1481 16E1 F7E2 B2E9 3007 14ED 5736 F687

More information about the NANOG mailing list