[dhcwg] Pre-determining DUID

[Jarrod Johnson <[e-mail]>]

I appreciate a constructive discussion on how to go about solving the
problems.  I'd much rather review suggestions and discuss viability of
them.  I apologize if I sound overly stubborn or close-minded,
regardless of tone I like to think I'm receptive to suggestions and I
do try to think hard about every suggestion I see.  I'm not alone with
my frustration with trying to cope with removal of aspects of IPv4
networking that are heavily relied upon today.  I'd rather not limit
my discussion to each dhcp vendor individually, as the problems I
experience are broader and the fact I would have to talk to so many
vendors is a sign that a wider scope should consider it.  I don't wish
to interfere with the capabilities granted by DUID, but I do want some
way to pre-provision addresses, but I do have requirements not met by
current implementations of DUID management (and people typing in mac
addresses from stickers on servers may never be able to be satisfied,
but they can speak for themselves).  Either one of two things must
occur for me to deploy IPv6 absent of an IPv4 crutch:
-chaddr must be added to DHCPv6 requests (technically, snooping the
layer 2 content of the packet could do it as well, however, it is
difficult for DHCPv6 server implementers to extract that compared to
acting on the payload in a 'recv' call, and also RFC3315 might be
construed to allow selection based on a chaddr option if it existed,
but not based on layer 2 packet headers, as it says some combination
of some candidate information including relay, client, contextual
layer 3 information, and DUID.  Those who dislike chaddr based
configuration would be able to ignore it as DUID isn't thrown out and
continues to exist as it does today, and the rest of us could use the
chaddr to our hearts' content.  This has the benefit of a key that is
easily coordinated with an ethernet switch port (ethernet switches
need not remember the DUID or IP of the entity on a port, but they
must remember the mac address).  It's the built in piece of data that
always persists between OS redeployments for environments where OS
deployments should not destroy associations, and must be part of the
firmware and OS stack.  I know there is a lot of opposition to use of
chaddr as a key to IP selection, but I'm not understanding why
allowing some of us to use chaddr while preserving existing DUID
practices would be so harmful.  Existing DHCP servers would ignore it,
existing DHCP clients would simply not be able to be keyed in a dhcp
config the same way new dhcp clients could, but they can't be keyed in
that way today, so no feature would be lost.  I probably missed some
discussions, so I'm curious as to why adding a chaddr option to DHCP
(not just relay) is so objectionable.

-DUID must be more controlled by system firmware and OS dhcpv6 clients
must use that DUID value.  I mention this here as both firmware
implementations and OS implementations of DHCPv6 would have to agree
and I'm not sure how that happens without a broader standard except
for platforms like AIX, MacOSX, and embedded platforms that totally
control their stack.  Linux, Microsoft, FreeBSD, and others running
atop UEFI, BIOS, and OpenFirmware have a hard time acting
independently to achieve this goal.  This has the significant downside
of potentially inhibiting the current DUID implementation benefits
where people taut the ability to move a hard drive to a new
motherboard and retain identity binding where the DHCP administrator
allows it.  Compromises around this could make it impossible for
sticker-readers to do their job as DUID on a sticker may not carry a
sufficiently strong guarantee of that DUID usage in practice.

On Mon, Nov 2, 2009 at 8:24 AM, Bud Millwood <[e-mail]> wrote:
> This approach gives you different "views" of the bindings. Your view is
> CHADDR, but you can (and should) be able to easily switch views. On many
> networks, view by relay-agent-circuit-id is most useful.

Currently, it is difficult for DHCP servers to extract this
information (if they simply bind the socket and do 'recv', they never
will see the data), as such it isn't deployed today, making CHADDR
effectively invisible to DHCPv6 collected data. Assuming they did,
it's still a tad awkward conceptually for me to deal with it when I'm
doing something less directly DHCP related (i.e. using DHCP as a tool
to help manage physical identity as opposed to act of explicitly
maintaining the DHCP server).  Today, I tie the specific rack and U
number to the IP identity using DHCP and the physical location is
baked right into the layer 3 identity without me having to consult the
DHCP server or ethernet switches again until a NIC hardware change.
The pre-provisioning aspect allows me to do the more expensive,
invasive procedures once up front rather than on-demand.  When someone
complains about an inability to reach 'r39u40.denver.example.com', I
know precisely what physical entity is involved upfront (though they
probably ask about 'www8' and I have to reverse lookup the IP to get
the canonical name, but still trivial).  One may advocate allowing the
IP to float and updating this all via DNS, but for DHCP I can
guarantee an instant update for MAC<->IP changes since the scope is
limited to one broadcast domain I completely control, but I can't
guarantee that a system a thousand miles away hasn't cached the DNS
info without excessively short cache expiry times which would degrade
DNS performance.  I'd rather manipulate a mechanism in a tight
specific scope rather than a mechanism global in scope.

> In DHCPv4 you were never guaranteed that
> the client id would be htype+mac, so you really did not have any guarantee
> that pre-provisioning with htype+mac would work. But it *was* more likely to
> work because there was no time factor involved, and most devices did use
> htype+mac for client id.

In DHCPv4, doesn't the backwards compatibility with BOOTP guarantee
chaddr as part of the payload?  I know that DHCP client
identifier/option 61 was also possible to be populated, but by and
large that has not been useful to me for the same reasons DUID has
been problematic.  Admittedly if something happened like a different
NIC used in the OS on the same segment executed DHCP (i.e. failover),
it is a tad more complicated to manage than the DUID approach, but I
already can cope with those scenarios and it didn't take much hard
thinking.  The DUID problem I face I haven't been able to conceive of
a way to get what I want despite a lot of thinking and some
suggestions.

If chaddr could be used as a 'hint' where an unknown DUID gets tied to
a specific static declaration, and subsequent uses of that DUID retain
the binding regardless of chaddr, it might work, but it would have a
serious gap.  This could cause problems similar to what cloning a DUID
would cause.  If a chaddr gets a DUID mapped to an IP entity, and then
NICs are swapped, that new chaddr location would induce a DUID mapping
to the same address as its former host, that is inadvertently two
current, valid identifiers end up mapped to the same association.  Any
practice of address association should have no more than one singular,
non-cloneable authoritative identifier, so keying directly off of
chaddr would be preferable here.

> You're free to manage devices with MAC address the same way you always have,
> you're just not free to assign IP addresses to MAC addresses.

That's a pretty huge exception.  Assuming chaddr were an option in the
client packet, what forbids this from happening?  RFC 3315 states that
address assignment may be based on "some combination of the following
sources", and includes DUID as one criteria but also allows IPv6
link-local contextual data and non-DUID options.  In that RFC, I
didn't see a blatant statement that an address MUST use DUID if other
options were sufficiently unique for an administrators use at their
discretion.

> Associating a MAC address to a set of options for PXE booting isn't exactly
> right, but maybe you mean something a little more sophisticated. The PXE
> loader and the OS use the same MAC when creating the clientid, but they
> expect very different DHCP options to be returned. You use the class
> identifier or some other such additional information to decide which options
> the server should return.

I do things like this today.  Independent of specic host identifier
aspects, DHCPOFFER parameters are populated based on conditionals
keyed from the DISCOVER (if x86, send one file, if UEFI, send a
different one, etc).  This allows manipulation of broad parameters in
generic fashion without diving into individual host declarations.
Sometimes, I do drive options specifically by mac-address in a sense
(a persistant 'server' identity would substitute, but DUID doesn't
carry the consistency guarantee, so the closest thing I have is mac
address which isn't exactly the perfect key, but is more consistent in
how it appears to a DHCP server).  For example, iSCSI client iqn I
specify specifically against a host declaration as it is unique to a
host.

>
> So my guess is you were previously using one MAC address to give one IP to two
> different DHCP entities over time; static IP addressing. As for options,
> those were probably differentiated based on vendor class.
>
> If you are doing dynamic IP addressing in DHCPv6, you can still have your
> identity (MAC address), you can still differentiate DHCP server responses
> based on vendor class, and you get the added bonus of having two unique
> leases for two unique entities.

The problem here is that conceptually, it is much simpler to track a
'server' as an entity rather than 'PXE running on that server',
'CentOS running on that server', and 'windows running on that server',
or 'this particular boot of a shared-root system' as distinct, unique
identities.  I see some power here for those that want it and IPv6
gives enough space so that exhaustion isn't an issue, but I'm not a
fan of forcing distinct identities to reference a singular server
based on what software/persistant storage happened to be authoritative
at the time of a DHCP transaction.

>> The irony here is that you're complaining to *us* that vendors don't do the
>> right thing.  I'm guessing you never complained to them, and you never
>> asked them to do anything differently, and they never lost a sale because
>> they aren't doing what you need them to do, and they never will.   And by
>> the way, they're not going to implement JHCPv6 either, for exactly the same
>> reason.
>>
>> You're paying their salaries.   You aren't paying mine.   So I'd really
>> encourage you to stop complaining here, and start complaining there.
>> You'd be surprised what a vendor will do when you ask them nicely to fix
>> something and point to the line in the protocol spec that shows that their
>> code is broken.

As addressed above, in an ecosystem driven by standards, vendors are
unable to properly achieve something without a standards body willing
to drive it.  The scope of the problem is too wide for any piecewise
vendor to address in a vacuum.

>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>
>
>
> --
> "The threat of madness is the price of reason" - Susanne Langer
>