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.
QuoteBut 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.
Is this about OPNsense core integration or Kea (DHCPv6) in general? I'm unable to tell.
Cheers,
Franco
Quote from: franco on May 07, 2026, 10:46:17 AMI'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.
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.
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.
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.
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.
Quote from: JamesFrisch on May 08, 2026, 07:33:12 AMI 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.
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 (https://forum.opnsense.org/index.php?topic=45822.0) 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.
Quote from: Patrick M. Hausen on May 08, 2026, 08:01:56 AMAll 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.
Desktop operating systems will normally use privacy extensions and not configure a stable address. But then why would they need one?
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!
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.
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.
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.
Quote from: RES217AIII on May 08, 2026, 10:38:30 AMApologies 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!
Then how does "I use an Apple Mac" come into play here? You are running public services on Mac OS?
Quote from: Monviech (Cedrik) on May 08, 2026, 11:23:57 AMThe 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.
It is almost philosophical in the sense of freedom. Clients—or network participants—regain their autonomy, liberated from the dictates of the network administrator. However, the administrator remains responsible for the network's structure and security—and this responsibility necessitates control.
Since IPv6 permits the use of multiple addresses simultaneously, this strikes me as no contradiction; consequently, ULAs are neither a hack nor a chaotic mess.
In my opinion ULA only networks are a bad choice. Using them together with GUAs is fine in my opinion.
IPv6 allows for so many setup possibilities that most suggestions are also personal opinions spiked with individual taste.
Quote from: Patrick M. Hausen on May 08, 2026, 11:37:41 AMThen how does "I use an Apple Mac" come into play here? You are running public services on Mac OS?
No, these are not public services, but rather a server hosted on the internal network. If I wanted to make this server accessible exclusively via IPv6, wouldn't it require a fixed address? Currently, I have implemented this on a trial basis using a ULA. The prefix consists of a virtual IP, followed by a suffix that the Mac generated for itself via stateless autoconfiguration. I have shared this address with the network clients that require access to the server.
Have I misunderstood something?
Quote from: Patrick M. Hausen on May 08, 2026, 10:27:22 AMDesktop operating systems will normally use privacy extensions and not configure a stable address.
But then why would they need one?
Don't they have both and only use the Privacy Extension one for Internet Connectivity ?!
And the reason they need one is so we can check if they are doing naughty things in our
Pi-Hole Query Log & Statistics :P
Quote from: OPNenthu on May 08, 2026, 11:00:26 AMDnsmasq cannot register the IPv6 address of clients using privacy extensions, so maybe that is a win for Kea+DDNS?
Not just the Privacy Extension one or any IPv6 Address ?!
QuoteBTW, my desktops usually have both a stable and a rotating privacy address.
That is what I would expect from any Client to be honest...
QuoteI 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.
I think you can change the preferences to whatever you like most anyway in most situations so I don't see any issue there for now :)
But to reply directly to the subject mentioned in the title of this topic and it's first post :
I think that in general KEA has been released a bit too early and ISC DHCP Server has been EOL-ed a bit too soon too!
My best guess is that KEA needs about 5 years of additional development to close the gap with ISC DHCP Server.
Maybe even a bit more...
I must be the only one here who's seen many dupe macs on laptops and pc's. This is relevant in million VLAN architecture but an absolute nightmare in IPv6. Anywho, please move along nothing to see here...
lol
Quote from: lilsense on May 08, 2026, 07:07:27 PMI must be the only one here who's seen many dupe macs on laptops and pc's.
I'm a network engineer for more than three decades and I have never seen a single duplicate MAC address. 🤷�♂️
Quote from: Patrick M. Hausen on May 08, 2026, 10:50:30 PMQuote from: lilsense on May 08, 2026, 07:07:27 PMI must be the only one here who's seen many dupe macs on laptops and pc's.
I'm a network engineer for more than three decades and I have never seen a single duplicate MAC address. 🤷�♂️
I've only ever heard of this once and it was some 30 years ago, from someone I knew. They had supplied a school with new computers and installed NIC's in all of them.
The first computer connected to the network and worked just fine. When more computers were connected to the network, problems ensued and they were all failing to communicate - the root cause was the (cheap and cloned) NIC's, which all had the same MAC address.
The only time I would expect to see the same MAC address used more than once, is if the interface is configured with VLAN's.
Off-beat, I am aware of a Ubiquiti device failing spectacularly and deciding it wanted to claim to have the address for every ARP request seen on the network and offered its MAC address in response.
Quote from: lmoore on May 09, 2026, 03:02:36 AMThe only time I would expect to see the same MAC address used more than once, is if the interface is configured with VLAN's.
As in VLAN Interfaces ? I would too :)
OK, I implied duplicate in the same broadcast domain.
Quote from: Patrick M. Hausen on May 08, 2026, 10:50:30 PMQuote from: lilsense on May 08, 2026, 07:07:27 PMI must be the only one here who's seen many dupe macs on laptops and pc's.
I'm a network engineer for more than three decades and I have never seen a single duplicate MAC address. 🤷�♂️
Four decades here, sounds super old... I have seen it as recent as in last 10yrs with the same manufacturer with diff NICs one on a laptop and other on a PC. Dupe MACs are here to happen is a fact. Reliance on them as an IPv6 is a crap shoot that I will not recommend losing job over. :D
To elaborate, the IPv6 should include at least the vlanID .
Pardon me for my ignorance, but isn't all of that besides the point?
If indeed two devices in the same broadcast domain do have the same MAC for whatever reason, you will be out of luck anyway, because both will use the same ethernet header and that is independent of IPv4 with ARP or IPv6 with NDP.
Quote from: nero355 on May 08, 2026, 04:51:00 PMQuote from: OPNenthu on May 08, 2026, 11:00:26 AMDnsmasq cannot register the IPv6 address of clients using privacy extensions, so maybe that is a win for Kea+DDNS?
Not just the Privacy Extension one or any IPv6 Address ?!
Sorry, couple days late responding...
I misunderstood about Kea (clarified by @Monviech).
As for Dnsmasq, my understanding is that SLAAC addresses are only registered if the host has both an IPv4 reservation and is using EUI-64. When you have privacy extensions enabled, it doesn't know what to register and so you get an A record only in DNS.
I could be wrong about this but that's what I observe on my desktop and also how I interpret this part of the manual (https://dnsmasq.org/docs/dnsmasq-man.html) (under --dhcp-range):
Quotera-names enables a mode which gives DNS names to dual-stack hosts which do SLAAC for IPv6. Dnsmasq uses the host's IPv4 lease to derive the name, network segment and MAC address and assumes that the host will also have an IPv6 address calculated using the SLAAC algorithm, on the same network segment. The address is pinged, and if a reply is received, an AAAA record is added to the DNS for this IPv6 address. Note that this is only happens for directly-connected networks, (not one doing DHCP via a relay) and it will not work if a host is using privacy extensions. ra-names can be combined with ra-stateless and slaac.
Even if it does use privacy extensions, it will most probably have an EUI-64-based management IPv6. I have never seen any client using privacy extensions with no management IP as well. As the name suggests: Those are extensions, which means those addresses are used "on top" of any other assigned IP for outbound connections only.
Thus, for addressability, you can always use the management EUI-64 IP. DNSmasq only makes use of that convention and it does not even handle the case when a DUID is used instead of the MAC.
If you have static prefixes, then you can guess what the IP will be, so you do not strictly need DNSmasq. If you have dynamic prefixes, you can at least guess the EUI-64 part (regardless of MAC or DUID) and use that for a dynamic DNS entry that is managed by OpnSense.
Quote from: meyergru on May 10, 2026, 05:08:23 PMEven if it does use privacy extensions, it will most probably have an EUI-64-based management IPv6. I have never seen any client using privacy extensions with no management IP as well. As the name suggests: Those are extensions, which means those addresses are used "on top" of any other assigned IP for outbound connections only.
Thus, for addressability, you can always use the management EUI-64 IP.
That's how I have always understood the whole Privacy Extension thing to work too, but I never got to use it so far because my last two ISP's didn´t/don't have IPv6 sadly :)
Sorry guys, it's not a safe bet that there will always be an EUI-64 address present. I agree there will be a stable address, but it can be what's known as a 'stable privacy' address not related to the MAC and thus not able to be guessed by Dnsmasq.
For example:
3: enp10s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 24:xx:xx:xx:77:cd brd ff:ff:ff:ff:ff:ff
inet 172.21.30.100/24 brd 172.21.30.255 scope global dynamic noprefixroute enp10s0
valid_lft 77087sec preferred_lft 77087sec
inet6 fd5a:xxxx:xxxx:1003:5dec:dd53:a78e:2964/64 scope global temporary dynamic
valid_lft 86375sec preferred_lft 76947sec
inet6 fd5a:xxxx:xxxx:1003:xxxx:610f:948:xxxx/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86375sec preferred_lft 86375sec
inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link noprefixroute
valid_lft forever preferred_lft forever
The management address here ("mngtmpaddr") does not have the signature "ff:fe" bits in the host part and the 'tmp' in the name gives it away. The host is using this:
stable-privacy-setting.png
"EUI64" is the other option on the drop-down menu, but they are mutually exclusive.
Can we let this thread die now please? Its not about KEA anymore. For general discussions about IPv6 please open a new thread.
Since I develop a lot in the current KEA implementation I'd like actionable tickets that can be solved.
Thank you :)
Quote from: Patrick M. Hausen on May 08, 2026, 08:01:56 AMAll 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.
Interesting, I thought that I had changing IPv6, but that was in the beginning of my journey. So maybe I looked at the privacy extended IPv6 back then. So in theory, I could ditch DHCPv6, and go with SLAAC only you think?
Hmm... I have to think about that, I quiet liked to have 10.10.50.4 and 2000:2000:2000:50::4 for simplicity.
Quote from: Monviech (Cedrik) on May 10, 2026, 07:24:09 PMCan we let this thread die now please? Its not about KEA anymore. For general discussions about IPv6 please open a new thread.
Why not just move it to the
General Discussion sub-forum ?!
Quote from: meyergru on May 09, 2026, 03:55:49 PMPardon me for my ignorance, but isn't all of that besides the point?
If indeed two devices in the same broadcast domain do have the same MAC for whatever reason, you will be out of luck anyway, because both will use the same ethernet header and that is independent of IPv4 with ARP or IPv6 with NDP.
Sure. Obviously you can replace the PC and move that dupe PC to another network or tell the OS to use a diff MAC. The point here was the when running SLAAC the end user may not know how to correct the dupe IP.