FW: Fix IP address based on the Option 82 info

[Szabó, Gábor - COM FN]

Dear Berry,

Wow, you have created what I had only deam of! Thanks a lot! 

I have immediatelly tried to use it. Of course I immediately run my main problem: I have no knowledge on OpenLDAP. I had begun to read the documentation heavily but I would appriciate very much if you could provide a sample LDAP configuration file for this application which I can use as a starting point. (There will be no more LDAP support question beyond this :-)  )

One additional question: is it planned to use your patch in failover scenario? Is it neccessary at all or it is enough to run two independent DHCP server using common LDAP database?

Thanks again for your patch.

Regards,

Gabor


-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf Of Berry Batist
Sent: Saturday, April 01, 2006 4:37 PM
To: dhcp-users at isc.org
Subject: RE: FW: Fix IP address based on the Option 82 info



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
>
>
>