>> but i want several addresses AT THE SAME TIME. this is stated in rfc8415. and
>> here is what is said about rfc8415 in the kea documentation:
>> --------
>> The server will allocate, renew, or rebind a maximum of one lease for a
>> particular IA option (IA_NA or IA_PD) sent by a client. RFC 8415 allows for
>> multiple addresses or prefixes to be allocated for a single IA.
>> --------
>> MAXIMUM ONE! ;) but of course i tried, since i don't have a mailing address
>> ending in "isc.org" ;) here is the config for the test:
>> --------

> rfc8415 also says that your client has to request multiple IA_NA and/or IA_TA 
> and/or IA_PD in the same packet.  Is your Windows client doing that?  Once 
> more, you can confirm with wireshark.  That is the first thing to confirm 
> before you start pointing fingers at Kea and saying it won't support this or 
> that feature.

>> the behavior of the server has changed, now there are two "solicit" requests 
>> and
>> two "advertise" responses, but each response has one IA_NA. it seems that 
>> this
>> is not what it should be according to rfc8415. the trouble is that although 
>> the
>> proposed addresses in each response are different(go in order), but they are
>> both from the same (first in the config) network, and the windows client
>> selects the last one from them.
>> what am i wrong about?

>> ps: version is 2.2.0, but i looked at the changelog and there are no changes 
>> on
>> this issue

> In my experience, your windows client is only going to be looking for one 
> IA_NA unless you have written your own DHCP client (maybe it will ask for an 
> IA_PD if it has somehow been configured to be a router - i've never tried 
> that).

i see that you haven't read the rfc. it's okay, i haven't read it either ;) 
instead of reading long rfcs, moreover, written in a bad style, often allowing 
ambiguity of interpretation, you can think about how to design this thing if 
you could design it. the first thing is the starting point. at this point, the 
server knows(or rather assumes. its assumptions are based on its config and the 
configuration of an interfaces it serves) almost everything about the network, 
and the client practically nothing(he knows his mac and how to search for the 
server. he doesn't even know if there is a server at all)- this is a typical 
situation, to get out of which dhcp was created. can a client request multiple 
networks in such a situation? if so, then he doesn't really need dhcp. i'll 
give you an analogy. you go into a restaurant to eat. if you have food with 
you, then you don't need to go to a restaurant. so, you're in a restaurant. can 
you order any dishes? no, you can't. first of all, you need so
 meone who will accept your order. secondly, you need a menu, because you may 
be a vegetarian, and there may not be such dishes in a restaurant. so you call 
the waiter and ask him to show you the menu with all available dishes, choose 
the ones you need and place an order. or you can turn around and leave. there 
is no need to reinvent the wheel, this is a typical situation that can be found 
in life every day. and when you say "did your client request multiple networks 
from the server before the server offered him just one?", then you assume the 
existence of a f**king time machine from the client! :D

-- 
ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.

To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.

Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users

Reply via email to