DHCPv6 and MAC Address inclusion

[Ted Lemon]

On Jan 24, 2012, at 9:39 PM, perl-list wrote:
For subscriber identification.  We have the subscribers easily identified in DHCPv4.  Short of requiring them to authenticate themselves a second time, I am not seeing how we can identify them in DHCPv6 using their DHCPv4 "knownness"

Why is re-authenticating them bad?  Don't you need to do this whenever they change their hardware anyway?

If the MAC were there, how would that break things specifically counting on it?  Has the MAC address been deemed something evil?  We know they are going to continue to exist as long as devices continue to send ethernet frames...

No, the MAC address isn't evil, but if it could be assumed to be present in every DHCP message from a client, non-conforming implementations would start depending on it, and then DUID would stop working.   You have to understand that it is a rare implementor who reads specifications carefully.   Normally people just do an implementation that's what they thought they read, and then try it.   If everything out there has a MAC address option, you can be sure that implementations will appear that will use it as the sole identifier and will ignore the DUID and IAID.

We could potentially track it down using the IP address, although in the case of some DSLAMS this may not be possible.

Doesn't the DSLAM send relay information?   Can't you identify the DSLAM from that?

Experience has shown that some clients do not implement the hostname as given by DHCPv4 (specifically, I believe, windows doesn't care about the hostname - as far as I have seen only MacOS and Linux cares about this option).

Windows was the first OS to use this option.   But perhaps they switched to using the client FQDN option instead?

Please understand - I wasn't advocating a return to NAT.  I was just lamenting that we ISPs are going to HAVE to use DHCPv6 is far as I can tell, at least for prefix delegation.  We MUST be able to correlate the identity of a client device or allocated subnet to a customer, at least in the USA.

Right, and you have the tools to do that.   What you are missing is the dual-stack tool that allows you to correlate the DHCPv4 client to the DHCPv6 client, because (AFAIK) nobody's ever implemented RFC 4361.

I am most certainly experiencing as you say FUD mostly because I am attempting to setup a test environment showing how we could move ahead with DHCPv6 rollout ahead of the coming IP exhaustion in 2013.  The state of things currently have left me scratching my head and adding to the baldness.  I am able to lease IP addresses and delegate prefixes easily enough.  I have not been able to find some predictable piece of information, even in packet dumps, that could be used to correlate devices to subscribers consistently in DHCPv6.

The DUID is required to be stable.   If you're not seeing stable DUIDs from clients, those clients are not implementing RFC3315.

We have an employee who goes to NANOG and ARIN meetings.  All of the administrators that he has run into that are actually doing something with IPv6 are not doing so for end users quite yet.  Most of them have test environments running , or are providing DHCPv6 on a non-hostile network.  The vast majority are doing DHCPv6 (or - egads - SLAAC) directly from the router in an anonymous way.  This obviously will not work in a hostile environment such as an ISP.

Most ISPs use relay id options to identify the CPE, not MAC addresses.   CableLabs, Broadband Forum and 3GPP all have specifications for how this works.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120125/6ab198fd/attachment.html>