host-identifier with IPv6

[Frank Sweetser]

David W. Hankins wrote:
> On Tue, Mar 03, 2009 at 02:07:51PM +1300, Eustace, Glen wrote:
>>> Looking at this problem from another angle, how would you feel about
>>> assigning an IPv6 address to any client seen on a given switch port?
>> Ahhh, no thank you.
> 
> Ah, pity.  When Shane wrote the IPv6 host bits, we talked and decided
> on the host-identifier syntax explicitly for this kind of reason.  I
> was hoping there'd be a hardware address option eventually (or
> environments where you could pull it from relay forward options), and
> I knew there would be situations you'd want to use the hostname, or
> relay agent supplied options, like those that describe the switch port
> the client's packet was received on.  I wanted to backport it to
> DHCPv4 as well, since we get feature requests there all the time.
> It's remarkably trivial to backport.
> 
> So I gave him the impossible task of a config option that the user
> specifies the matching constraint, while still being a hash-table
> lookup and not some series of byte-compiled conditional stages.  The
> host-id syntax is how he solved it.
> 
>     host-identifier option fqdn.fqdn "foosrv.example.com";
>     host-identifier option agent.circuit-id "eth0";
> 
> Doesn't help for registration (since even if there was a hardware
> address option, clients today don't send it; you still need an
> interim solution).

Would it be feasible to define behavior where the circuit-id, or some other 
field with similar behavior, contained the client HW address?

The relay agent would have to be on the same broadcast domain, so it should be 
able to pick the address off the wire regardless of whether or not the client 
explicitly transmits it.  Similarly, in cases where there is no relay agent, 
the server would have to be on the same broadcast domain as the clients, and 
again can see the sending address.

This would:
   - allow the DUID to remain an opaque object consistent across all interfaces
   - resolve the ambiguity of which client interface was used to generate the DUID
   - be easily backported to DHCPv4 without any behavior change
   - be completely decoupled from client code and behavior
   - be much easier for admins to deploy, by updating router firmware or 
adding strategically placed hosts running relay agents, than waiting and 
hoping for OS updates (raise your hand if you still have Win98 machines on 
your network!)

Does this sound reasonable to everyone?

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