KEA is still a mess IMHO

[Patrick M. Hausen]

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!

Then how does "I use an Apple Mac" come into play here? You are running public services on Mac OS?

[RES217AIII]

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.

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.

[Monviech (Cedrik)]

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.

[RES217AIII]

Then 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?

[nero355]

Desktop 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

Dnsmasq 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 ?!

BTW, my desktops usually have both a stable and a rotating privacy address.

That is what I would expect from any Client to be honest...

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.

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...

[lilsense]

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

[Patrick M. Hausen]

I 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. 🤷�♂️

[lmoore]

I 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.

[nero355]

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.

As in VLAN Interfaces ? I would too :)

[Patrick M. Hausen]

OK, I implied duplicate in the same broadcast domain.

[lilsense]

I 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 .

[meyergru]

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.