KEA is still a mess IMHO

[JamesFrisch]

I know a lot of work went into KEA and I truly believe that a lot of bugs were ironed out with the recent release.
Still, KEA is IMHO not polished and production ready.

One example:
1. You have a static IPv4 reservation (based on MAC)
2. You create a IPv6  reservation, based on the same MAC

KEA will now ignore your IPv4 reservation. Yes, it worked before, but now no longer works and instead will get an IPv4 from the DHCPv4 range, while IPv6 will do the reservation correctly.

But James, you should DUID and not MAC for IPv6

Fine, but then it should not use MAC when I click on the "add static lease" button in the lease tab, but DUID instead.
Also, since the newest update, I can no longer see the DUIDs anymore on OPNsense?


So if you think just because ICE is eol that you should switch to KEA, don't! Don't make the same mistake I did.
There is still no need to make the switch. At least not for now.

[franco]

Is this about OPNsense core integration or Kea (DHCPv6) in general? I'm unable to tell.


Cheers,
Franco

[JamesFrisch]

I'm unable to tell.

Me too ;) no seriously, I have this issues with OPNsense, but of course it could also be KEA that is the root issue.

[RES217AIII]

I do not believe KEA is the problem; rather, it is DHCPv6. Centralized address allocation runs counter to the design of IPv6, which is predicated on autonomous address assignment.
However, this presents a challenge for the network administrator who wishes to manage and structure their network in distinct zones.
One has two options: either continue using IPv4 for the internal network—retaining the familiar segmentation based on IP addresses—and restrict IPv6 usage solely to external traffic; or, structure the network not by IP addresses, but by interfaces (VLANs), groups, or segments. Given the immense number of potential addresses enabled by IPv6, one could theoretically assign each individual device its own interface with a unique address (via Prefix Delegation down to the host level).
Those who truly leverage IPv6 manage traffic at the boundaries of their network segments (via firewalls), rather than through the micromanagement of static leases.

[JamesFrisch]

That is a little bit off topic, because my issue is more about OPNsense offerin MAC based reservations, which according to some folks on github is against IPv6 philosophy. And because of that, they have not accounted for certain situations and you run into errors.

Maybe I am misunderstanding you, but IMHO your idea falls flat, because I only need static leases for services. And for that I need a static IPv6.


I can't say to NGINX:
My static /48 prefix is 2000:2000:2000::, my service is in the vlan 30, which has the prefix 2000:2000:2000:30:: so proxy pass to 2000:2000:2000:30:: and somewhere in there is my destination, go find it.

[Monviech (Cedrik)]

Essentially with SLAAC (Router Advertisements) most devices should receive an EUI-64 based "management" IP address, that is stable (based on device MAC address) and static, which can be used for inbound connections.

So DHCPv6 IA_NA address is generally not that important.

As I said on github, the duid missing is a small bug right now that has been fixed in the PR I mentioned there.

[RES217AIII]

I don't want to be misunderstood—I am far from being a networking expert. Rather, I am grappling with the very same issues regarding the implementation of fixed IPv6 assignments, network segmentation, and access control. In that sense, I used this thread as an opportunity to better understand—through discussion—how our specific problem might be solved without forcing the IPv6 structure into a straitjacket that runs counter to its fundamental design principles. Couldn't we simply assign a ULA to Nginx instead of relying on a static assignment via DHCPv6? In the IPv6 world, devices are capable of having—and indeed typically do have—more than one address: a GUA assigned via Router Advertisement to enable communication with the outside world, and a ULA for internal purposes, ensuring the device can be reliably located within the local network.

[Patrick M. Hausen]

I can't say to NGINX:
My static /48 prefix is 2000:2000:2000::, my service is in the vlan 30, which has the prefix 2000:2000:2000:30:: so proxy pass to 2000:2000:2000:30:: and somewhere in there is my destination, go find it.

All my servers use SLAAC. The addresses are stable unless I change the MAC address of the server for some reason. I can then point Caddy (or NginX in your case) at these addresses. DHCPv6 is rarely needed.

[meyergru]

Exactly. It is also true that any IPv6 device can have more than one address.

Thus, for the purposes of reachability, you can always have the EUI64-derived addresses. Even in the case of dynamic prefixes, you can use OpnSense's dynamic DNS facilities to handle any EUI-64 in lieu of the device.

If need be, you can use ULAs with fixed MAC- or DUID-derived lower 64 bits for local addressing (with the caveat that IPv4 will be preferred if it exists).

For egress, the actual IPv6 being used is irrelevant and many people even prefer to use IPv6 privacy extensions.

Thus, Patrick is correct in saying that for the most part, DHCPv6 is unneeded, which is why I advise against it here and why I do not notice any Kea DHCPv6 shortcomings - I do not use that for many reasons given in the article.

Maybe the underlying problem is that people try to apply IPv4 concepts to IPv6.

[RES217AIII]

All my servers use SLAAC. The addresses are stable unless I change the MAC address of the server for some reason. I can then point Caddy (or NginX in your case) at these addresses.

Just to confirm my understanding:
This holds true
1. if either a static prefix from the ISP exists, combined with an autoconf-secured suffix (I use an Apple Mac) or the client's EUI-64-adress;
or
2. if a Dynamic IPv6 Host Alias is used, specifying the autoconf-secured suffix (I use an Apple Mac) or the client's EUI-64-adress within the alias.

[Patrick M. Hausen]

Desktop operating systems will normally use privacy extensions and not configure a stable address. But then why would they need one?

[RES217AIII]

Apologies for the lack of precision in my phrasing.
The discussion centered on server reachability; a server requires a unique address in order to be located. Therefore, my clarifying question does not pertain to clients, but rather to servers!

[meyergru]

With SLAAC, either OS uses an IPv6 with a statically derived suffix. It can choose this and most OSes do it via EUI-64. E.g., Windows 11 chooses an abritrary, but fixed suffix, too.

So, you can work with that suffix for firewall rules and - in case of dynamic prefixes - for dynamic DNS updates, as well, for ingress. It does not even matter if privacy extensions are being used for outbound access.

[OPNenthu]

Dnsmasq cannot register the IPv6 address of clients using privacy extensions, so maybe that is a win for Kea+DDNS?

BTW, my desktops usually have both a stable and a rotating privacy address.  I think most Linux desktops now enable them by default when a desktop environment is initially selected during installation.  I think the stable address on desktops is usually not EUI-64 but on server installs it is (and those would obviously also not be using privacy extensions).  At least this is my experience with some Debian-based ones.

[Monviech (Cedrik)]

How should KEA know about RFC 4941 addresses, it has nothing to do with Router Advertisements, or addresses that clients generate themselves. So there won't be any Dynamic DNS updates for any of those addresses.

The main dissonance here is that the authority of the IPv6 addresses belong to the client, generally the client should decide whatever happens with their addresses. In IPv4, NAT took care of centralizing the identity to the router in most networks that used RFC1918 addresses, for "a comparable" experience in IPv6 you need ULAs and all of the mess they are.