DHCPv6 client classification based on DUID.

[Ted Lemon]

On Sep 20, 2012, at 1:28 AM, "Рязанцев Андрей" <kardox at mail.ru> wrote:
> 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: 
> 
> 1) for DUID-LLT string, containing its hex-representation comparing substring @[1:4]* with "0001" AND substring@[16:6]* with "080027";
> 2) for DUID-LL string, containing its hex-representation comparing substring @[1:4]* with "0003" AND substring@[8:6]* with "080027";
> // * - @[offset, length]
> 
> should separate clients based on  network device's vendor-code in MAC. Or maybe something changed since that RFC 3315 was written?
> 
> And as for DUID-EN - there is always should be IANA assigned enterprise number. Which also can be extracted and matched.
> 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.
> 
> So am I saying the right things? Or I am missing something?

What you are proposing to do here is exactly what "opaque" is intended to forbid you doing. Your server's behavior would be wrong, because you are attributing meaning to fields in a packet for which no such meaning has been promised.