Re: How are you doing DHCPv6 ?

[Mohacsi Janos <mohacsi () niif hu>]

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 () 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