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

[Frank Sweetser]

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