[gPXE] Hypothetical DHCPv6 Questions/issues

[Jarrod Johnson]

I wanted to seek the opinions of the gPXE community on DHCPv6.

I'm not sure if everyone is famililiar with the ways DHCPv6 differs from v4,
but one particular feature that is marketedly different is the key
identifier is intended to be the same for a 'host' entity regardless of
interface.  If you have two nics, the identifier sent over those two nics
are supposed to be the same.  In DHCPv4, an interface identifier was always
there (the hw addr, for most people the mac), each nic looked distinct, and
it was trivial for correlate OS to firmware DHCP activity no matter how many
reinstalls and so on.  The field guaranteed to be a mac address is
removed entirely from the UDP layer payload, and no implementation allows
for faking it reliably through etiher guessing based on the physical layer
packet or deriving it from the host portion of the fe80 address.

I'm sure some will want/need something that is explicitly a per-interface
identifier, but all I am looking to solve is the fact I can't reliably
predict the whole DUID in any system or even part of it in a multi-nic
system with the status quo.  Currenlty, Windows and Linux pick 'a' nic in an
arbitrary fashion and concatenate the current time on every reinstall.
 There are two other options currently blessed , but neither work out for
x86.  One is by enterprise number, which isn't of significant help in a
platfrom like x86, and by HWADDR without timestamp, which is explicitly not
recommended for this sort of platform and is really reserved for more
embedded style scenarios.

My proposal to I've submitted to the IETF, MS, and Intel is to have x86
standardize on an as-yet unapproved DUID type, that uses 'the' UUID already
ubiquitous in x86 firmware (dmidecode|grep UUID: will show it in linux and
wmic csproduct will show it in Windows (the latter is a tad byteswapped in
output)).  DHCPv6 aims for a host identifier rather than an interface
identifier, and I think this is the "cheapest", most approriate approach in
x86 space.

Do the developers/users of gPXE find this an acceptable approach to use by
default when the time comes to do DHCPv6, or is there a different
plan/desire that is generally held?

For more writeup, http://tools.ietf.org/html/draft-narten-dhc-duid-uuid-01 is
the draft RFC submitted to the dhcwg.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://etherboot.org/pipermail/gpxe/attachments/20100717/7664f17b/attachment.html