Hello 3, As Simon has previously pointed out a number of times, a client must send multiple IA_NA’s in a request to get multiple addresses. This is discussed in section 6.6 Multiple Addresses and Prefixes of RFC8415 (https://datatracker.ietf.org/doc/rfc8415/ <https://datatracker.ietf.org/doc/rfc8415/>)
As per the Kea documentation, you can find the specific reference to how we handle Multiple Addresses with Host Reservations in this section in the ARM: https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#host-reservations-in-dhcpv6 <https://kea.readthedocs.io/en/kea-2.2.0/arm/dhcp6-srv.html#host-reservations-in-dhcpv6> > DHCPv6 allows a single client to lease multiple addresses and multiple > prefixes at the same time. Therefore ip-addresses and prefixes are plural and > are actually arrays. When the client sends multiple IA options (IA_NA or > IA_PD), each reserved address or prefix is assigned to an individual IA of > the appropriate type. If the number of IAs of a specific type is lower than > the number of reservations of that type, the number of reserved addresses or > prefixes assigned to the client is equal to the number of IA_NAs or IA_PDs > sent by the client; that is, some reserved addresses or prefixes are not > assigned. However, they still remain reserved for this client and the server > will not assign them to any other client. If the number of IAs of a specific > type sent by the client is greater than the number of reserved addresses or > prefixes, the server will try to assign all reserved addresses or prefixes to > the individual IAs and dynamically allocate addresses or prefixes to the > remaining IAs. If the server cannot assign a reserved address or prefix > because it is in use, the server will select the next reserved address or > prefix and try to assign it to the client. If the server subsequently finds > that there are no more reservations that can be assigned to the client at > that moment, the server will try to assign leases dynamically. Thanks, Dan Theisen ISC Escalations Engineer > On Nov 17, 2022, at 10:21 AM, 3 <[email protected]> wrote: > >>> seriously? i just killed rad and reconnected the client. shall i tell you >>> what has changed? NOTHING! do you think the dhcp client in windows is >>> wrong? if so, then will have to redo the rfc for windows, and not windows >>> for rfc. lol >> Did you tell the client to release its leased address ? No ? In that case, >> the DHCP client will continue to keep the address configured until it >> expires (or another network event causes it to become invalid). > dear, do you take me for an idiot? of course i deleted the leased address and > looked at the dhcpv6 frames. i tell you again- check your statements in > practice, otherwise it will turn into trouble for you someday. > >>> exactly, there may not be a router. do you know what the problem with >>> link-local addresses is? they can be random! >> They shouldn’t be random, on an ethernet network they will be based on the >> MAC address and will be stable as long as the MAC address is stable. > so, i see that you know even less than me. this is due to a device tracking > issue. it's a long time to write, google it. > ps: damn it, i came here for help, and it turns out i have to help %) > >>> and often this is not what we need. besides, if everything is so good with >>> link-local, then why do local unicast addresses exist? ;) >> Different address types have different uses. >> You may have seen 169.254.n.n addresses in the IPv4 world when there is no >> DHCP server present. These self-assigned addresses fulfil a similar role to >> some of the uses for IPv6 link local addresses - specifically they allow a >> group of devices to use multicast DNS to find each other. mDNS underpins a >> number of discovery functions around finding printers, network shares, etc. >> But in a managed network, you would normally prefer to manage the addresses >> you put into the internal DNS. So rather than use a link local address for >> your internal web server, you would setup a ULA prefix and use that >> internally. As it’s independent of any upstream connections, it’s stable and >> under your control. >> For networks without a full time management team (even if that is a one >> person team), setting that up is usually “too hard” and not required. For a >> typical home network, the users don’t care about all that, they just want >> stuff “to work”. > i'm not stupid enough to tell me the basics ;) > >> If you have a prefix delegation, it’s (in most cases) not very useful unless >> the rest of the network knows how to reach that prefix. But even where there >> isn’t any routing involved, you still need RAs to tell devices what >> prefix(es) are available. > CHECK YOUR STATEMENT IN PRACTICE! >:( > > -- > 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 > [email protected] > https://lists.isc.org/mailman/listinfo/kea-users
-- 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 [email protected] https://lists.isc.org/mailman/listinfo/kea-users
