dhcp-hackers Digest, Vol 4, Issue 5 (Lease information operations).

Sat Mar 28 20:24:30 UTC 2009

-----------------------------------------------------
> Message: 1
> Date: Fri, 27 Mar 2009 23:48:36 +0200
> From: PavelTilinin <pavel.tilinin at gmail.com>
> Subject: Lease information operations.
> To: dhcp-hackers at lists.isc.org
> Message-ID: <49CD49B4.7020501 at gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Hello..
> The situation is the following:
> I'm using Option 82 on switches in the network to identify users, 
> requesting for IP-address via dhcp. It is impossible to identify them in 
> some another way, because there is no layer2 connectivity between users 
> and dhcp-server. I have built classes-based rules to provide a concrete 
> IP-address for each user (to identify that user later by his ip). It 
> becomes a very big waste of IP resourses, and a whole sense of dynamic 
> ip delegation is lost:(
> So there is a question:
> Does anybody know, is it possible to send lease information (with Agent 
> circuit-id and remote-id) to some remote host (Any way, either a radius 
> server or randomly created socket), when client requesting/renewing his 
> IP-address? Is it possible to operate by lease information in ANY 
> another way, then just parsing of "dhcp.leases" file?
>
> Scheme must be the following: Some host requests for an ip, dhcp-server 
> receives this request, does decoding of option 82 and sends this option 
> and other lease information to remote server. After that, allocates ip 
> for host and sending an offer.
>
> Every idea will be useful.. I will thank everyone...
>  
>
>
>
> ------------------------------
>
> _______________________________________________
> dhcp-hackers mailing list
> dhcp-hackers at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-hackers
>
> End of dhcp-hackers Digest, Vol 4, Issue 5
> ******************************************
>
>   

Pavel,

Your message is unclear.

Clients are typically identified by their mac address.
If they are on a different network than the DHCP server, there must be a
DHCP relay present that forwards any DHCP broadcasts.
Presumably your switches have DHCP relay functionality built in.

I fail to understand your statement
"It is impossible to identify them in
some another way, because there is no layer2 connectivity between users "

Client identification to the DHCP server has nothing to do with 
connectivity.
Perhaps you are trying to identify the _subnet_ that your clients are
coming from? For what purpose?  To select an address that is
correct for the client's subnet? 

I fail to understand what you are trying to accomplish.
DHCP does what it does as per the relevant rfc-s.
If you want to extract and send some extra information that is not
part of the protocol processing, you obviously have to add
some custom code to the DHCP client.

What does "Operate by lease information" mean?

Steve
-------------------------------------------------------------------------

Hello, Steve!
I'll try to "draw" a complete picture:

There is an ISP, which provides its services to the customers over 
Ethernet exclusively. FTTB project in fact.
There is one ethernet switch with fiber uplinks in every building, where 
ISP has Point Of Presence, and clients are connected to switch over UTP.

When the client connected to switch, he tries to obtain an IP-address 
over DHCP, switch extends this request by inserting option 82 to it, and 
dhcp-packet begins his travel over the network. There is one DHCP-Relay 
in every layer2 segment (You where absolutely right, when You said about 
switche's built in relay functionality), it retransmits requests to 
ISC-DHCP server, server allocates IP, packet returned to relay, and then 
to client. After that host becomes configurated, and all should be 
happy... but no:(

After that (according to ISP's service politics) client's profile has to 
be applied somewhere, at some transit gateway. Now I mean, at least, 
client's bandwidth. In place of "transit gateway"  we can put Cisco ISG 
(if you familiar with) or OpenBSD Packet Filter based shaper or IPFW 
based solution or anything we can imagine. We can shape client's traffic 
only if we know his IP-address. It is impossible to examine client's 
MAC, because users can change their computers, connecting to network 
their notebooks, Home Gateways or other stuff.
ISC DHCP server gives possibilities to process Option 82 information and 
to build classes. In this way we can assign STATIC IP to every 
requesting host . This IP will be used later at "transit gateway" to 
build some rules.
But HOW to define client's IP address to build shaping rules, if this IP 
was allocated over DHCP much earlier? - That is the main question.. 
Information about leased IPs must be available elsewhere that only in 
cache of isc-dhcpd. "Transit gateway" should know, that client1, for an 
example, now using ip 1.1.1.1, and client2 is using 1.1.1.2. Next time, 
when these two will be connected to network, client1 will obtain 
1.1.1.150, and second will get 1.1.1.200, and you have to dynamically 
rebuild your rules, to limit bandwidth for these guys by their new IPs.

So.. my question is the next: Possibility of sending of lease 
information to elsewhere, does it exist?
-------------------------------------------------------------------------

OK Pavel..

This message is much better.

Basically, you want to configure the quality of service level to 
customers, based on
some criteria.    Perhaps  you wish to identify your clients based on 
which building
they are located in.  So the purpose of transmitting the lease 
information to somewhere,
so that your traffic shaping infrastructure can have  the  option 82 
information available,
which is logically the basis of your QOS decisions.  This surely can be 
done by extending
the ISC server. Easy to do, as it is available in source.

Actually, the traffic shapers are driven off of  IP lists. Some other  
piece of code has to
compile these lists, based on the option 82 information

Your current  thinking is:  implement  this logic via  a hard-coded 
association between
specific IP addresses and the opt 82 "building / residence identifier"
Perhaps another way to put this: your "customer-id" is constructed from 
the option 82 information. 

One possibility, is to make your solution stand on its head...

1) Segregate your IP addresses  into address pools.  You probably have a 
relatively small number
of  service levels ( Silly example:  bronze, silver, gold and platinum, 
each with a pre-configured set of 
bandwidth etc. guarantees ). 
Each distinct service level should have a pre-defined address pool 
associated with it.
e.g.: 10.0.1.1 to 10.0.1.254 is bronze service level.
        10.0.2.1 to 10.0.2.254 is silver service level.   etc...

2)  Pre-setup your QoS infrastructure based on these sub-pools, before 
the addresses are assigned.
E.g: any IP address in the Bronze pool  gets the bronze treatment.

3)  It is possible (rather easy) to configure the ISC server to give out 
an address from a specific pool
depending on  the class configuration.  The configuration  to accomplish 
this is rather similar to what you are
doing now.  As long as the client gets the address from the right pool, 
you do not
need to care about the specific identity of the customer.   You know  
which service class the customer
belongs to , and the ISC server enforces this.  

3B) Here is a finer point: you may want to temporarily or permanently 
move a client from one class
to another.  E.g.1.: client X upgraded from brinze to silver service. 
E.g.2 client Z paid for a
pay-per-view movie so for the next 2 hours she gets more bandwith.

This is  a generalization of the "client registration" problem, 
universities and hotels tend to have.
 ie. an unregistered client gets a limited access IP which is only 
allowed to go to a self-registration
web site, but after self-registration, they get full access.

The problem is solved via sending a command to the DHCP server, to move 
the client from one class
to another.  The ISC server has a facility to do this (OMAPI). I do not 
know how good it is these
days, last time I had to deal with these kinds of problems I rolled my 
own interface because
the OMAPI was too much for my purposes. (I  extended the ISC server to 
listen on a socket and
accept client registration commands).

4) This way you only have to configure your QoS infrastructure once,  ( 
maybe occasionally, if you
need to resize your pools, or change your service levels).

Hopefully this helps you a bit.
-------------------------------------------------------------------------

And the next question will be "why i didn't think of it by myself"... 
It's a definitely a good idea... Thanks a lot, Steve!
I will necessarily schedule works in this direction...
At least how to identify client by his IP (honestly, first mention was 
about analyzing of abuse reports, where the only useful information is 
IP-address of spamer/openproxy etc). but i think, that can be done.
OMAPI shell of isc-dhcpd in its generic view is useless, because there 
is no possibility to work with it in another way then from its CLI 
(without writing separate code, which uses API provided by isc 
developers), and it doesn't operate by any Agent option, including 
option 82 (now i'm talking about omapi shell of isc-dhcpd version 3.0.5, 
available from FreeBSD ports collection). Now I will necessarily examine 
omapi of last version of isc-dhcpd.

P.S. In fact, using my NULL cognitions in C programming, operating only 
by MAN pages and general knowledges about how it has to work, i made 
some alternates in sources of "db.c" and compelled it to send lease 
information to remote host, statically defined in sources, (listening 
daemon at this host was written in perl by my collegue) over raw tcp 
socket. It works, but i think that this solution is alike.... i don't 
know.... similar to crutch and prop, agglutinated by a chewing-gum... 
thats why this idea hadn't leave our test lab.
Your advice is much constructive, even if it leads some additional 
works, thank you very much once more.