[dhcwg] Pre-determining DUID

[Jarrod Johnson <jarrod.b.johnson at gmail.com>]

I was trying to comb through to see if in the generic DHCPv6 space
that any alternative to the current DUIDs would be provided to more
closely mimic capabilities in DHCPv4.  I've seen a lot of controversy
and a suggestion that a draft be put together, but I can't seem to
find any draft.  I know I am digging up a discussion that has occurred
time and time again, but I have not been able to find any constructive
conclusions that are useful to me so far.

I am fully aware of the aims of trying to use a different strategy of
DHCPv6 for many use cases, but much of my life in networking relies on
centrally managing and pre-configuring a host's network identity
before it turns on.  It also depends on the address staying with the
underlying entity rather than the OS image that runs on top of it.  As
a common specific instance of the previous point, it depends upon a
coherent, consistent identity to be maintained during firmware
bootstrap (currently, no IPv6 capable boot firmware, but I see there
is a draft discussing that) and the resultant operating system.  The
current DUID strategies do not provide for a mechanism that is even
likely to be similar between those two largely uncoordinated pieces of
code running on the same entity.

One thing I've seen suggested is a mechanism by which the networking
'edge' would tag dhcp packets to key off of that, the problem there
being that I generally must deal with 'edge' devices presenting
multiple mac addresses on the same port, rendering that proposed
mechanism insufficient.

I've considered potentially using the stateless addressing, but two
problems that occur are that DNS zone updates would have to be
manipulated in a global scope which takes more time than a DHCP
binding change in my segments and, more importantly,  I either must
choose the variant that shares the hardware address in the global
namespace or use the privacy addresses which brings me back to square
one where I can't centrally manage network identity mapping between
layer 2 and layer 3.

With the current circumstances, the best I can do makes an IPv4
provisioning network on my segments a prerequisite for IPv6 function.
Essentially, I would leverage the semantics of IPv4 to bootstrap the
environment identities and deploy OS, and at the same time, feed down
a static DUID for that host to achieve persistence across deployment
actions.  I'm not particularly excited about a long-term strategy that
requires IPv4 to function simply because a particular semantic was
given no allowance in the IPv6 generation of protocols.  It's also a
minus that I have to be pretty hands on for every platform I deploy.

I wanted to know if I missed something in the drafts and it was there
or else how it may be possible to add a standard field to store the
traditional hw-type,hw-addr data in the DHCPv6 payload in addition to
the DUID today.