host-identifier with IPv6
fs at WPI.EDU
Tue Mar 3 02:32:27 UTC 2009
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.
- 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
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
More information about the dhcp-users