I wanted to seek the opinions of the gPXE community on DHCPv6.<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div><div><br></div><div>
For more writeup, <a href="http://tools.ietf.org/html/draft-narten-dhc-duid-uuid-01">http://tools.ietf.org/html/draft-narten-dhc-duid-uuid-01</a> is the draft RFC submitted to the dhcwg.</div><div><br></div><div><br></div>