AI contributions are only a part of the issue. Another part is where a contributor decides they want a specific feature and contributes it but then disappears off into the sunset when it comes to needing maintenance later.
Having services be accessible on a link-local address and then advertising that service via mDNS is a completely legitimate use-case that works extremely well and is extremely common with Apple devices amongst others. The advantage being that it still works just the same even without a router handing out addresses or if you just connect two devices directly to each other.
Also what gives you the impression that zones were “deemed a mistake”? They may be awkward in URIs but they are very much not a mistake, they are a deliberate part of ensuring that each link has its own link-local subnet without any ambiguity. It solves the problem of what the operating system should do if you need to access a link-local address that shows up via more than one network interface, which is a very real problem with unscoped IPv4 link-local addresses.
Finally, ULAs don’t and were never intended to replace link-local addresses, they serve a different purpose entirely.
> Finally, ULAs don’t and were never intended to replace link-local addresses, they serve a different purpose entirely.
Right, but ULAs are the correct answer here because the purpose they serve is exactly the one the article is trying to hack around with link-local addresses. Like most "IPv6 is hard" articles, the main issue with this one is the author simply refusing to learn how IPv6 works or follow best practices.
ULAs are not hard to set up. You just need one device to broadcast Router Advertisements with the "A" flag set and router priority 0. That device may be the same one hosting the service!
> Also what gives you the impression that zones were “deemed a mistake”?
I disagree that zones are a mistake, but a good rule of thumb is that if you're trying to use zones and you're not writing system code, you're probably holding it wrong. Use IPv6 the right way and your life will be so much easier.
> Having services be accessible on a link-local address and then advertising that service via mDNS is a completely legitimate use-case that works extremely well and is extremely common with Apple devices amongst others.
Apple devices actually advertise services to hostnames via mDNS. Hostnames are then resolved to IP addresses, again via mDNS. While link-local address are populated in the host table, so are the routable addresses as well as the ULA-prefixed addresses (if your network uses ULAs).
Note you can also advertise a ULA prefix without the A flag. The advertisement tells other machines that the IP is on-link, and they can use their own GUA addresses to connect without needing a ULA address of their own.
You could also assign a single address (e.g. fd53::1/128) and advertise the corresponding prefix of fd53::1/128, so you don't even need a whole ULA prefix, just individual addresses. (This is sometimes useful if you use a router you can't configure and it's advertising a DNS server you don't want to use.)
When I say “zones” I’m referring to site-local addresses specifically which were deprecated and replaced by ULAs because zones in anything other than link local addresses were declared stupid and hard to implement. That may be where the confusion is coming from. I’m sorry I didn’t use specific language. I understand what we commonly call the “interface scope” is technically a “zone id”.
mDNS working on link-local means you can advertise your service over mDNS so no user ever types this shit into their address bar in the first place.
I still maintain that the interface leaking into the address is a bad thing from a design perspective even though I very much appreciate that everything works naturally on v6 LL addresses after applying this one small fix… no user should ever by typing a v6 LL into a browser, and probably every use case you can imagine that isn’t managing network link topology or NDP/bootstrap or running LL name resolution can be solved with ULAs or DNS.
I would add that there is no particularly good reason for an EV to have a push-to-start button. With Volvo, Polestar etc, you get in and shift straight into Drive or Reverse, and when you’re done, you put it into Park and climb out again. This is how it should be.
None of MeshCore, Meshtastic or Reticulum will scale well, especially not on top of a heavily constrained radio technology like LoRa. Flooding is inefficient for obvious reasons, AODV-esque routing (which MeshCore tries to do for DMs and Reticulum tries to do in general) is prone to almost-immediate path failure on unstable underlying transports, and the hidden node problem always bites on haphazard/unplanned mesh radio deployments where people show up with nodes in random locations on the same frequency.
The cracks are already extremely visible in MeshCore in the UK, where overheads from adverts and dropped packets from collisions mean it is already horrendously unreliable and most of the chatter in the Public channel is people sending test messages and being unsure whether anything they sent was ever heard by anyone.
Most other routing protocols (BATMAN included) are also not that well suited to situations where the underlying transport ends up asymmetric, e.g. one node can't hear others but it can be heard, and that's an extremely common occurrence/failure mode in wireless meshes like this. It's a difficult problem to solve with coordination between nodes, let alone without.
You have two conditions: not dense enough or too dense and the fractal nature of population mean you can have both. Radio bandwidth is a precious resource and if you think somehow that anything good will come out of sending a packet N times you are not likely to manage a wireless network successfully.
Incoming voltage monitoring is a requirement for EV chargers in the UK. The sudden huge demand would result in a voltage drop, the chargers would then detect the under-voltage condition and they'd stop charging.
Google's QuickShare contains a reverse-engineered AWDL implementation that works on Pixel and a few other phones.
As for WiFi NAN: support for it seems rather limited outside of iOS and Android. From what I can tell the feature is barely tested on Linux and I can't find any generic Windows APIs for it either.
I've definitely used STA and AP modes concurrently on my Windows laptop with the operating system's built-in internet connection sharing function to help troubleshoot a problem in the field.
That was around a decade ago. It didn't take any extra effort on my part; I just told it to do the thing, and then it did that thing.
Researched this for a bit: there is some hardware for PCI supporting it, but Windows 10/11 not, and Linux is still work in progress, so no real support on OS level, only for some iOS/Android devices.
it might be interesting to use unused or extra wifi cards to support this. My pc motherboard has both wifi and ethernet and I only use the ethernet. That card does absolutely nothing at all.
reply