How are you doing DHCPv6 ?

Karl Auer kauer at biplane.com.au
Mon Jan 23 16:17:29 CST 2012


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 DUID.
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 NIC
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 biplane.com.au)
http://www.biplane.com.au/kauer

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