HI Darren!
A client sends a SOLICITATION message to the network when it connects to
the network. It then receives a ROUTER ADVERTISEMENT message with the
available addresses and routers. Now there are currently two address
ranges included, one for the GUA and one for the ULA. (See overview
sketch here:
https://dokuwiki.nausch.org/doku.php/linux:radvd#grundlagen_hintergruende )
The CLIENT then sends a DHCPDISCOVER message to the HDCP6 server, but
only one request, mind you. The kea-dhcp6 daemon responds with only ONE
DHCPOFFER message, although it has two defined address pools, one for
the GUA and one for the ULA. Since the GUA pool comes first in
kea-dhcp6.conf, only the GUA is included in the DHCPOFFER message, the
poll for LUA is defined, but it is not addressed at all. This would
require the client to be able to send a new LUA-specific DHCPDISCOVER
message, which it def. does not do.
My idea of distributing IPv6 Statfull Addresses (GUA and LUA) via HDCPv6
is therefore fundamentally doomed to failure. I think the best thing
will be to distribute only GUA stateful in the intranet and bury the ULA
issue. It was a nice idea to use both, but it will never work that way!
So get rid of the LUA and only use GUA on the intranet!
Best regards
Django
--
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
