host-identifier with IPv6

[Frank Sweetser]

Ted Lemon wrote:
> On Mar 3, 2009, at 2:25 PM, Frank Sweetser wrote:
>> Between the DUID only including one MAC address of a
>> multi-homed machine, and the fact that Vista doesn't use the EUI-64 
>> link-local
>> address when communicating with the DHCPv6 server, it seems inevitable 
>> to me
>> that there are going to be plenty of instances where the originating MAC
>> address is nowhere to be seen in the packet once it goes through a relay.
> 
> Okay, so can you clarify for me please why it's the case that when you 
> have a multi-homed machine, it's a problem that it only reports one of 
> its mac addresses in the DUID?   Why is one not sufficient?   Why do you 
> need the other?   I'm not telling you you don't need it - I'm just 
> asking why.

Primarily because you don't know which one will get reported.  If I have a 
wired and a wireless adapter, how do I know which one I should register?  And 
if I wipe the system and put a new OS image on it, will it pick the same 
adapter as the previous one?

A big piece of what's throwing everyone for a loop here is a (relative) lack 
of stability.  With the MAC based v4 behavior, it was quite simple for an 
admin to quickly look at a machine, and, based on the centralized DHCP server 
configuration, tell exactly what would happen to that machine on any subnet. 
Similarly, you could take an IP address, look it up in the DHCP lease 
database, and know exactly which interface, and therefore which host, was 
assigned that IP address.

If there were rules added in place defining which MAC address must be used to 
generate the DUID (lowest value, highest bandwidth, manufacture date - the 
exact rules don't matter so long as they're deterministic), that would help, 
because (assuming that the DHCP server began extracting the MAC address from 
the DUID) that chain from MAC address to software policy could be restored.

There would still be some transition pains which having either all of the MAC 
addresses, or the interface MAC address, would help with.  Right now, on a 
laptop the wired and wireless interfaces must be registered with DHCP 
separately.  Having each interface use the same DUID, but still indicate their 
respective MAC addresses, would give the administrator the option of matching 
the old DHCPv4 behavior as closely as possible.

Oh, and another minor case: on our wireless network, I have our radius servers 
configured to only accept authentication requests from MAC addresses 
registered as wireless.  True MAC addresses can be spoofed, but 1) it prevents 
the neighborhood riff-raff from trying to brute force their way in, and 2) it 
allows us to selectively block virus infected machines from connecting.

>> As a long term solution, how would you feel about a proposal to add a new
>> DHCPv6 field containing the link-layer address on which the packet was 
>> sent?
>> This could, from the protocol point of view, be sent as a simple 
>> informational
>> attribute, with no guarantee of uniqueness, while the DUID semantics 
>> remain
>> unchanged.  If I've understood your other comments correctly, this 
>> means that
>> the DUID could still be used as the primary identifier, but the DHCP 
>> server
>> would optionally be able to use the link-layer address, if present, as an
>> input to administratively configured policy decisions about which 
>> options and
>> values should be handed back to the client.
> 
> I think two things.   First, I think that it won't be implemented, 
> because it's not required for the protocol to work.   Second, I don't 
> think the IETF would adopt it, because it's not required for the 
> protocol to work, and I don't think you can come up with a convincing 
> use case (I've been trying to get someone to give me one, and I haven't 
> heard one yet).

Can you give me a rough idea of what a convincing use case might look like?

>> This should let those of us with MAC centric workflows (including 
>> many, many
>> EDU networks) migrate to IPv6 with far less pain and suffering, while 
>> still
>> leaving the million client per server ISPs able to freely ignore the 
>> MAC address.
> 
> This is going to sound callous.   Please don't take it that way - I'm 
> asking this question sincerely.   I do not understand why you have a 

Quite the opposite!  I'm viewing this as a learning experience all around, and 
often times blunt questions are the best way to reveal hidden assumptions you 
didn't even know you were making.  Please feel free to throw these questions 
at me, as it probably means that either I haven't communicated effectively, or 
there's something I've flat out misunderstood.

> "mac-centric workflow."   I do not understand why you think not using 
> the Mac address is going to be a source of such pain.   You call it a 
> "showstopper."   That's *astonishing* to me.
> 
> To me, the idea of tracking every mac address of every device on a 
> network by walking around with a keyboard or a bar-code scanner and 
> entering them all into a database is the very definition of "pain and 
> suffering." DHCP's whole raison-d'être is to save you, the network 
> administrator, the effort of walking around doing a manual process on 
> each machine.

I completely agree with this goal here.  We have very few full time IT staff 
here who can directly support computers, so the more time we have to spend 
babysitting each machine in person, the less time we have to spend on more 
useful projects.

> So why is it that you have chosen this model - what is the value that it 
> adds, and why is it that there is no better solution that involves less 
> work?

Tracking the MAC address of every machine on the network is certainly a fair 
bit of work, at least at first, but 1) extensive use of self-service means 
that the students can manage their own machines, taking a huge amount of churn 
off the shoulders of IT, and 2) once the database is in place, it's not as 
much work as you'd think to keep it up to date, and 3) once it's done, it pays 
off for itself 50 times over in other steps of the workflow.

I think a big piece of the miscommunication going on here is that when I say 
that removing the MAC from client DHCP packets will cause me more work, I'm 
not clearly defining the scope of that work.  A lot of the work doesn't show 
up in the actual scope of the DHCP protocol itself.  It's all of the other 
things we have to do to and with machines that have, over the years, been 
built up around the way that DHCPv4 works, and the ability to use the MAC 
address as a primary key.

Let me give you an example: upgrading the machines in a computer lab.  Right 
now, it typically looks something like this:

  - pallet of new computers shows up on the loading dock
  - each machine is unpacked, labeled with its hostname, and MAC is recorded
  - machine records are updated with replacement MAC (about 15 seconds each)
  - machines are physically installed
  - each machine is powered on, PXE boots, and unattended installed
  - machine looks up hostname from IP
  - hostname is used to determine which policies to apply, turning it into a 
full fledged lab computer

Without the ability to fix the IP address to the MAC address, DHCP will 
certainly still be able of giving it a perfectly usable IP configuration. 
What is lost, though, is the ability to install and configure a machine (or a 
whole lab of them) by just telling a student worker to run through all of the 
machines hitting reset buttons and F12.  Instead, someone has to go through 
and somehow manually tell each machine what its identity should be.

I'd also like to point out that, at least in the EDU IT management space, 
we're pretty typical.  These systems have, in a wonderful example of 
convergent evolution, simultaneously appeared in many schools with similar 
goals and resource constraints.  If you haven't seen it, the NetReg host 
registration system from Southwestern is very popular for tracking MAC 
addresses, and generating DNS and DHCP configs from the database.

If you have an alternate suggestion of how I might be able to recreate this 
workflow without recording and tracking the MAC address, though, I'd certainly 
be interested in hearing it.

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