Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-opt-netboot-05

[Jarrod Johnson <[e-mail]>]

On Sun, Oct 11, 2009 at 8:55 PM, Ted Lemon <[e-mail]> wrote:
>> There are two problems with RFC 4361 section 7 for me:
>> -Practically speaking, I see no specific standards in place for the
>> various architectures to implement the prescribed communication path
>> between OS and firmware.
>
> That's because we can't do anything about that.   We can't tell firmware vendors what to do.   Indeed, generally speaking, they don't even follow the protocol specifications anyway - we're lucky if what they do roughly interoperates with conforming implementations.
>
> It wasn't my intention in RFC4361 to say that the O.S. or the firmware should be in charge, but rather to say that they should collude to present the same identifier.   As far as I know nobody's implemented that, though.
>

FYI, the wording that made me feel it implied OS control was:
"Such clients should  provide a way for the operating system DHCP
client to configure a DUID to use in subsequent boots" which I took to
mean that if the OS mismatched, that it should be considered that it
is the firmware that needs to be rectified.  After some thought, I
actually think precisely the opposite would be true.

Anyway, perhaps with some specific recommendations, this draft should
reference RFC4361 to ensure that firmware developers have this in mind
and hopefully some standards get pushed in the correct places (just
like iBFT exists to facilitate RFC4173).

If appropriate, I have some thoughts on how it can be resolved to my
satisfaction (but not Chuck's) and probably keep people who like the
DUID moving with the hard drive happy:
-Firmware should provide a DUID of it's choosing (likely DUID-EN) at
any time through a mechanism of their choosing (i.e. openfirmware
properties, DMI tables in x86, whatever is appropriate).  However,
unless specifically configured to do otherwise, DHCP clients should
ignore this information.
-If netboot firmware actually executes a boot, it should make the
DHCPv6 reply packet available in some form that the OS and bootloader
can read. (openfirmware, for example, would almost certainly do it
just like they stick the bootp-response in /chosen today).  In x86,
maybe they'd implement it in a similar way they do iBFT, but the
format should be just the raw packet, since the consuming software
would certainly already have code to parse a DHCP reply packet, and an
intermediate format would just be a headache for everyone).
-If netboot is started, but ultimately aborted (i.e. pxelinux.cfg's
'localboot' directive, or a non-existant boot file), it should not
retain any DHCPv6 reply packet and the OS need not try coordinating
with boot firmware.
-If the OS dhcp implementation sees that the firmware has populated
the DHCPv6 reply structure, it should ignore (but may retain for
future use) any DUID it might have saved and instead configure itself
to always read DUID from firmware structures instead of system disk
(this way, if a hard drive is deployed in this manner, it won't clone
a DUID-EN and risk making it non-unique by moving it to a system that
isn't deployed in the same fashion).  If that drive appears in a
system with no firmware provided DUID, it would have to generate a new
DUID or revert to the DUID it had generated previously.
-The OS need not have a way to write back a DUID in a standard way as
it is not very important and further mitigates the risk of duplicate
DUIDs by avoiding cloning them with the risk of future disassociation.

The thoughts behind this are that the scenario for netboot include:
-network boot of the OS.  In this case, the layer2<->layer3 identity
mapping has already been proven to make the correct association.  So
if the OS sees that firmware has one, and it happens to have a
different one, it knows one has been proven and one has not been, so
it makes sense to always use the one already validated.
-network deploy of the OS.  A no brainer here, there is/should be no
meaningful DUID other than the firmware.  If image deployment is being
done, they would already have to wipe DUID to make it a generalized
image anyway.
-network boot starts, but chain to a local disk (i.e. syslinux
chain.c32).  This could be the most controversial case, but I think it
fair to presume that the network loader infrastructure implying it has
that much knowledge of the managed system means it is pre-configured
specifically for this, and therefore the boot time DUID should be
considered the correct one.
-network boot, but exit to local boot instead.  I think it's fair to
say this could imply that the DUID in use is not specifically
validated and therefore is not worth implying it should be used over
other DUID.  In my case, when this occurs, the OS had previously
recorded the DUID from the boot firmware and is using it, so I don't
lose control.

An alternative would be for OS to always source DUID from firmware
tables if available (i.e. DMI tables in x86) regardless of boot state,
however I think that would be detrimental to those who enjoy retaining
their IPv6 identity when they move their hard drives to a new set of
equipment in a decentralized scenario.