[Dibbler] Address assignment policy in Dibbler

Tomek Mrugalski thomson at klub.com.pl
Wed Jan 18 19:43:28 CET 2012


On 12-01-17 09:36, Jyrki Soini wrote:
> On Sun, Jan 15, 2012 at 4:24 PM, Ron, Omer1 <omer1.ron at intel.com> wrote:
>> Hi,
>>
>>
>>
>> Failing when performing DHCPv6 server decline test:
>>
>>     step 1. Initiate a DHCPv6 Decline for the client current IPv6 address
>>
>>     step 2. Verify that the server sends a Reply message with status code of
>> 0 'Success'
>>
>>     step 3. Client sends DHCPv6 solicit to server.
>>
>>     step 4. Verify that the server assigns an address to client
>>
>>     step 5. Verify that the address assigned by the server is not the same
>> as the client's original address
>>
>>
>>
>> ·        all solicit messages from clients are send without IA_NA-options
>> meaning there is no IPv6 hint.
>>
> 
> RFC3315 Section 17.1.1. Creation of Solicit Messages states:
> 
>    The client uses IA_NA options to request the assignment of non-
>    temporary addresses and uses IA_TA options to request the assignment
>    of temporary addresses.  Either IA_NA or IA_TA options, or a
>    combination of both, can be included in DHCP messages.
> 
> So, if there is no IA_NA option, the server is not requested to give
> the address.
> 
> Hint is IA address option (section 22.6) embedded in IA_NA (22.4) or
> IA_TA (22.5)
> option. Client may omit the hint.
> 
> Besides, server may give the client every time the same address. That is totally
> upon the server implementation or configuration policy issue. For
> instance, server may
> assign the client address that has the same interface identifier part
> as the clients
> link-local address has.
Agree. And the policy is to assign the same address again for the same
clientid+iaid tuple. For example, if client sends 100 requests with IA
(iaid=1234), it will get the same address 100 times.

On the other hand, if client sends 100 requests with iaid=1 in first,
iaid=2 in second, iaid=3 in third etc., it will get 100 different addresses.

On a related note, to prevent client abuse, there is client-max-lease
parameter that limits amount of addresses a single client can get.

Current code is confusing regarding actual lease assignment policy. It
works ok in simple cases, but if you happen to define white list, black
list, there is cached lease for client, client exception is defined and
client request completely different address, I honesly admit that I
don't know which address would be assigned.

I'm currently rewriting parts of the code to better support client
address and prefix reservations. Please contact me if you are interested
in testing and I will let you know when the code will be ready for testing.

The assignment policy will be as follows:

1. Client classification is performed (i.e. client assigned to a client
class, if such class is defined and client should belong to it)
2. Access control using black and white lists (accept-only and
reject-clients)
3. Existing lease if exists
4. Fixed lease for a client (client exception, i.e. address reserved
uniquely for this client)
5. max-client-leases check (if client is allowed to get another address)
6. cache (is there a lease that client got previously?)
7. client's hint (did client sent something in IAADDR in IA_NA?)
8. random address

I'm considering switching steps 3 and 4. Prefix delegation will follow
the same policy, but I intend to implement it for addresses first and
see if it works out.

I would love to hear your comments about this approach. This is
significant code update, so it will take some time. I'm afraid that new
bugs may be introduced in the process, but I'm also going to implement
unittests and system tests to verify that the behavior does not degrade
(too much :).

Sorry for delayed response. I'm (mostly finishing) business trip.

Cheers from Silicon Valley,
Tomek Mrugalski


More information about the Dibbler mailing list