<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">A convincing case for the need of the MAC address in the DHCP packet:</font><div style="color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-size: 10pt; "><br></div><div><font face="'Andale Mono'" size="2">1) we are going to be dual stacking for the foreseeable future (at least 5+ years I would guess).</font></div><div><font face="'Andale Mono'" size="2">2) We are going to have clients that are getting their v4 address via DHCPv4 and their v6 address via DHCPv6</font></div><div><font face="'Andale Mono'" size="2">3) Presently, I cannot in any way see how the client could be tied together. </font></div><div><font face="'Andale Mono'" size="2"><br></font></div><div><font face="'Andale Mono'" size="2">In other words... How could I know that the client that has 1.2.3.4 is the same client that has 1234::fffa? The DHCP server has no information available that would allow this determination presently.</font></div><div><font face="'Andale Mono'" size="2"><br></font></div><div><font face="'Andale Mono'" size="2">MAC addresses in their present format will very likely outlive any dual stacking as a forklift upgrade of all switches internet wide would be required to move to EUI-64 or some other link layer identifier.</font></div><div><font face="'Andale Mono'" size="2"><br></font></div><div><font face="'Andale Mono'" size="2">I just don't understand why it was chosen that mac address (read: link layer identifier) was left out of the DHCPv6 packet. What was the reasoning there? What was the harm in including it? Is it not better to have to much information rather than to little?</font></div><div><font face="'Andale Mono'" size="2"><br></font></div><div><font face="'Andale Mono'" size="2">The link layer identifier can be used to track down the client on the network FAR more easily than either the DUID or IAID both of which can be made up by the client in any way that they see fit (and they are - see windows7 and D-link routers for examples) RFC not withstanding. Further, some have said use the link-local address. That is completely random in the windows7 world. It cannot be decoded back to some useful piece of information.</font></div><div><font face="'Andale Mono'" size="2"><br></font></div><div><font face="'Andale Mono'" size="2">If someone has some idea how one might correlate a DHCPv4 and DHCPv6 client who are one in the same please enlighten me and don't read the rant below :)</font></div><div><font face="'Andale Mono'" size="2"><br></font></div><div><font face="'Andale Mono'" size="2"><rant></font></div><div><font face="'Andale Mono'" size="2"><br></font></div><div><font face="'Andale Mono'" size="2">Now we are left with a crippled standard that is going to make life VERY difficult for administrators who choose to use DHCPv6. As far as I can tell, in the ISP world, this will not really be a choice that we can make. If we want to do anything other than static assignments, DHCPv6 will be required as Prefix Delegation is necessary due to the purposeful lack of NAT in the IPv6 world. A public network MUST be delivered in some way to a home router. Static or Prefix Delegation via DHCPv6 are your choices. I could be wrong, of course, but that is my understanding.</font></div><div><font face="'Andale Mono'" size="2"><br></font></div><div><font face="'Andale Mono'" size="2">Life has been made difficult for administrators due to this. I imagine some will choose to attempt static assignment. Tech support employment should rise dramatically I suppose. Perhaps we should be thankful for the uptick in the job market.</font></div><div><font face="'Andale Mono'" size="2"><br></font></div><div><font face="'Andale Mono'" size="2"></rant><br></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>Cc: </b>"Users of ISC DHCP" <dhcp-users@lists.isc.org><br><b>Sent: </b>Monday, January 23, 2012 2:56:17 PM<br><b>Subject: </b>Re: DHCPv6 and MAC Address inclusion<br><br>
<div>On Jan 23, 2012, at 8:26 PM, "perl-list" <<a href="mailto:perl-list@network1.net" target="_blank">perl-list@network1.net</a>> wrote:<br>
</div>
<div>
<blockquote>
<div>
<div style="font-family: 'Andale Mono'; color: rgb(0, 0, 0); ">
<div style="font-size: 10pt; "><span class="Apple-style-span" style="font-size: small; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); ">Do
we know if the draft document submission to the IETF regarding the inclusion of the link layer address in the DHCPv6 packets that Frank Sweetser mentions was ever done? If so, how was the document received at the IETF?</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
There's certainly interest in this, although it's somewhat sad that DHCPv4 is driving features in DHCPv6.
<div style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">
<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.300781); -webkit-composition-fill-color: rgba(175, 192, 227, 0.234375); -webkit-composition-frame-color: rgba(77, 128, 180, 0.234375);"><br>
</span>
<blockquote>
<div>
<div style="font-family: 'Andale Mono'; color: rgb(0, 0, 0); "></div>
</div>
</blockquote>
</div>
<blockquote>
<div>
<div>
<div><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-size: small; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">Are
they planning to amend DHCPv6 specs with the requirement of the link layer address?</span></div>
</div>
</div>
</blockquote>
<div><br>
</div>
It could never be a requirement, first because it's too late, and second because doing so would create massive interoperability problems. It might be added as an option, though.</div>
<div><br>
<blockquote>
<div>
<div>
<div><span class="Apple-style-span" style="color: rgb(0, 0, 0); font-family: 'Andale Mono'; font-size: small; -webkit-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">I
don't see how we, at our organization, can proceed with IPv6 rollout using DHCPv6 without being able to somehow correlate both a DHCPv4 and DHCPv6 assignment to a single client device. </span></div>
</div>
</div>
</blockquote>
<br>
</div>
<div>Why not? Can you write up a use case that explains the problem that this creates for you? It's important that you say what it is that you can't do without this, not simply say "because I need it," which is unfortunately what we usually hear. The
most convincing argument I've heard for this is that the MAC address is what's printed on the box the device comes in, and you can read it and enter it into your inventory with a bar code scanner. But from the way you said this, it sounds like your use case
is different.</div>
<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></div></body></html>