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.p... 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@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