<HTML><BODY><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;" class="mailru-blockquote"><div id=""><div class="js-helper js-readmsg-msg"><div id="style_13480949000000000300" class="mr_read__body"><div id="style_13480949000000000300_BODY">Let me state the problem differently, as I understand it: The client ID doesn't have to contain the client's MAC address, and does not reliably follow any pattern whatsoever across all implementations. Therefore, parsing the client ID to find the MAC address is not a reliable method.<br>
<br>
Chris Buxton<br>
BlueCat Networks<br>
</div>
                        <div>_______________________________________________<br>
dhcp-users mailing list<br>
<a href="sentmsg?compose&To=dhcp%2dusers@lists.isc.org">dhcp-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/dhcp-users" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
</div>
                
                <base target="_self" href="https://e.mail.ru/cgi-bin/">
        </div>

        
</div>







</div>
</blockquote><br>Well thats confusing a little bit. I was hoping that most of the clients should obey dhcpv6 protocol as stated in RFC 3315. And that document says that DUID types 0x1 and 0x3 are containing link-layer address. That's why I think that following wildcards like "0001*080027*" and "0003*080027*" should do the trick. Or in case of isc-dhcpd we can still use character offsets because DUID has a few types only, it has a structured header and all conditions like: <br><br>1) for DUID-LLT string, containing its hex-representation comparing substring @[1:4]* with "0001" AND substring@[16:6]* with "080027";<br>2) for DUID-LL string, containing its hex-representation comparing substring @[1:4]* with "0003" AND substring@[8:6]* with "080027";<br>// * - @[offset, length]<br><br>should separate clients based on  network device's vendor-code in MAC. Or maybe something changed since that RFC 3315 was written?<br><br>And as for DUID-EN - there is always should be IANA assigned enterprise number. Which also can be extracted and matched.<br>And those clients who put some random stuff in solicit packets or overriden their manufacturer's hardware addresses - I think should be discarded or assigned some general class and general ipv6 address.<br><br>So am I saying the right things? Or I am missing something?</BODY></HTML>