Persistent DUID (DHCP Unique Identifier) for Server

[Bjørn Mork]

Simon Hobson <dhcp1 at thehobsons.co.uk> writes:
> Ted Lemon wrote:
>
>>>Thus effectively making it unusable?
>
>> No, it serves to identify the client to the DHCP server.   That's
>> very useful.   When you say "makes it unusable," you must mean
>> unusable for something other than that.
>
> I think what was meant is that hardly any devices these days truly fit
> the description of having an immutable interface hardware address. If
> applied to the letter, the restriction would preclude the use of
> DUID-LL for virtually all devices - thus "effectively making it
> unusable".

Well, there are devices with ethernet and without user writable flash,
either because they are entirely ROM based or because programming them
requires using a special interface (JTAG or whatever).

I believe the DUID-LL type was added with those in mind, although such
devices typically don't have an IPv6 stack yet...  But that isn't
required by RFC3315 :-)

In fact, thinking of it: How much would you actually have to write to
use DHCPv6 if you completely ignore anything you don't use?  Say you
have a sensor which just needs a global source address to send its
measurements as routed UDP packets to some collector, but doesn't really
care about receiving anything on the global address.  Send a DHCPv6
request with a rapid commit option - the whole request could be
prebuilt.  Parse the reply and just save whatever address you got in
memory. I bet it's doable in a few hundred bytes of ROM.

Just using SLAAC is of course easier (as you will have to parse the RAs
anyway to get the gateway address), but adding simple DHCPv6 client
capabilities to really primitive devices won't cost much extra.  So it
will happen.

Of course, the physical interface probably won't be ethernet.  But that
doesn't matter.


Bjørn