DHCPv6 host-identifier, the Never Ending Thread: A Summary

[David Farmer]

Frank,

I would like to invite you to subscribe to the Internet2 IPv6 
Working Group mailing list, especially since WPI is an 
Internet2 member.  But, anyone else interested in IPv6, 
especially in the Research and Education networking world is 
welcome too.

http://ipv6.internet2.edu/
Mailing list details a the bottom of the page.  
And yes you can get to it with IPv6.

You will find lots of support for this work there, moral support at 
least from just about everyone and beyond that from many.  
This issue (DUID without MAC for DHCPv6) came up as an 
OH SH#$! moment, for a bunch of us in the working group 
meeting at Joint Techs in College Station last month.   

By the way, I noticed WPI's main web page is IPv6 accessible.  
Good job, even if it wasn't your personal doing!

On 4 Mar 2009 Frank Sweetser wrote:

> I think at this point, with over 160 emails in the original thread, everyone
> interested in the whole DHCPv6 host identifier issue has had their say (some,
> like myself, more than once) so I thought I'd try to summarize how everyone
> feels, and propose a couple directions to go in from here.  Hopefully this
> will be close enough to a consensus that we can start to work on concrete
> solution, rather than just continue to rehash the same points at each other.
> As Ted has pointed out, we have to deal with the state of things as they are,
> and being "right" won't change anything.
> 
> First, the problem: all of these various network operators have, over the
> years, built up extensive workflows and DHCPv4 configurations using the MAC
> address as the primary client identifier.  With the removal of the client
> address field from DHCPv6, the machines are no longer recognizable by the same
> identifier using current tools, so all of those workflows as they currently
> stand fall apart under IPv6.  This obviously makes the network operators quite
> unhappy.
> 
> There are three general directions that we can go in to restore happiness:
> 
>   - change workflows to accommodate the new DUID feature
>   - modify the DHCP server and relay agent to discover the client MAC
>   - ask the IETF to change the standards going forward
> 
> ------------
> 
> The first option, changing around site workflows to be DUID centric, does not
> appear to have been very popular.  In addition to teaching dhcpd how to pick
> apart the DUID to even begin to handle most sites, this would require anything
> from changing policies about who's granted access to what, to extensive rework
> of internal tools.  Even then, the quirks of the DUID (such as persistence
> across hardware changes) appear to to cause a whole new crop of corner cases
> that admins would prefer to avoid.
> 
> Some places may be able to go down the workflow rework road, but based on
> response, for most sites this would be sufficiently problematic to flat out
> halt IPv6 deployment for at least a year or two.  (Please note that I'm not
> trying to argue whether this is a good idea or not, simply that this is the
> response that I've observed.)
> 
> ------------
> 
> The second option is to attempt a workaround in ISC dhcpd and relay agent to
> figure out the client MAC address on its own, and act as if it were still
> being sent by the client.  This would obviously have some limitations, such as
> possibly only working on ethernet, and wouldn't help any other DHCP servers,
> but I suspect that neither of those limitations will bother anyone in this
> particular discussion overmuch.
> 
> The first and most obvious method would be to extract the MAC address from the
> DUID.  However, the previously discussed corner cases of the DUID not matching
> the sending MAC address make this one an incomplete solution, and probably not
> worth the effort.
> 
> The second method, suggested by David, was to extract the MAC address from the
> EUI-64 link-local address in use by the client.  Unfortunately,
> experimentation showed that Vista/7 generates a purely random link-local,
> rather than use EUI-64, which means that the MAC address is nowhere to be found.
> 
> The third method is to teach the server to just roll up its sleeves and pull
> the client MAC address out of the link layer headers on the received packet.
> The relay agent would be taught to do the same, and then package the MAC up in
> a relay agent option which the server could key off of.  Out of all the
> options, this is probably the least elegant method, and is almost guaranteed
> to have some strange quirks making it harder than it seems at first (for
> example, dealing with unicast packets from clients on remote subnets), but is
> the only one put forward so far that will work in all cases.
> 
> If David amenable to this idea, or has a better idea of how to find the MAC, I
> have a programmer in my group that I can commit to spending some time
> implementing it.  (Having workstudy students is great... =)
> 
> ------------
> 
> The third option is to go through the IETF process, and attempt to create a
> new standard in which clients once again transmit their link layer hardware
> address to the DHCP server.  If this were to happen, and vendors began
> adopting the new standard, network operators would be able to have exactly the
> same workflow on v4 and v6, and peace would reign throughout the land (or at
> least return to levels prior to this discussion).
> 
> Ted's primary objection to this option was that it would be a long process,
> easily taking two or three years, and there's no guarantee that vendors would
> implement it, especially in legacy systems.  I have no doubt that he's
> absolutely correct, but I think that these are only minor deterrences:
> 
>   - Nobody here is desperate to deploy IPv6 next week, at least throughout
> their entire infrastructure, so a couple of years before clients begin showing
> up with the new standard would not be a huge deal.
> 
>   - Right now, only Windows Vista/7 and Linux even support DHCPv6 at all.
> Neither Mac OS 10 nor XP support it, leaving them out of this.  I can't see
> getting support added to the Linux clients as being a huge obstacle, which
> only leaves Windows, and with a published standard and enough customers
> asking, that should be doable as well.
> 
> Putting the link layer address back into the client request at a standards
> level will, I believe, have benefits in the long run that none of the other
> options can achieve.
> 
>   - Assuming that it is widely adopted (I know, this is a big assumption...),
> it means that the same general methodology will be viable even on any future
> networks (note how I specified the link layer address, rather than the
> ethernet MAC address)
> 
>   - By putting it in on the client side, option two doesn't require anything
> special be implemented in the relay agent, meaning that any existing v6 relay
> agents can be used
> 
> The IETF will no doubt be sceptical, and rightly so - I can only imagine the
> quantity of bad ideas that get thrown at them.  Absolute worst case, though,
> they simply say "Nope!", so the only risk to trying this is some lost time.
> 
> Chuck and I are already planning on writing a draft proposal for this (thanks
> again to David for giving us the pointers on getting started).  I would
> strongly urge anyone who's interested to join the dhcwg mailing list and
> contribute.  As Ted said, the IETF is an open organization, and welcomes
> network operators to the process.  You have a voice, use it!
> 
> ------------
> 
> We now return you to your regular schedule of compilation problems and host
> statements placed inside subnet statements.
> 
> -- 
> Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
> WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
>     GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC
> 
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users



================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======