DHCPv6 and MAC Address inclusion

[Ted Lemon]

On Jan 24, 2012, at 9:27 AM, perl-list wrote:
> 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.

Why do you care?

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

If you can count on the MAC address being there, you can use it as an identifier in a non-conforming DHCPv6 implementation.   We didn't want that, so we couldn't specify it in such a way that that would be possible.   I've got nothing against an option that includes this information, as long as it's not required, and hence can't be counted on. 

> 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 you have a device on the wire talking to the DHCP server, why don't you have enough information to track it down from the relay agent 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 :)

Look at the hostname option?

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

It's not been our goal to make it easy for you to deliver a broken network.   NAT is a really, really bad thing for the Internet.   PD is intended to give ISPs the same experience as NAT, without the crappy brokenness that NAT causes.   There's a spec that defines what a v6 home gateway ought to look like, that gives you all the security that NAT got you, plus some more, and supports prefix delegation.

I get the sense that you're experiencing a bit of fear, uncertainty and doubt about the IPv6 transition.   This is entirely understandable, but I don't think it's as bad as you imagine.   You might benefit from hanging out with some people who are actually delivering DHCPv6 today and learning how they are doing it.   Go to the IETF, or NANOG, or find someone to visit.   It may be that there is something that needs to be fixed that we haven't thought of (I happen to know that multihoming is broken, but that's not what you're complaining about).   If so, it's going to be easier to get some clarity on that in a face to face setting at IETF than in a conversation on this mailing list.