FW: Fix IP address based on the Option 82 info

[Berry Batist]

In reply to many people that wish to assign IP addresses based on option
82 circuit id values I mocked up a patch that might be interesting for
people to explore.

The patch and instructions can be found here:

http://www.xs4all.nl/~bbatist/dhcp/

I hope this will aid all those that really need this functionality and are
not afraid to use an LDAP database ;-)

Regards,

Berry

> Dear David,
>
> 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.
>
> Thanks again,
>
> Gabor
>
>
> -----Original Message-----
> 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
> any replies).
>
> 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.
>
> Something like:
>
> 	dhcp-selected-identity = pick-first-value(
> 				   concat("c:", option dhcp-client-identifier),
> 				   concat("h:", hardware));
>
> 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
> hand-in-hand.  Just:
>
> 	dhcp-selected-identity = pick-first-value(option dhcp-client-identifier,
> 					hardware);
>
> 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
>
>
>