FW: Fix IP address based on the Option 82 info

[Berry Batist]

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

That was the idea ;-)) A pleasure to be of help to you.

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

The section 'LDAP SETUP' describes actually the only additions to the ldap
configuration you have to make if you had a standard installation.
Anything else in the configuration file is just default stuff.

But here is a complete example:

include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema

include         /usr/local/etc/openldap/schema/dhcp.schema

pidfile         /usr/local/var/run/slapd.pid
argsfile        /usr/local/var/run/slapd.args

schemacheck     on

timelimit       15
sizelimit       500

access to * by * read

database        ldbm
suffix          "dc=domain.com"

directory       /usr/local/var/openldap-data

cachesize       500000
dbcachesize     5000000

index           ObjectClass     eq
index           dhcpCircuitID   eq

rootdn          "cn=user, dc=domain.com"
rootpw          password

I used openldap 2.3.11 and build it running the following commands:

sh configure --prefix=/usr/local \
              --disable-slurpd   \
              --disable-bdb      \
              --disable-hdb      \
              --enable-ldbm

make depend install

The section 'LDAP ENTRIES' shows a sample entry which you can put in a
text file and load into the database. LDAP becomes a storage of host
records that you would normally put into the dhcpd.conf file.

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

I actually disabled failover completely by commenting it in includes/site.h
(as well as dynamic DNS updates). The patch actually also corrects some
small pieces of code that make the compiler croak when failover is
disabled. This is because some variables are not within the
FAILOVER_PROTOCOL defines.

The cool thing is that you don't need the failover support. You could run
any number of DHCP servers with the same config and using the same LDAP
database.

The way the server will work is as follows:

 - On a discover message it gets the IP address associated to the circuit
id from LDAP and offers it. What also happens is that now the IP address
hash table (populated at startup) and MAC address hash table (populated
on receival of client packets) point to the same lease structure.

 - This is used for the renewals where the server will use the packet's
ciaddr and chaddr values to locate their corresponding hash table
entries. Then it only needs to verify if the both point to the same lease
to identify the (legitimate) client and ack the lease. This saves another
LDAP lookup to be performed.

Normally a client will send its packets to the server it selected when it
received an offer and use unicast to directly contact the server.

As it could be possible that the client packets arrive at another server
which did not initialize served the client, this would create naks.
Fortunately, the client will arrive at the rebinding phase and broadcast
request packets. Then any other server can handle the request and normally
will not hurt the client's connection.

So there could be a situation where a client has an active lease (always
for the same IP though) on more than one server. But since there cannot be
a collision on the IP address being offered this is not an issue.

It is a long story, and I am not too good a telling stories. Therefore I
can only code it ;-)

> Thanks again for your patch.

You're welcome, and of course I am very much interested in your feedback.

Berry

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