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

Sat Mar 7 17:32:27 UTC 2009

Frank, et al,

I planned on participating in the 160+ email thread but got tied up.

For what it is worth as someone leading a large IPv6 effort where, as  
you stated below, MAC addresses are leveraged extensively I can tell  
you how I handled this issue.

When we specified the use of DHCPv6 in DOCSIS 3.0 we of course  
leveraged vendor information options.  In these options as you will  
see if you read the DOCSIS specifications we made provisions to carry  
the MAC address of the device that adheres to this specification.   
This is one part of the equation.  I also had to make sure that the  
necessary back office systems, DHCP for example, account for the  
presence of these options to support the deployment.

If you wish I would be willing to discuss further offline.

Regards,

John
===============================================
John Jason Brzozowski
jjmb at jjmb.com
(p) 484-994-6787
(f) 610-616-4535
===============================================

On Mar 4, 2009, at 6:05 PM, 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
>