Diff client IDs -> multiple leases

[David W. Hankins]

On Sun, Mar 12, 2006 at 10:47:59AM -0600, Jesse Saletan wrote:
> Can anyone bring me up to date on the status of this issue?  Does the 
> current dhcp server include any option for how to handle client IDs?  Or 
> is there some other way to produce the desired result, other than 
> modifying all the dhcp clients' settings?

DHCP 3.0.x has no mechanism to support this, and since we're talking
about a new feature in order to do so, it never will.

DHCP 3.1.x may have a feature to support this, if I can manage to
find the time to develop it.


Understand first that the current behaviour is how we interpret RFC2131.
There are alternative behaviours in use by other DHCP servers (Cisco,
Microsoft), but I see these as side effects of 'expendiency of design',
not of interpretation of any RFC (at least, none of their authors have
ever argued in that direction).  In essence, they store only one
identifier field assigned from the contents of the client-id if present
and the hardware address otherwise...and if it matches client identifier
or hardware addresses when the client-id is or is not present, it is mere
coincidence.

The difference between them and us is that my employer will fire me if
he ever gets the idea I'm not writing an implementation to the reference
standards (which is also why he expects I may spend a certain portion of
my workday writing new reference standards).

So, since it's the desired behaviour we believe is documented by the
relevant IETF documents, it must remain the default behaviour (and is
not considered a bug, rather the lack of support for the converse is
considered a missing feature).


Presently, internally to dhcpd, each 'lease' state structure contains
two identifier fields - a hardware field, and a 'uid' field (which
it takes to mean 'client identifier').  When we want to do our
client/lease ownership checks, we have to check both sides every time.

The result is at least in one known (and now fixed in 3.0.4) case
we aren't all that consistent about application of this policy.

The right fix for this, to retain the current behaviour by default and
allow any arbitrary administrator-supplied behaviour, is to add a third
field.  'uid' will probably go away and come back as 'client-identifier',
because it annoys me.  The new third field 'selected-identity' let us
imagine, will describe what was used to identify a given lease when it
was assigned (and therefore what must match to verify client ownership).

This will be administrator selectable, and will default to the current
behaviour, something like:

	select-identity pick-first-value(
				concat("c:", option client-identifier),
				concat("h:", hardware));

So the first byte guarantees mismatch if the identity-type is not a
match (note that concat() fails if either argument is null).

Essentially code at the start of packet processing will evaluate this
configuration directive and assign that value to a placeholder in
the current state object that it will use henceforth to identify
the client.

So from here on out we only have one field to check against one
field on the leases, vastly simplifying a lot of code (taking out
entire secondary loops).


But alternative by-administrator config could be as easy as:

	select-identity pick-first-value(
				option client-identifier,
				hardware);

Which is what you're trying to acheive (without losing client-id
support entirely).  Basically, client-id that matches hardware is
a match.  And this will probably be recommended in the manpage (we
would certainly prefer the above behaviour to outright ignoring the
client-id).


I would also like to note purely coincidentally that the following
might also be selected by an administrator;

	select-identity option agent.circuit-id;

Which, in essence, assigns an address to a port on your relay agent
(which may be, let us imagine, a single port given to a user as part
of a broadband set-top-box or similar).  Note that this can and does
confuse things, and it is absolutely RFC2131 incompliant.

But sysadmins are funny people that way, and if there's no danger
that a client might move between ports, there's probably no harm in
using this particular method to limit your clients to a single
address (and a single computer).


Understand also that in the future, an RFC3315-like client-id within
DHCPv4 client identifiers may be adopted.  In this case, dual booting
clients have a third dimension that is not covered by either of the
above examples.

  http://www.faqs.org/rfcs/rfc4361.html

So your Linux and Windows versions of the same end-host will suddenly
come up with two very different 'DUID's and most likely will also offer
different 'IAID's...in essence, both will supply mismatching client
identifiers most likely by default.  The draft advises that the DUID
should be easy to export from a client, displayable somehow, so that
it might be copied between multiple operating systems...by the system
operator.

Life will get substantially more interesting when that happens.  A
big part of my motivation in the above feature is that I'm trying to
make life easier in the rfc4361-adopted world of the future we hope
(for other very good reasons) will come to pass.

At the very least, you should be able to build a conversion table of
DUID/IAID pairs, even if most sysadmins will not invest that much work
when easier avenues are available.

-- 
David W. Hankins		"If you don't do it right the first time,
Software Engineer			you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins