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

[Daniel Theisen]

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 <babut at yandex.ru> 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
> Kea-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/kea-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20221117/3c8ce38e/attachment-0001.htm>