Re: [dhcwg] Pre-determining DUID

[Bud Millwood <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg



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