DHCPv6 and MAC Address inclusion

[perl-list]

----- Original Message -----

> From: "Simon Hobson" <dhcp1 at thehobsons.co.uk>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Sent: Wednesday, January 25, 2012 5:05:29 AM
> Subject: Re: DHCPv6 and MAC Address inclusion

> Lets face it, there are still plenty of
> ways to make a non-compliant implementation -
> such as splitting an LL or LLT identifier to
> extract the hardware address, something that is
> now encouraged by it not being present in the
> request packets in it's own field/option.

Simon - thank you for your comments as always they are quite refreshing. 

The above assumes that the DUID will actually contain the MAC address. In my experience, it does not on all systems. 

We are left with attempting to identify a client based on information that is not necessary for the client to transmit and receive on the network. Letting the client make up bits of information that are to be used to identify them certainly doesn't sound like a good foundation for good security practice. I realize that the RFCs say that the client must make up the DUID in one of three ways. In practice however there is no way to enforce this. A DUID could be made up based on the current astrological positions as long as it follows the correct format (and I'm not even sure how loosely the format is restricted). 

With DHCPv4 we could identify the client with two pieces of information that were necessary to transmit on the network not only one (IP Address). Further, we could decide to allow them on the network based on one piece of information that they needed to talk on the network prior to receiving the second bit of information - the IP Address. The DUID? Well ... since it is not necessary for any sort of communication, it cannot be enforced. 

I understand where some of this is coming from. Academic vs. Operational philosophy . Academics are nice, but if the system that is cooked up is not useable by the operational people, it will not be used. If the academics are resistant to suggestion from the operational people, then we will have to wait until some large operational people such as Microsoft or Cisco come up with a solution and use their clout to push it through. 

BTW: people on the NANOG list are advocating splitting the mac from the LL or LLT identifier as mentioned above for subscriber identification as they, being operational, recognize the importance of identifying that the DHCPv6 and DHCPv4 client are one in the same. We have pointed out to them that this will not work in all cases and there is much renewed head scratching. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120125/25b41327/attachment.html>