[Kea-users] yet another question about multiple subnets %)

[3]

>> "shared network" is not about how to allocate multiple addresses(it doesn't matter if we have one pool or several), but about how to combine several pools into one.
> Almost - it’s about how to have multiple (IPv4) subnets/(IPv6) prefixes on one wire.
where do you see even a word about this in the documentation? in any documentation, not only for kea, the "shared network" is referred to as a pooled pool of addresses from which the dhcp server will take an address to assign to the client. could you quote exactly the place where it says about allocating multiple addresses at the same time from the pooled pool?

>> A client connected to a shared network may be assigned a lease (address or prefix) from any of the pools defined within the subnets belonging to the shared network. Internally, the server selects one of the subnets belonging to a shared network and tries to allocate a lease from this subnet. If the server is unable to allocate a lease from the selected subnet (e.g., due to pool exhaustion), it uses another subnet from the same shared network and tries to allocate a lease from this subnet. The server typically allocates all leases available in a given subnet before it starts allocating leases from other subnets belonging to the same shared network. 


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

> As has already been said, your client will need to ask for multiple addresses/prefixes. The client knows (for IPv6) the prefixes configured for any link from the RAs it receives.
no RA is needed for dhcpv6 to work. these are different protocols, different group addresses. moreover, there may not be a router in the network at all, but what does this have to do with dhcp(no matter v4 or v6)? maybe you are confusing ff02::1:2 and ff02::2? these are not the same thing, they are generally different things. so when we don't have a router with its RA on the network, the client cannot request something specific in any way(but to request two, three, etc. addresses is to request something specific) before the server tells him about the existence of this particular one. can't you see that you're traveling in time?

> However, as this thread has highlighted, one of the complications of multiple prefixes by default (having only one is simply multiple prefixes where “n=1”) is that there is then the gap in how to inform clients how they are expected to use them. Having been following a couple of IETF mailing lists, this is not yet a solved problem - and I suspect may never be due to the complexity involved to cover all situations.
> One particular variation involves having two (or more) upstream internet providers - each providing a different prefix. There is currently no portable way to inform clients how to use the different prefixes - hence calls by some for NPT (network prefix translation) so that the network layer (i.e. routers) can route packets according to admin defined rules (e.g. email via a cheap but high latency link, web browsing via an expensive but low latency link), or switch routing on the fly (e.g. switching to a backup link if the primary fails).

> Having said that, if there is a GUA and a ULA advertised, then it would be logical for a client to request addresses from both and use them accordingly - ULA for communications with other ULA addresses, GUA for everything else.
do you want to talk about how this can be implemented? the answer is simple- you do not need to tell the client how to live, especially since you do not have any levers to force him to fulfill your requirements. the router can at least block traffic from the rebel, but the dhcp server does not have such an opportunity. therefore, all you can do as a dhcp server is to offer the client all the prefixes that you have- the client will choose the ones he needs and notify you of his choice in a reply message. you will only have to keep track of this connection. it's obvious! dhcp is not a tool for political repression of clients, like go here and don't go there %). a router should deal with such repression- it exists for this very purpose. what makes you think that dhcpv6 is being developed by mad people? :D
one more time: address allocation and traffic routing are completely different tasks that practically do not overlap. at least because there may not be a router on the network, but ip addresses will still needs