Re: [dhcwg] Pre-determining DUID

[Jarrod Johnson <[e-mail]>]

On Sun, Oct 18, 2009 at 4:55 PM, Ted Lemon <[e-mail]> wrote:
>> So these are the motivations behind our desire at least to provide the
>> chaddr in the DHCP packet as a way to identify and classify clients.
>> As I said in my other email, we have a working prototype that does
>> exactly this for ISC dhcrelay.
>
> My only objection to you proposing this is that it's clear to me from some
> of your early statements in this message that you actually intend to use the
> MAC address from the relay agent option as an identifier in place of DUID,
> and not as a hint for your back office system to use in connecting
> DUID-based identifiers to MAC-based identifiers.   This is unnecessary--what
> you're proposing completely solves your problems without requiring any
> change to RFC3315 or RFC4361.
>
> So if you were to propose a protocol extension that included the MAC address
> in the relay agent options, and you were to describe how it could be used as
> a hint to relate DUID-based identifiers to MAC-based identifiers, I would be
> in favor of that.   But to the extent that your proposal essentially
> substitutes this relay-provided identifier for DUID-LLT, this would
> eliminate an identifier that is the same across all interfaces for the same
> device, and I would not support that.
]>
> One bellwether of this would be whether or not you expected a PXE boot
> loader that sends a different identifier than the OS client to get the same
> IP address that the OS client gets, because the relay-supplied MAC address
> is the same.   If you expect this, your spec breaks interoperability.

>From a practical standpoint, for a static host identity that I want to
specifically control, I want this to be possible since the OSes have
already rolled DHCPv6 implementations that won't send the same
identifier as hypothetical boot agents.  I don't want to be required
for a statically declared host to carry multiple layer 3 identities
based on time (one of which I won't know in advance at all).   For a
dynamic host identity within a specific range, I wouldn't care that
addresses change between phases (though it certainly sounds peculiar).
 If there were strategies to assure a firmware selected DUID would be
used by the OS and I got to declare non-support of all DHCPv6 client
OSes that exist today, that would suffice, but I doubt that to be
realistic to hope for.    (but if it were possible, I would think that
ffirmware DHCPv6 actions that succeed set a flag that subsequent OS
bringups can use to know that a firmware populated structure is the
authoritative DUID rather than to generate one on disk).

The problem for me with DUID vs. chaddr is that in practice, there are
huge problems that I don't see being addressed that already are
present in production DHCPv6 stacks.  In theory, it's nice, but then
again, UUID in PXE for IPv4 was nice in theory, but in practice rarely
usable since the OS wouldn't cooperate (and many manufacturers are not
good about ensuring uniqueness of their UUID, which may happen again
with DUID-EN, not because DUID-EN is flawed, but because some
manufacturers lack proper discipline to catch things like that).
Fixing DUID selection to somehow work in a reliable way would be nice,
but it's an option that requires that Microsoft, ISC, and many more
change their DHCPv6 client implementations according to as-yet
unwritten firmware specs (ISC's job is particularly complicated since
they would have to adhere to Openfirmware, UEFI PXE, BIOS PXE, and who
knows what else).  Snooping the layer 2 inforrmation and allowing an
administrator to select on that data is unfortunate, but a backwards
compatible of restoring well-known IPv4 workflows in the cases where
those quirks are more management than the quirks in IPv6 scenarios
introduced by fixing the IPv4 quirks.

I want some way to say a particular host will be fdf4cd4e:6dd0::de,
regardless of it is PXE booting, if it is installing an OS, if it is
netbooting an os, or booting into an OS from a hard drive that has
been installed.  I've outlined the only ways I could see that
happening (either changing existing DHCP clients or allowing static
declarations to key off of chaddr), but if you can think of other ways
to be able to make this guarantee, I'm receptive.
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>