Subject: [dhcwg] Pre-determining DUID

From: Jarrod Johnson <[email-masked]>
Date: Fri, 9 Oct 2009 21:10:15 -0400

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.

---

From: Chuck Anderson <[email-masked]>
Date: Sat, 10 Oct 2009 17:09:03 -0400

On Fri, Oct 09, 2009 at 09:10:15PM -0400, Jarrod Johnson wrote:
> 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. 

We at WPI have a working prototype implementation of a DHCPv6 Relay 
Agent that adds the client's hwaddr to the relayed packet.  It is our 
intent to write a draft describing this method, although we have not 
had the time to do this yet.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Oct 2009 15:48:25 -0700

It seems that you want to use the client id as a token to identify a  
particular piece of hardware for some purpose, but you haven't said  
what the purpose is.   It also seems that you are (perhaps without  
realizing it) proposing that we break a bunch of protocol  
functionality for everyone in order to solve a problem that is  
specific to your application.

Rather than starting out with the solution, could you please clearly  
state the problem you are trying to solve?

---

From: Chuck Anderson <[email-masked]>
Date: Sat, 10 Oct 2009 20:25:22 -0400

On Sat, Oct 10, 2009 at 03:48:25PM -0700, Ted Lemon wrote:
> particular piece of hardware for some purpose, but you haven't said what 
> the purpose is.   It also seems that you are (perhaps without realizing 
> it) proposing that we break a bunch of protocol functionality for 
> everyone in order to solve a problem that is specific to your 
> application.

I don't see how it breaks protocol functionality to provide 
additionaly information in a DHCP packet in order to identify and 
classify a client.

> state the problem you are trying to solve?

Here are the problems we have that I'm sure many others share:

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

We desire to only use a single identifier across IPv4 and IPv6.  
Current systems and workflows use the MAC address for this purpose, so 
it is only natural to want to use it for IPv6 as well.  I hesitate to 
use the word "authenticate", but when combined with other switch 
security features (MAC security, DHCP Snooping, IP Source Guard), the 
MAC address works great as a way to casually authenticate clients for 
access to the network and is universally supported, unlike 802.1X.

We also need to classify systems to offer different options to 
different groups of systems.

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

MAC addresses only change/move when network hardware changes or moves 
between machines, which is a rare event, and an obvious one, done 
either by IT or the machine owner.  DUIDs are supposed to be generated 
at OS-install time and hence be long-lived/unchanging, but they would 
have to change/move when the OS is reinstalled, hard drives moved 
around, etc.  Also, different OSes or firmwares on the same hardware 
(think PXE boot) will most likely have differing DUIDs.  Finally, 
given that DUIDs aren't as “permanent” as MAC addresses, it is 
conceivable that various circumstances (bugs, troubleshooting 
procedures, uninformed or malicious users, etc.) could cause a DUID to 
change (think resetting the TCP/IP stack in some OSes).

Granted, an advantage to DUIDs is that all network cards in a system 
will use the same DUID, so we would no longer require separate 
registrations for each wired card and wireless card in a machine.  
However, we just trade that for requiring multiple separate DUID 
registrations for each OS on the machine instead, and requiring 
registration changes on OS reinstall since the original DUID would be 
lost at that point.

If we continue to use MAC addresses for DHCPv4 while using DUID for 
DHCPv6, this will cause weird situations due to the different 
scenarios under which each value changes.  Replacing the network card 
will cause v4 to break, but v6 will still work.  Swapping hard drives 
between two systems will cause the v6 registration to move, but the v4 
registration will stay with the original machine.  Tracking systems 
via MAC and via DUID will require two separate systems.  Overall, it 
seems like a very bad idea to go this route.

- Locating a system physically on the network, auditing:

It is easy to track MAC addresses on the network and find which switch 
port they are used on at any particular time by looking at the switch 
forwarding tables.  It is therefore easy to associate a client's 
physical location with the identity of the registrant.  This makes 
automated, captive-portal based registration systems easy to implement 
and integrate with other security mechanisms such as locking a MAC 
address down to a switch port.  Since we bind a user account to a MAC 
address when they register the MAC in our system, this allows us to 
track down that user and associate network activity with the user who 
registered the system.  How do we do the same with DUID?  We'd need 
some kind of new switch feature like DHCPv6-snooping with DUID 
capturing support.

- Detecting when a registration is no longer needed:

Similar to above, we can keep track of activity on the network for 
particular MAC addresses, and purge unused registrations after a 
period of time.  This would become difficult if not impossible if we 
no longer registered MAC addresses and instead registered DUIDs.  We'd 
rather not require our users to register multiple things (MAC and 
DUID), and as stated above we can automate the MAC capturing part, but 
not the DUID capturing part.

- Preprovisioning and automated deployment:

We want to jot down the MAC address of a machine from the box it came 
in (without opening the box) and pre-provision the machine on the 
network so that when it is eventually set up, it can boot up, install 
itself via PXE, and be associated with the particular pre-provisioned 
identity on the network.  We want to maintain this same identity on 
the network via IPv4 and IPv6, regardless of how many times the system 
is reinstalled or booted into multiple operating systems.

Right now, one can simply read the MAC address off a machine (on the 
box or label, or through software) and this value will never change 
(unless the hardware changes). This can be used to associate that 
specific hardware to a DHCP Class for PXE booting to a specific 
server/filename, etc. With DUIDs, the PXE boot firmware will have a 
different DUID from the OS which will generate a new DUID every time 
the OS is re-deployed. This implies at the very least that PXE booting 
will require a separate “registration”, and that the OS will need to 
be re-registered after each re-deployment.

So these are the motivations behind our desire at least to provide the 
chaddr in the DHCP packet as a way to identify and classify clients.  
As I said in my other email, we have a working prototype that does 
exactly this for ISC dhcrelay.

---

From: Tim Chown <[email-masked]>
Date: Sun, 11 Oct 2009 11:17:20 +0100

> Here are the problems we have that I'm sure many others share:

I would echo these general comments for our site.  It's a very nice
summary of the issues.

It's a notable stumbling block for deploying DHCPv6 for our campus
enterprise.   There's some well-established processes in place for
DHCPv4 which become problematic with the introduction of DUIDs.

I'd certainly encourage Chuck to submit the 'problem statement' as
a draft before the Hiroshima cutoff.

-- 
Tim

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 17 Oct 2009 09:31:56 -0400

You might want to look at what Cablelabs did with DOCSIS 3.0 ... in
particular the Cablelabs device identifier vendor-specific option. This
works because there is a single mac-address for the CM and the CMTS
(relay) can insert this data in the flow between client and server
(whether client here is CM or CPE).

See
http://www.cablelabs.com/specifications/CL-SP-CANN-DHCP-Reg-I03-090811.p
df, section 5.2.15 Device Identifier Option.

At the time Cablelabs was working on this, we were discussing a "device
identifier" option that would be a standard DHC WG (IETF/IANA) assigned
option to provide a device identifier (most likely a mac-address, but it
was to be defined to support other identifiers) but it wasn't clear how
this would be used and how it would handle situations such as the case
of a device with multiple interfaces and hence multiple device
identifiers. One possibility is that as DHCPv6 requests would occur on
each interface separately, the Client Identifier (DUID) would contain
the same identifier for all requests but this "device identifier" would
specify that interface's mac-address. The DHCPv6 server could then use
the two values in different ways.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tim Chown
Sent: Sunday, October 11, 2009 6:17 AM
To: [email-masked]
Subject: Re: [dhcwg] Pre-determining DUID

-- 
Tim
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Sun, 18 Oct 2009 13:55:03 -0700

> exactly this for ISC dhcrelay.
My only objection to you proposing this is that it's clear to me from  
some of your early statements in this message that you actually intend  
to use the MAC address from the relay agent option as an identifier in  
place of DUID, and not as a hint for your back office system to use in  
connecting DUID-based identifiers to MAC-based identifiers.   This is  
unnecessary--what you're proposing completely solves your problems  
without requiring any change to RFC3315 or RFC4361.

So if you were to propose a protocol extension that included the MAC  
address in the relay agent options, and you were to describe how it  
could be used as a hint to relate DUID-based identifiers to MAC-based  
identifiers, I would be in favor of that.   But to the extent that  
your proposal essentially substitutes this relay-provided identifier  
for DUID-LLT, this would eliminate an identifier that is the same  
across all interfaces for the same device, and I would not support that.

One bellwether of this would be whether or not you expected a PXE boot  
loader that sends a different identifier than the OS client to get the  
same IP address that the OS client gets, because the relay-supplied  
MAC address is the same.   If you expect this, your spec breaks  
interoperability.

---

From: Bud Millwood <[email-masked]>
Date: Wed, 28 Oct 2009 14:07:42 +0100

> MAC address is the same.   If you expect this, your spec breaks

We've done quite a bit of research on this topic, and I think Ted hit the nail 
on the head with his last comment.

In DHCPv4 a client id served two purposes: it identified the originator of the 
DHCP request, and it identified the owner of a lease.

Identifying the originator is absolutely not the same thing as identifying the 
owner of a lease, and there is *no* requirement whatsoever that these 
identities be related.

In our DHCP server design we have separated out the process of identifying an 
originator so much that we will accept almost any form of identification you 
care to configure, while still enforcing the DHCPv6 requirement that we 
assign leases to a DUID/IAID/IATYPE. (This makes for some interesting 
possibilities)

Since you expect to have some reasonable form of unique identification, I 
suggest that you seriously consider adding the hardware type to this option 
you are proposing. Without the hardware type you run a higher risk of 
identity clashes.

So the proposal should state that the htype+MAC address you are providing MUST 
NOT be used for the assignment of leases. This is no different than if you 
were to configure the server to identify the originator using the relay agent 
interface-id option.

MAC addresses are ubiquitous and a reasonable form of originator 
identification (when taken with htype), so I think this proposal is perfectly 
acceptable... even downright useful for many workflows that require 
pre-provisioning of devices.

- Bud

---

From: Jarrod Johnson <[email-masked]>
Date: Fri, 30 Oct 2009 22:26:43 -0400

On Sun, Oct 18, 2009 at 4:55 PM, Ted Lemon <[email-masked]> wrote:
> My only objection to you proposing this is that it's clear to me from some
> of your early statements in this message that you actually intend to use the
> MAC address from the relay agent option as an identifier in place of DUID,
> and not as a hint for your back office system to use in connecting
> DUID-based identifiers to MAC-based identifiers.   This is unnecessary--what
> you're proposing completely solves your problems without requiring any
> change to RFC3315 or RFC4361.
>
> So if you were to propose a protocol extension that included the MAC address
> in the relay agent options, and you were to describe how it could be used as
> a hint to relate DUID-based identifiers to MAC-based identifiers, I would be
> in favor of that.   But to the extent that your proposal essentially
> substitutes this relay-provided identifier for DUID-LLT, this would
> eliminate an identifier that is the same across all interfaces for the same
> device, and I would not support that.
]>
> loader that sends a different identifier than the OS client to get the same
> IP address that the OS client gets, because the relay-supplied MAC address
> is the same.   If you expect this, your spec breaks interoperability.

>From a practical standpoint, for a static host identity that I want to
specifically control, I want this to be possible since the OSes have
already rolled DHCPv6 implementations that won't send the same
identifier as hypothetical boot agents.  I don't want to be required
for a statically declared host to carry multiple layer 3 identities
based on time (one of which I won't know in advance at all).   For a
dynamic host identity within a specific range, I wouldn't care that
addresses change between phases (though it certainly sounds peculiar).
 If there were strategies to assure a firmware selected DUID would be
used by the OS and I got to declare non-support of all DHCPv6 client
OSes that exist today, that would suffice, but I doubt that to be
realistic to hope for.    (but if it were possible, I would think that
ffirmware DHCPv6 actions that succeed set a flag that subsequent OS
bringups can use to know that a firmware populated structure is the
authoritative DUID rather than to generate one on disk).

The problem for me with DUID vs. chaddr is that in practice, there are
huge problems that I don't see being addressed that already are
present in production DHCPv6 stacks.  In theory, it's nice, but then
again, UUID in PXE for IPv4 was nice in theory, but in practice rarely
usable since the OS wouldn't cooperate (and many manufacturers are not
good about ensuring uniqueness of their UUID, which may happen again
with DUID-EN, not because DUID-EN is flawed, but because some
manufacturers lack proper discipline to catch things like that).
Fixing DUID selection to somehow work in a reliable way would be nice,
but it's an option that requires that Microsoft, ISC, and many more
change their DHCPv6 client implementations according to as-yet
unwritten firmware specs (ISC's job is particularly complicated since
they would have to adhere to Openfirmware, UEFI PXE, BIOS PXE, and who
knows what else).  Snooping the layer 2 inforrmation and allowing an
administrator to select on that data is unfortunate, but a backwards
compatible of restoring well-known IPv4 workflows in the cases where
those quirks are more management than the quirks in IPv6 scenarios
introduced by fixing the IPv4 quirks.

I want some way to say a particular host will be fdf4cd4e:6dd0::de,
regardless of it is PXE booting, if it is installing an OS, if it is
netbooting an os, or booting into an OS from a hard drive that has
been installed.  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.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Oct 2009 22:17:16 -0700

On Oct 30, 2009, at 7:26 PM, Jarrod Johnson wrote:
> I've outlined the only ways I could see that

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.

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.