<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Andale Mono; font-size: 10pt; color: #000000'><br><br><div style="color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-size: 10pt; "><br></div><hr id="zwchr" style="color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-size: 10pt; "><blockquote style="border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica, Arial, sans-serif; font-size: 12pt; "><b>From: </b>"Simon Hobson" <dhcp1@thehobsons.co.uk><br><b>To: </b>"Users of ISC DHCP" <dhcp-users@lists.isc.org><br><b>Sent: </b>Wednesday, January 25, 2012 5:05:29 AM<br><b>Subject: </b>Re: DHCPv6 and MAC Address inclusion<br><span style="font-size: 12pt; "><br></span></blockquote><blockquote style="border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica, Arial, sans-serif; font-size: 12pt; "><span style="font-size: 12pt; ">Lets face it, there are still plenty of </span><br>ways to make a non-compliant implementation - <br>such as splitting an LL or LLT identifier to <br>extract the hardware address, something that is <br>now encouraged by it not being present in the <br>request packets in it's own field/option.<br></blockquote><font face="'andale mono', times" size="2"><div><font face="'andale mono', times" size="2"><br></font></div><div><font face="'andale mono', times" size="2">Simon - thank you for your comments as always they are quite refreshing.</font></div><br></font><div><font face="'andale mono', times" size="2">The above assumes that the DUID will actually contain the MAC address. In my experience, it does not on all systems. </font></div><div><font face="'andale mono', times" size="2"><br></font></div><div><font face="'andale mono', times" size="2">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). </font></div><div><font face="'andale mono', times" size="2"><br></font></div><div><font face="'andale mono', times" size="2">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.</font></div><div><font face="'andale mono', times" size="2"><br></font></div><div><font face="'andale mono', times" size="2">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.</font></div><div><font face="'andale mono', times" size="2"><br></font></div><div><font face="'andale mono', times" size="2">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.</font></div><div><font face="'andale mono', times" size="2"><br></font></div><div><font face="'andale mono', times" size="2"><br></font></div></div></body></html>