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

[3]

>> RFC 8415 DHCP for IPv6 November 2018

>> 6.6. Multiple Addresses and Prefixes

>> DHCP allows a client to receive multiple addresses. During typical
>> operation, a client sends one instance of an IA_NA option and the
>> server assigns at most one address from each prefix assigned to the
>> link to which the client is attached. In particular, the server can
>> be configured to serve addresses out of multiple prefixes for a given
>> link. This is useful in cases such as when a network renumbering
>> event is in progress. In a typical deployment, the server will grant
>> one address for each IA_NA option (see Section 21.4).

>> A client can explicitly request multiple addresses by sending
>> multiple IA_NA options (and/or IA_TA options; see Section 21.5). A
>> client can send multiple IA_NA (and/or IA_TA) options in its initial
>> transmissions. Alternatively, it can send an extra Request message
>> with additional new IA_NA (and/or IA_TA) options (or include them in
>> a Renew message).

> This says that the server can assign multiple addresses but the client is in the driver's seat.  Is your WIN10 device asking for multiple IA_NA or IA_TA?  You can check with Wireshark (https://www.wireshark.org/).  It says that by default, the server will allocate only one address.  It wouldn't make sense to send multiple addresses to a client that didn't ask for them.

>> The same principle also applies to prefix delegation. In principle,
>> DHCP allows a client to request new prefixes to be delegated by
>> sending additional IA_PD options (see Section 21.21). However, a
>> typical operator usually prefers to delegate a single, larger prefix.
>> In most deployments, it is recommended that the client request a
>> larger prefix in its initial transmissions rather than request
>> additional prefixes later on.

>> The exact behavior of the server (whether to grant additional
>> addresses and prefixes or not) is up to the server policy and is out
>> of scope for this document.

> Here it is saying that it is technically possible to send multiple prefix (several /64 lets say).  But, again, that doesn't make sense as you can just allocate a larger than /64 prefix and let the client break it apart as needed.  If your client (WIN10?  Didn't realize WIN10 even cared about prefix delegation) needs multiple networks (subnets), configure your client to ask for a /60 instead of a /64 and your server to allocate anything up to a /60.  Then, it's up to the client to break up the prefix and assign the smaller subnets to the appropriate interfaces.  The ISP router (or whatever) will add a route to your client for the entire prefix and your client will be responsible for what happens after that.

Identity Association for Non-temporary Address
    Option: Identity Association for Non-temporary Address (3)
    Length: 12
    IAID: 0fa0a8cd
    T1: 0
    T2: 0
--------
here the client can request the previous address via the IA Address field, but the server can ignore this request so it doesn't matter
--------
Identity Association for Non-temporary Address
    Option: Identity Association for Non-temporary Address (3)
    Length: 40
    IAID: 0fa0a8cd
    T1: 1800
    T2: 2880
    IA Address
        Option: IA Address (5)
        Length: 24
        IPv6 address: fc00:0:0:85::14
        Preferred lifetime: 3600
        Valid lifetime: 7200
--------
-Each IA_NA carries one "set" of non-temporary addresses; it is up to
-the server policy to determine how many addresses are assigned, but
-typically at most one address is assigned from each prefix assigned
-to the link to which the client is attached.

since all communication between the client and the server can consist of two or four packets(as stated in the rfc), this means that there cannot be several server responses with different IA_NA values, which means that the server should have several IA_NA in one response if it required by server's config. i don't know english well, but in my opinion the rfc quite clearly says about one address from EACH PREFIX. therefore, what the client wants there, what his plans for the future are, what he thinks about the structure of the world- the server does not care about all this, and this is how it should be, because this is the right approach. the server has only one task- to offer the client everything he has. or make concessions to the client and limit yourself only to the part that the client requests. i do not request IA_TA and not given it to me. but with IA_NA, it's a completely different matter- the client does not have a mechanism to request several of them. in my opinion, the person who wrote this part of the rfc clearly understood life. the remaining two packages are about additional options and are not relevant to the question. and when you say that the client should steer the server, then i think that you have very strange views on the world! %\ it is not necessary to make assumptions that it is easier for the client to do. it's not the server's business at all how the client will deal with the information received from the server, the client can simply send it to /dev/null- these are his rights and you won't do anything to him :D i literally ran into a situation the day before yesterday when the author of miniupnpd from my router makes some fascist assumptions about a higher-level router and based on them refuses to open ports on my router. how does he even know what's above me, where i am and this f**king world?! maybe we are in the eye of a giant? :D you don't have to teach people your life, these people have their own life. i'm sorry, i'm too talkative, but it seemed to me that you wanted to talk about it ;)