How are you doing DHCPv6 ?

Tue Jan 24 08:17:33 UTC 2012

Hi Randy

On Mon, 23 Jan 2012, Randy Carpenter wrote:

>
> 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?

There are several possible DUIDs exist:
DUID-LLT, DUID-EN, DUID-LL - have a look at slide 36 and 37 at
https://openwiki.uninett.no//_media/geantcampus:2011-gn3na3t4-ipv6-mohacsi.pdf
or section 9. of RFC 3315:
http://tools.ietf.org/html/rfc3315#section-9

You should use DUID type 3 which is tied to MAC address in case of 
Ethernet. So it is not random. You should warn your device vendors that 
they should use DUID-LL (or type 3) as a default - or should be 
able to preconfigure to use DUID-LL.

In reality some vendors - due to some lazyness? - only implement DUID-LLT 
(or type 1) and sometimes does not store the first time value - therefore 
generated  again and again - seemingly generating pseudo random DUID. 
However DUID-LLT has a structure:
http://tools.ietf.org/html/rfc3315#section-9.1

Best Regards,
 		Janos Mohacsi

>
> -Randy
>
>
> ----- 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
>> 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
>>
>>
>>
>>
>
>