DHCPv6 and MAC Address inclusion

scott_stone at trendmicro.com scott_stone at trendmicro.com
Tue Jan 24 23:25:18 UTC 2012


here's our situation.  We have datacenters all over.  We have maybe 1 guy who is local on-site, all our other ops people are thousands of miles away.  We rack 100 servers, let's say.  mostly this is done by consultants who go in and rack and cable things.  We assign static IPMI IP addresses based on rack location, so that's all our ops people know.

Now they go to inventory all these machines - they boot them through the IPMI console into a minimal linux environment of my own design that inventories the hardware and sends an xmlrpc call to our inventory database with this info.  So now these 100 anonymous machines are identifiable on the network.. how?  they have no hostname, no operating system with a DUID, only the interface MAC addresses to uniquely identify them.  This is where DHCPv4 works well, the ops people can then go into our database and find the unprovisioned hosts by MAC, and assign IP/hostname info.  The automation then populates DHCPv4 and DNS tables with the appropriate information, and the machines can then be kickstarted with their correct network values set.


Trying to use DHCPv6 creates a chicken/egg issue for us where the DUID is not known ahead of the OS installation - that wouldn't be such a big problem even if we had a way of knowing what that DUID would be - but it appears to be random, at least in the way that CentOS/RH have implemented the client side (and windows server 2008.  2003 "solves" the issue by not supporting DHCPv6 at all, according to our windows admins).

So now I have 100 machines booted with completely random DUIDs and no automated way to assign IPs except to have someone log in again on the IPMI console, record this, populate the database manually, etc.  I could have an automated on-firstboot tool gather the DUID and push it to the DB.. but I'm still stuck with a single per-host ID that won't work on my multiple-NIC machines -- and so far I don't see that the clients are generating unique per-interface IAIDs *at all*, nor do I see a way to do it without modifying the dhcpv6 client (which I can do on RH, but not on Windows).

am I missing something here in terms of how this client and this server are implemented...?

====================
Scott Stone <scott_stone at trendmicro.com>
Manager, DCS-RD
Trend Micro, Inc. http://www.trendmicro.com


-----Original Message-----
From: dhcp-users-bounces+scott_stone=trendmicro.com at lists.isc.org [mailto:dhcp-users-bounces+scott_stone=trendmicro.com at lists.isc.org] On Behalf Of Ted Lemon
Sent: Tuesday, January 24, 2012 3:12 PM
To: Users of ISC DHCP
Subject: Re: DHCPv6 and MAC Address inclusion

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.

_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.




More information about the dhcp-users mailing list