FW: Fix IP address based on the Option 82 info
Szabó, Gábor - COM FN
szabo.gabor at siemens.com
Wed Mar 29 08:39:28 UTC 2006
Thank you for your kind and detailed answer. I have only one small note: the Option 82 circuit ID is attached to the DHCP by the access equipment of the service provider so in this case not the client identifies itself but the (access port of the) service provider identifies the client. In service provider environment it is a very big difference in terms of security and operation so this is the reason for providers asking such solution.
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf Of David W. Hankins
Sent: Monday, March 27, 2006 8:41 PM
To: dhcp-users at isc.org
Subject: Re: FW: Fix IP address based on the Option 82 info
On Mon, Mar 27, 2006 at 07:41:08PM +0200, Szabó, Gábor - COM FN wrote:
> I hope I do not disturb you very much.
I just got home from IETF 65. So, I'm already quite disturbed.
> I would like to ask your kind opinion about a "wish" regarding ISC DHCP and I was not sure to send it privately or to the list..
The list is almost always preferrable. We are an open organization,
not only in our sources but in our output to the community.
> I have read through the DHCP server list archive and i saw that the need for assigning fix IP addresses based on Option 82 circuit ID parameters appears regularly. Also I have recognised that my solution (described in my attached mail) is the usual way other colleagues are using as well.
> My question: what is your opinion extending the "host" declaration rules allowing Option 82 circuit ID as parameter in addition to the currently supported "dhcp-client-identifier " and "hardware" parameters? My feeling is that using such mechanism it will not necessary to declare many thousands of class definitions, pool declarations with "allow member" statements and single-element ranges; and the simplified structure should results in less memory usage, faster startup and execution time, more scalable application..
> I'm just a network engineer (I have not written software since more than 10 years) so I'm not so brave to try to modify the source code without asking your kind opinion before.
Client identification in DHCPv4 is a problem.
The client identifier option was intended to clarify the issue. By
providing a field that identified the client uniquely, it removes
that overloading from the chaddr (which is also used to return-address
Instead, it's made the problem slightly more complex. Not just in code,
if you look inside ISC DHCP you will see that in every case where we
want to judge if a client owns a lease, or which lease a client should
be given, we have to dupliate our efforts...once in the case where
the client (or lease) supply a client-id, again in the case where the
client (or lease) do not, falling back to the hardware address.
The 3315-id-in-v4 (now RFC4361) seeks again to simplify this by
teaching clients the merits of selecting truly unique identifiers
rather than merely duplicating chaddr within their client-id.
This is a good thing, and can be used for a variety of good purposes.
But rather than simplifying the sysadmins' lives, it's going to make
it more complex once again: these RFC4361 identifiers could in no way,
shape, or form be compared to chaddr contents, so the traditional ways
these problems have been solved in the past are of no avail.
So the only way forward I perceive is to establish a third field. The
client's "selected identity". After the packet is classified (so "class"
statements can guide this behaviour), some sysadmin-configured process
with present-code-compatible defaults selects an identity to use.
dhcp-selected-identity = pick-first-value(
concat("c:", option dhcp-client-identifier),
This single identity now is the only thing to question in all the code
I mentioned previously that duplicates efforts. We only have one field
to compare, lookup, etc.
In addition, for the people who are struggling with rfc2131 "classic"
client identifier problems (notably, PXE/Windows users), it goes
dhcp-selected-identity = pick-first-value(option dhcp-client-identifier,
And the server behaviour will match others in the field.
I hope it will also be useful as rfc4361 deploys, but I wonder at how
difficult it will be, even with this tool, for a sysadmin to work around
that particular set of problems.
There are some quirky points that need to be addressed for this to work
properly. Namely, failover, and ddns updates.
At any rate, it could just as easily be used for the purposes you
describe (to select the contents of any arbitrary portion of the dhcp
packet to identify the client).
I have spoken on this on the list in the past, but not in relation to
this particular issue.
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
More information about the dhcp-users