<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Andale Mono; font-size: 10pt; color: #000000'><font face="'Andale Mono'" size="2">Please see responses inline.</font><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>"Ted Lemon" <Ted.Lemon@nominum.com><br><b>To: </b>"Users of ISC DHCP" <dhcp-users@lists.isc.org><br><b>Sent: </b>Wednesday, January 25, 2012 3:36:16 PM<br><b>Subject: </b>Re: DHCPv6 and MAC Address inclusion<br><br>
<div>
<div class="">On Jan 24, 2012, at 9:39 PM, perl-list wrote:</div>
<blockquote><span style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; " class="Apple-style-span">
<div class="">
<div style="font-family: 'Andale Mono'; font-size: 10pt; color: rgb(0, 0, 0); " class="">
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"</div>
</div>
</span></blockquote>
<div><br>
</div>
Why is re-authenticating them bad? Don't you need to do this whenever they change their hardware anyway?</div><div><br></div></blockquote><font face="'andale mono', times" size="2">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.</font><br><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; ">
<div><br>
</div>
<div>
<blockquote><span class="Apple-style-span" style="font-family: 'Andale Mono'; font-size: 13px; ">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...</span></blockquote>
<div><br>
</div>
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.</div><div><br></div></blockquote><font face="'andale mono', times" size="2">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.</font><br><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; ">
<div><br>
<blockquote><span class="Apple-style-span" style="font-family: 'Andale Mono'; font-size: 13px; ">We could potentially track it down using the IP address, although in the case of some DSLAMS this may not be possible.</span></blockquote>
<div><br>
</div>
Doesn't the DSLAM send relay information? Can't you identify the DSLAM from that?</div><div><br></div></blockquote><font face="'andale mono', times" size="2">Not all DSLAMs do this ... no.</font><br><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; ">
<div><br>
<blockquote><span class="Apple-style-span" style="font-family: 'Andale Mono'; font-size: 13px; ">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).</span></blockquote>
<div><br>
</div>
Windows was the first OS to use this option. But perhaps they switched to using the client FQDN option instead?</div>
<div><br>
<blockquote><span class="Apple-style-span" style="font-family: 'Andale Mono'; font-size: 13px; ">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.</span></blockquote>
<div><br>
</div>
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.</div><div><br></div></blockquote><font face="'andale mono', times" size="2">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.</font><br><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; ">
<div><br>
<blockquote><span style="border-collapse: separate; font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; " class="Apple-style-span">
<div class="">
<div style="font-family: 'Andale Mono'; font-size: 10pt; color: rgb(0, 0, 0); " class="">
<div class="">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.</div>
</div>
</div>
</span></blockquote>
<div><br>
</div>
The DUID is required to be stable. If you're not seeing stable DUIDs from clients, those clients are not implementing RFC3315.</div><div><br></div></blockquote><font face="'andale mono', times" size="2">It isn't a question of stable on an individual client, it is a question of predictable across multiple clients.</font><br><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; ">
<div><br>
<blockquote><span class="Apple-style-span" style="font-family: 'Andale Mono'; font-size: 13px; ">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. </span></blockquote>
<div><br>
</div>
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.</div><div><br></div></blockquote><font face="'andale mono', times" size="2">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.</font><br><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; ">
<div><br>
</div>
<br>_______________________________________________<br>dhcp-users mailing list<br>dhcp-users@lists.isc.org<br>https://lists.isc.org/mailman/listinfo/dhcp-users</blockquote><br></div></body></html>