DHCPv6 and MAC Address inclusion

[perl-list]

Please see responses inline. 

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

> From: "Ted Lemon" <Ted.Lemon at nominum.com>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Sent: Wednesday, January 25, 2012 3:36:16 PM
> Subject: Re: DHCPv6 and MAC Address inclusion

> 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?

Authenticating them once is fine. We are talking twice here since the customer will have to authenticate the DHCPv4 and the DHCPv6 since there isn't a way to tell that they are the same device. 

> > 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.

And why should anyone care about a DUID and IAID and whether they are present or not? These bits of info are not necessary for networking to function. 

> > 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?

Not all DSLAMs do this ... no. 

> > 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 seriously doubt anyone is going to change the format / generation logic of the UID from DHCPv4 on their client. That would be a great solution in the case it were done. 

> > 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.

It isn't a question of stable on an individual client, it is a question of predictable across multiple clients. 

> > 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.

This information is not always available. Not all DSLAMs support this. Not all relay agents support this. Authentication of some kind must be used in most cases save cable modems. 

> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120125/6902658f/attachment.html>