Subject: Re: [dhcwg] Pre-determining DUID

From: Bud Millwood <[email-masked]>
Date: Mon, 2 Nov 2009 14:24:23 +0100

On Saturday 31 October 2009, Ted Lemon wrote:
> On Oct 30, 2009, at 7:26 PM, Jarrod Johnson wrote:
> > I've outlined the only ways I could see that
> > happening (either changing existing DHCP clients or allowing static
> > declarations to key off of chaddr), but if you can think of other ways
> > to be able to make this guarantee, I'm receptive.
>
> Sure, go ahead and write Jarrod's Host Configuration Protocol.   That's
> what it would be.   The change you propose breaks interoperability, plain
> and simple.   So it's not going to appear in a standard from the IETF
> unless you can convince a whole lot of people that it's time to chuck out
> the baby and the bathwater.

Jarrod, Chuck and Tim have valid issues, and they've come to the right place 
to ask their questions. It's true that they've jumped the gun by putting 
forth a problematic proposal, but they DO have very real-world problems. I 
don't think they should be ridiculed for trying to figure out a working model 
for their IPv6 deployments and workflows.

Chuck's overview of the requirements is great. I have responded to each point 
below.

Jarrod:

Your last e-mail stated that you want a single identifier to "control" the 
host, but further down you said you wanted to associate chaddr with a 
specific IP address. My point in my last e-mail was that these are two 
fundamentally different things.

Imagine your network is viewed this way:

CHADDR
  -> DUID -> IP address
  -> DUID -> IP address

In this scenario, you're using CHADDR to identify the device and locate 
bindings that it "owns". Each binding is associated with a binding identifier 
(DUID+IATYPE+IAID), but you're not 'managing' DUIDs or binding identifiers, 
you're managing CHADDRs.

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.

The real problem is if you want to explicitly control, in advance, which DUID 
gets which address. It is impossible to guess what the RFC-recommended DUID 
will be because of the time factor.

It *is* possible in theory to make the IP address available to the identity 
(MAC in your cases) without actually creating a binding, but I concede that 
it's not ideal for your workflow. 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.

To take Chuck's requirements one by one:

> - Identify "known" clients vs. "unknown" clients, and other client
> classification:

Identity can be chaddr if we propose adding chaddr to the relay options. No 
problem, and Ted seemed to wholeheartedly agree with this. Many people use 
relay-agent-circuit-id as a management identity in DHCPv4 without binding 
addresses directly to the circuit-id. Everything you wrote under this point 
can easily be accomplished once you have the MAC address identity available, 
and without interfering with DUID.

> - Stability/semi-permanence of MAC addresses vs. DUIDs

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.

> - Locating a system physically on the network, auditing:

See above. If MAC addresses work for you, no problem.

> - Detecting when a registration is no longer needed:

See above.

> - Preprovisioning and automated deployment:
<snip>
> This [MAC address] can be used to associate that specific hardware to
> a DHCP Class for PXE booting to a specific server/filename, etc.

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.

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.

Managing this setup effectively is not so much a DHCP problem as a 
presentation problem. I hope this has helped, and I'm still very much 
interested in seeing a proposal for adding MAC address to the relay options.

- Bud

> 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.
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

-- 
"The threat of madness is the price of reason" - Susanne Langer

---

From: Jarrod Johnson <[email-masked]>
Date: Mon, 2 Nov 2009 18:31:23 -0500

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.

> 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

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 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.

> 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.

> 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.

>> something and point to the line in the protocol spec that shows that their

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.