host-identifier with IPv6

[Frank Sweetser]

Ted Lemon wrote:
> On Mar 1, 2009, at 7:52 PM, Frank Sweetser wrote:
>> And what if, rather than a fixed address, the address assignment were a
>> dynamic one?  In DHCPv4, the client would get a different address, but a
>> number of people would be happy if it were legal for it to get the 
>> same one
>> instead.
> 
> Two things.   First of all, implementors are encouraged to provide ways 
> for things like DUIDs to be known by all the protocol agents that might 
> use them.   But of course we have no control over what implementors 
> actually do.
> 
> Secondly, with DHCPv6, there simply isn't a shortage of IP addresses.   
> So if you set an artificial goal of absolutely never having a client get 
> a different IP address in the boot prom than in the operating system, 
> you may have trouble.   But if your goal is simply to notice that two 
> clients are the same device, you can do that.

I'm not at all concerned about address shortages (I have a full /16 here); 
it's about the ability to specify arbitrary options, for an arbitrary client, 
while knowing only the clients HW address and performing no configuration on 
the client.

Right now, we frequently use this idiom in a number of different ways:

MAC address -> DHCP -> IP -> hostname -> software policies

where "software policies" is something like Active Directory, which does all 
of the heavy lifting required to turn the machine into a lab machine, desktop, 
or whatever else.

In other cases, DHCP is configured to point clients to any one of a number of 
different TFTP servers, depending on which administrative group owns them.

If, contrary to my understanding of RFC 3315, the DHCP server is allowed to 
extract the HW address from the DUID, and use that to give matching behavior 
to DHCPv4, then that gets 90% of what I'm looking for.

The other 10% is selection of which HW address the DUID gets generated from. 
Given a host with two interfaces, the DHCP administrator has no way of knowing 
which one will be used to generate the DUID.  Unless the client behavior is 
changed to either a) use a deterministic algorithm to pick which interface the 
DUID is generated from, such as always using the lowest MAC address, or b) 
send a complete list of all interface addresses, I don't see a way that I can 
reliably recreate this workflow in IPv6.

> You can always come up with a scenario where you can show that DHCP 
> doesn't do what you want in that scenario.   But each specific behavior 
> of DHCP is there for a reason.   Rather than attempting to engineer a 
> different protocol that does precisely what you want, and in the process 
> opening yourself up to all the interoperability problems we were trying 
> to avoid when we wrote the spec, why not simply figure out how to get 
> what you need in the context of the spec as written?

If there is some alternate way of reliably getting from an anonymous computer 
with a blank hard drive to high level software policies, I'd love to hear 
about it.  From everything that I've read and understood in the RFCs, though, 
it's just not possible.

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