DHCPv6 and MAC Address inclusion

[perl-list]

A convincing case for the need of the MAC address in the DHCP packet: 

1) we are going to be dual stacking for the foreseeable future (at least 5+ years I would guess). 
2) We are going to have clients that are getting their v4 address via DHCPv4 and their v6 address via DHCPv6 
3) Presently, I cannot in any way see how the client could be tied together. 

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. 

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. 

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? 

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. 

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 :) 

<rant> 

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. 

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. 

</rant> 

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

> From: "Ted Lemon" <Ted.Lemon at nominum.com>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Cc: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Sent: Monday, January 23, 2012 2:56:17 PM
> Subject: Re: DHCPv6 and MAC Address inclusion

> On Jan 23, 2012, at 8:26 PM, "perl-list" < perl-list at network1.net >
> wrote:

> > 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?
> 
> There's certainly interest in this, although it's somewhat sad that
> DHCPv4 is driving features in DHCPv6.

> > Are they planning to amend DHCPv6 specs with the requirement of the
> > link layer address?
> 
> 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.

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

> _______________________________________________
> 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/20120124/c56371aa/attachment.html>