After recently working our way through UDP broadcasting and network subnetting all in the comfort zone of IPv4, it’s time to address the elephant in the room, the one wearing a bright neon ‘IPv6’ sign. Although it’s still very much a rumor at this point, supposedly IPv6 is slated to replace the venerable IPv4 protocol. Rather than just being IPv4-but-with-more-addresses, its designers took the opportunity to basically completely redesign the protocol for the futuristic world of the late 90s and the early 2000s.
Joking aside, IPv6 having been introduced in 1995 and still struggling to meaningfully displace IPv4 does invite some worries about just how easy it is to switch between these two fundamental internet protocols. Say if we wanted to join the future of the 2000s and adapt our software to speak IPv6 instead of IPv4, what would change about the aforementioned aspects of IPv4 UDP broadcasting and IPv4 subnetting?
Speaking as an ignorant developer who mostly knows IPv6 from those weird and hard to remember network addresses, as well as many broken router implementations, I’m not entirely convinced that I’m going to like what I’ll see.
Futuristic Broadcasting
We saw with IPv4 UDP broadcasting that it was mostly a matter of either determining the network interface’s broadcast address based upon its subnet, or playing things easy mode with the local broadcast address. In the case of IPv6 none of these things exist, however. This raises the question of how our lonely UDP packet can still ask everyone on an IPv6 network whether they have seen a particular network service.
The simple answer is that IPv6 has a special link-local multicast group at address ff02::1 that functions pretty much identical to an IP broadcast. This is the equivalent of IPv4 multicasting to address 224.0.0.1, so this isn’t technically a new feature, just that multicasting is optional in IPv4.
Even though IPv4 multicasting would seem to be generally implemented, it’s telling that despite spending a considerable amount of time researching IPv4 broadcasting I have not seen this ‘multicast to all’ feature used anywhere. Perhaps this makes IPv4 and IPv4 multicasting worthy of an article of their own in some fashion, as it seems to be a whole other supermarket of canned worms to peruse.
That aside, if we were to look at this from a slightly philosophical technical angle, then having broadcasting treated as just another type of multicasting does make a lot of sense. Rather than singling out a subset of nodes on the network interface, we just mash the ‘all’ option. Very simple and elegant in a way.
Subnet Things
Whereas IPv4 subnetworks are a delightful topic that can keep any sysadmin entertained for days and will happily explode the software written by an ignorant developer – who was until that moment blissfully unaware of subnets beyond /24 – IPv6’s designers took a look at this veritable source of entertainment and decided that they wanted none of this.
In IPv6 you get one subnet and it’s /64, and you will learn to love all of its 264 possible addresses. Since this makes for about four billion times the address space of IPv4 it does make for a compelling argument that it renders subnets unnecessary.
Of course, while certainly the people who hammered out the RFCs for IPv6 were happy with all these changes, it’s somewhat of a running gag that it’s the worst thing that has happened to sysadmins since IPv4.
A 2017 Standard
The slightly smaller elephant in the room that’s hiding in the shadow of the neon-sign-adorned IPv6 elephant is the one wearing a hand-scribbled RFC 8200 sign slung around its neck with a bit of bailing rope. This was namely when the IPv6 RFCs received the ‘Internet Standard’ level of maturity, leading some to question whether the push to switch to IPv6 during the years prior was at all warranted.
This little factoid is just one of the many problems that networking people have with IPv6. For example this 2020 rant by Teknikal_Domain, with the main focus being that instead of being just an IPv4 with 64-bit addressing space and some of the warts of IPv4 smoothed over, it saw fit to add many details and complexity that nobody asked for and fresh warts that could have been easily prevented.
The annoying thing is of course that IPv4 Internet address allocations have pretty much run out everywhere, meaning that you are either lucky right now to still have an IPv4 address, or you have to pay a hosting provider extra, or your Internet connection finds itself with only an IPv6 connection and the IPv4 side of things dumped behind carrier-grade network address translation (CG-NAT) that kills most IPv4-specific applications.
Transitioning from IPv4 to IPv6 is also a pain, as there’s no direct compatibility between the two protocols, with IPv6 supposed to ‘encapsulate’ IPv4 packets while using a dual network stack on the network equipment side of things. Unfortunately this also means that on the Internet you now have a section that’s IPv4-only, an IPv6-only subset and IPv4/v6-capable nodes that may or may not have a broken dual-stack implementation.
Obviously this doesn’t really help anyone, and there’s a strong argument to be made that for LANs IPv4 is really all you need.
A UDP Discovery Perspective
While the idea of cleaning up IPv4’s messy broadcast address options with a simple multicast option is a good one that I’ll definitely be giving a shot in IPv4’s multicast feature, and the lack of subnets a welcome simplification, the whole concept of service discovery gets a bit weird with IPv6.
The first is that IPv6 doesn’t do NAT and unless you use the non-routable prefix your LAN will not be private in the IPv4 NAT-ed LAN sense. Fortunately IPv6 does do NPT, which is essentially NAT, but with prefixes instead of addresses, so it’s totally different.
Although with routable IPv6 prefixes you could totally do a global address space service discovery, this would obviously be less than desirable. Since service discovery tends to be just about devices on the LAN anyway, this makes the use of IPv6 at the very least a questionable proposition, and a liability in the worst case.
Ultimately as nice as IPv6 seems in some respects, when you look at the whole package it really just makes you wish for it having been basically IPv4 with a larger address space and mandatory features like multicasting. For now this means that when it comes to e.g. my NyanSD service discovery library, I see no reason to use IPv6-style UDP broadcast, even the library already fetches the IPv6 address of any found service.
It’s totally possible that I’m wrong and that within a few years we’ll all be using IPv6-only on our LANs, ideally with globally routable IPs like we’re back on the 1990s internet with people plugging their PCs straight into the modem with zero NAT or other considerations.
Skill issue
No, I definitely trust Samsung’s data collection devices to be both secure and not do anything nefarious on a far more complex and harder to secure network setup. Every IoT vendor has shown a level of care and future proofing we should find reassuring if we blindly let their devices route live Internet traffic.
Less tongue-in-cheek I’m somewhat sure that the average store clerk plugging in their IPv6 connected record player won’t have the slightest idea of what hardening that against external threats means. They may also have set up the network. That should be an expected use case by anyone designing network equipment or devices, but I’m betting it won’t be. As I’ve seen equipment sent out with live IPv4 addresses to residential and retail accounts.
It should be up to the router, you have no idea how scared I was when I connected to a friends home wifi and realised I had a publicly routable IPv6 address
Your IPv6 is publicly routable, but unlike IPv4, you can’t just sequentially scan all IPs, even in a /64. Also, modern OSes don’t expose many ports nowadays (and usually don’t have bugs in their IPv6 implementation that allow RCE from a simple packet spam, see https://hackaday.com/2024/08/30/this-week-in-security-the-rest-of-the-ipv6-story-cve-hunting-and-hacking-the-tsa/)
IPv6 is less useful than alternate DNS roots. Same “cult of enlightenment” self-righteous advocacy, without the actual functionality. The protocol of the future specified by those who thought ATM was a good idea but too simple.
Imagine a geographic routing system, where your ICBM address (including elevation) is your network address. “But privacy!” … is no worse than today and forwarding and tunneling would need to be first class considerations.
Are you serious about the geographic routing system or are you mocking IPv6?
Because that sort of system would be so privacy crushing that we’d easily be upping ourselves on the dystopia-o-meter by a bunch of levels.
Ha ha … Remember reading the ATM spec early in my career and remarking “really a 53-byte cell”?
I never cared about ipv6 (just disabled anything ipv6 related in the router) because my ISP did not have ipv6.
Now the ISP does support ipv6, and I see that 60% of traffic flows via ipv6.
Configuring ipv6 was easy after I stopped thinking in ipv4 terms. It is different.
The pain is that you always need to configure both ipv4 and ipv6, and keep things in sync.
I guess that ipv4 will never go away, but ipv6 is here to stay.
IPv6’s pigheaded desire to do away with subnets and NAT as an option really shot it in the foot. I don’t know how the designers didn’t see how annoying that would be. I like that IPv4 addresses are simple to reason about and remember. I like that by default nothing is exposed on the internet and I have to go out of my way to make that happen. Yes NAT/SNAT is painful and limiting. With all the IPv6 space this could have easily been handled via a prefix reserved for this or some other similar approach while still leaving the concept of a private subnet alone. IPv6 stans will just scream “skill issue” and that there are a dozen ways to “do it right” in IPv6, but they can scream all they want. The fact is, that even at large companies, most of them use IPv4 internally. If IPv6 really was a panacea it would have been adopted by the majority of at least the large companies at this point, and it’s just not.
“IPv6’s pigheaded desire to do away with subnets and NAT as an option really shot it in the foot. I don’t know how the designers didn’t see how annoying that would be. I like that IPv4 addresses are simple to reason about and remember. I like that by default nothing is exposed on the internet and I have to go out of my way to make that happen.”
Those are bugs, not features. Those were specific pain points of IPv4 that IPv6 fixes.
With IPv6, you remember names, not numbers. That’s easier than numbers.
What operating system do you use that defaults to no firewall? On Windows, you’ll be in Public zone by default that does what you’re thinking NAT does for you.
It would be better if you educated yourself on IPv6 instead of fighting the benefits.
I don’t know what made up statistics you’re talking about regarding large companies, ALL of them use both IPV4 and IPv6. IPv6 has been the default IP stack in all the major OS’ for a decade or something.
No, with IPv6 you just can’t remember numbers, because there are too many of them for your biological neuron to learn. And it’s a failure in the specification, not the feature, sorry. This and the “shortcut” algorithm to the so many useless 0s in that address. It requires you to learn a “decimal to hexadecimal to RLE encoding to colon encoding” algorithm in your head. In the end, you give up and set up DNS, proof of the failure.
It’s exactly like using a SHA256 in a DHT and saying “what? you don’t remember the hash number directly for your peer address?”
IPv4 is still used because it’s simple enough for us to use, not because it’s superior in features, or because people bless the 4 decimal numbers rules in long night rituals.
And the IPv6 designers miss that point, clearly.
In a network of any considerable size the idea of memorizing addresses is about as useful as memorizing a national phone directory. Automatic address assignment and name service rendered all that obsolete a very long time ago. NAT is a crime and a major performace bottleneck and single point of failure. In a properly designed network, no human has to memorize anything or ever enter an address on an end device. As for the broadcast, that is rendered inoperable by two things, 1. It negates efficient switching where you dont send unneeded traffic to an endpoint. And 2. Every stupid utility and misconfigured device decided the best way to handle things is to announce themselves to the entire network. Yes, the transition to v6 is pretty difficult for large networks already in existance however building a new large network without v6 is a dumb idea. For the home gamer, it actually does not matter since the big carrier networks are handling it for you which is why they are using cgnat. At the lowest end, a home user that connects their PC to their cable modem or satellite is already using V6 without a care in the world. Its the in between user building small networks that has a problme when they try to engineer stuff that is now intended to be automatic. What really slowed v6 deployment in corporate networks was deploying their public facing services to the cloud or hosting providers rendering public addressing irrelevant to the main corporate networks which can hide behind NAT firewalls and proxy services like load balancers.
“In a properly designed network” – this is a unicorn! Not arguing with you, in an ideal world ipv6 would be great. But we’re not in an ideal world. Networks are messy, organically grown and in my experience I’ve yet to see a switch room/server room/datacentre where every closet is tidy (unless every endpoint is wired up at the get-go and you’re left enabling and disabling switch ports hoping one doesnt get enabled by mistake thats connected to something that shouldnt be on the network or you have to do physical audits so regularly you’ve a full time person looking after it).
I’ve seen networks where one segment was set up by one group of people on a contract, contract wasn’t renewed, network was subsequently joined with another in a merger using a different contractor and a different way of doing things. Lease was terminated in one building, started in another, techs scrambled to put it together and the “lead engineer” was just the most senior technician who found ipv4 simpler and made sure that all addresses in that location were on a 172 subnet.
I’ve spent a week troubleshooting network layer issues through various firewalls, NATs and LBs on a single issue only to find it was a proxy or some other issue from an exception rule put in place eons ago (years of my life in total wasted), but the resources involved in a complete redesign just aren’t justifiable to the people who make those decisions. And I’m not the one hiring a webdev/technicians/server admins who’ve never used ipv6 before and insist only setting things up for ipv4 only. I’ve a hard enough time trying to get management to assign staff to cyber, or migrate away from vmware, or update all the MS Server 2016 OSs or whatever else is more pressing than a network redesign.
I do see a change from management in a lot of organisations and while more resources are definitely assigned to ICT in general, for a lot of senior management an ICT person is someone who can fix a printer, wire a switch, fix a phone, create an app, do the thing with the firewall that lets them on that website and not specialists with niche areas of expertise. And you can be sure when I get that honorary doctorate (because I’m too bloody busy learning about and implementing new technologies to get a PhD) I’ll be sure I’m addressed as Dr!
Brother, I work for a major tech company that specifically deals with networks, and IPv6 is the red headed step child. Your brain is too knotted from trying to do gymnastics to justify IPv6 if you think those are bugs. IPv6 is disdained by almost everyone who works in the IT space.
“What operating system do you use that defaults to no firewall? On Windows, you’ll be in Public zone by default that does what you’re thinking NAT does for you.”
In a way, please warmly consider your average user who is maybe sticking with Windows 7 or 10 (shoved in their DMZ) because that’s what they they know and honestly, in today’s economy all they can afford.
We will pull back from that extreme though to a slightly more clever HaD reader.
The CVE landscape is harsh right now. Yes I do agree that many of the zero days – or even long disclosed 10.0 CVEs they are openly exposed by won’t be altered v6 or v4… but… /24 is working for many people, and they grew up and know it.
In dangerous times, being a knowledge-space you are comfortable in is a very valid consideration we shouldn’t discount. We can’t lose sight of the point that networking for most people is hard, real hard. Certified professionals would know from painful experience how a single configuration mistake can bite hard. So, in this discussion I personally apply great weight here;
Dotted quads in a /24 address space are easier to understand for many people. Easier to understand means it’s well inside their capability to control. Is NAT adding a layer of swiss cheese? Not really but it’s comfortable, and that comfort /does/ mean something.
Are /64 easier to impliment? On a new network with no legacy overhead yep. But when legacy is brought into the mix, it can become so much harder. And when things don’t work, I’ve noticed people do tend to drift towards ever more permissive setups until it does work, then stop and leave it.
My 2 bits aint worth much in the grand scheme, but I can see both sides have valid points.
Not sure what you’re suggesting, there’s nothing stopping IPv6 networks to also have NATs and subnets. They aren’t required for the most part though since there are so many addresses that every single device can have its unique address on the planet.
I have an IPv6 capable ISP, and I have configured my router correctly so that every device in my network has a publicly reachable IPv6 address. Of course, only my home server is allowed to reach the interwebs, my router firewall prevents any other device from reaching in.
In the early 2000s, it was simple for a person to self host stuff at home using IPv4 + DMZ (or port forwarding). Then came the CGNATs, completely killing off domestic self hosting world. And now finally IPv6 has arrived to liberate the self hosting world again. Tell me this isn’t great!
“every device in my network has a publicly reachable IPv6 address. Of course, only my home server is allowed to reach the interwebs”
And you don’t consider that remarkably silly?
Not at all, that is what firewalls and routing are for and you can still use private addressing in v6 if that is what you want. If you are only relying on your private addressing for protection you trust you home router more than I would.
You don’t think that maybe there is a security or at least privacy issue with every device in your home network being specifically identifiable?
You don’t think that an ISP being able to link internet traffic with a specific device is an issue?
The IPv6 privacy extensions constantly change your IP addresses. That’s the default configuration for every modern operating system. If you want a fixed address for inbound connections, you have to manually enable that.
Websites will uniquely identify your devices using browser fingerprinting rather than by IP address.
The initial philosophy of IPv6 was really awkward by forcing that on people, but these times are long over. Since quite some time now you can operate IPv6 networks in certain different modes:
Use a public subnet, each client in your network uses its own public IP to send requests
Usually in such a network SLAAC/Prefix Delegation is used, so every host finds its own IP address within that network
But you can also
Have a private subnet in the fd00::/8 range and assign addresses whatever way you find suitable (SLAAC/PD, DHCPv6, static addresses)
Use NAT to access outside resources
just like you do in IPv4. It is your choice, you decide. But as you have 2 options now you have to decide.
The link-local subnet might be a bit confusing at first as it is always set up using SLAAC. So your adapters always have a fe80:: address.
But as in the definition of “link-local” it can’t be used to reach any outside resource as it is never routed by definition. It’s like getting an additional 169.254.0.0 address in IPv4, even with DHCP.
The “problem” here is a historical one.
Historically, there were public data networks running over X.25 protocol
and IP protocol was used in ARPANET and early non-public internet to work over long distance.
And because of Unix being common in academic circles, TCP/IP got an established protocol, too.
Also, on a side note, Europe had favored the existing X.25 of the time but USA, home of ARPANET, had focused on that Frame Relay thingy.
https://en.wikipedia.org/wiki/Frame_Relay#Origin
In non-scientific fields, however, there were other, more efficient protocols for LANs and WANs/intranets.
AppleTalk, IBM PC Network, Lan Manager, IPX/SPX, Vines, LBL, LANtastic..
But then came the 90s and BSD’s TCP/IP stack was made free.
Within a couple of years, all major OSes had a solid TCP/IP stack,
providing interoperability an made heterogenous networks a reality. Simply put.
And that’s probably why the designers or planners of IPv4 and IPv6 are so out of touch with reality.
They missed the LAN/WAN/intranet aspect and focused on the internet solely.
They where thinking on a large, global scale and didn’t care about the needs of villagers (LAN users).
Lets talk about subnets and NAT. IP v6 does not at all eliminate subnets. The /64 is intended to be the smallest GLOBALLY routable subnet to keep the size of intenret backbone routing tables under control. The service provider sends you all traffic bound for your /64. You can subnet down as far as you want within your network. That what corporations are intended to do. Mutlinationals can get a /56 which means they can advertise their /64s regionally and selectively. NAT was a cludge from the beginning to allow a lot of stuff to hide behind a single public address. It was brought about due to the expense of obtaining and managing public address for tons of little customer networks. It added complexity to things like VPNs and created single points of failure where the NAT tables reside. Now that we have ASIC network switching at 100G+ speeds, doing NAT lookups is like crawling to your hypersonic jet. Once you have essentially unlimited address space there is no need for NAT. It also allows the average enterprise to obtain their own assigned address space that they can advertises on any service provider they choose and to take with them when they leave. This is espcially attractive for companies that operate among multiple jurisdication and providers. Any shortcoming of V6 comes down to lack of education, understanding, or trying to replicate V4 baggage in the V6 network. I say all this as a forty year network arrchitect for the government and large emterprise since the days of DDN and MILNET. At the Internet numbering assignment level it fixed a thoroughly broken bureaucracy with a much simpler model which gives anyone who needs one an address space that can never exhaust and can hold forever. No justification really needed if you connect to more than once service provider. One and done service.
If IPv6 fails there is always the IPv8 draft sitting in the wings (expand the IP address space to 64 bits while keeping backward compatibility with IPv4)
Ipv8 fails for one simple problem. Ipv4 is not forwards compatible. So infrastructure needs to be upgraded for it, explicitly what the ipv8 RFC says can be avoided.
If that was the replacement we would have dropped IPv4 long time ago. That IPv8 with 64 bit addresses is far more sensible invention and would be far easier to switch in our limited human brains. ISPs giving 65k IPs (256 blocks of 256) to end users would offer plenty of space and there would be no problem with local separation like it is now with ISPs that give single /64 instead of /56.
Unfortunately they went for an overkill address space and here we are. At the same time, they didn’t think of standardizing any automatic naming system on the routers to translate convoluted strings into human readable format.
I bet IPv6 adoption would far higher if they mandated that router for each final /64 would automatically build and resolve DNS entries in some sort universal TLD like .lan or .local for that network. mDNS is not a solution if you don’t know the hostnames. We need centralized location to see what addresses and names are present in the network. That should be basic IPv6 router functionality.
Ip6neigh for OpenWRT is an example of this. PfSense is also good with a table showing IPs, MACs and hostnames with an option to register DHCP leases in the DNS forwarder.
Unfortunately both are rarely used. Most common home and business routers don’t offer anything like that and no one is willing to fix that.
Probably worth noting that the cellular companies (you know, those service providers with massive needs for address space) are doing rather a lot with IPv6 at this point, so there’s rather more of it out there than you may think.
IPv6 definitely has a place, yes, but it’s tragic that it doesn’t feel like it was designed to be a replacement for IPv4.
64-bit addresses would have made a lot more sense, given that they fit nicely in 64-bit registers.
Trying to address all the atoms in the universe was a fools errand.
While it took a bit of time for me to wrap my head around it, I must say I am starting to enjoy the benefits of ipv6.
Yes, no “comparable” NAT private 10/172/192 subnets as we were taught to think about networks.
BUT width fe80 (link local) and fd (ula) type addresses plus the fact that each card can just have multiple v6 IPs, I can have those type of private network(s) AND public routing at the same time on every device.
For example at home I divide my devices in subnets based on location (1st floor, 2nd, outside) via ULA networks for house-“internal” chatter, each of those has its fe80 for floor specific chatter (if so desired) and everyone has a global routable ip for the world wide chatter
Took a while for all of that to click in my head though
So are you saying that someone could look at your public IP address and know your approximate location in your house?
No, multiple IPs per device.
Your fe80 IP isnt the same as your public IP.
This is different with ipv6 from how ipv4 works
IPv6 subnets can be as large or as small as you want them, they are not limited to /64.
Also IPv6 still supports private subnets with NAT just as IPv4 does. The subnet for this is fd00::/8. Its the 192.168.0.0/16 equivalent, just stupidly large.
So the classic setup of having private IPs behind a NAT router is still possible, I use it every day.
The subnets can be any size, but using anything other than /64 breaks SLAAC.
Yes, SLAAC is the bring-up mechanism for the link-local address, there you need /64 subnets. Even though the original approach of filling the last 64bits with the MAC address has been deemed unsuitable and subsequently has been replaced, so from a technical perspective you don’t need /64 subnets there either.
However SLAAC is only suitable for small networks as mDNS doesn’t scale for larger ones. So there you get the traditional DHCP(v6) and with that you can choose whatever subnet size you want. Sounds like IPv4 and works like IPv4.
just let IPv6 die!!! We have routers invented for infinite IPv4!
I still can’t access IPv6 only addresses via my ISP in 2026….
IPV6 is meant to resolve the ownership problems of WHO owns your data. We are expected to “buy” our devices and pay a perpetual subscription fee for the pleasure of “owning” a content delivery device. IPV6 means we have to relinquish all control to the robot overlords because “they” are better at knowing what we want, “they” own our data, and “we” are the cash machines expected to relinquish all control to someone else and pay for that privilege. IPV4 is a thorn in the side of big business because it gives consumers a choice of what and when we want to share our data.
This…. Makes no sense.
Ipv6 if anything will replace cnat, and maybe allow people if they want to run services from their own internet connection more easily. which would be a big plus to trying to move away from centralized cloud services.
I’m not trying to be overly critical or negative but the article is flat wrong on multiple aspects of IPv6. There are absolutely subnets and NAT in IPv6. And /56 and /40 are already in use regularly too. Inherent security of IPv4 and NAT is not a real advantage because ipv6 has equivalent with ipv6 firewalls and host based firewalls that provide the same connectivity profile surface to both the internet and lan.
NAT is actually the stupid thing – it’s a host not knowing its own Internet address; IPv6 solves the same problems without NAT so you can ask a host it’s address and it actually knows, very useful for things like IPsec in direct transport mode and Kerberos both of which are incompatible with NAT.
Finally the author concludes that they will not be migrating their application from UDP based service delivery to native IPv6. Guess what, UDP works fine over ipv6 also which was thanks to it being a modular layer (network layer) below the transport layer protocols of UDP and TCP. The author doesn’t realize that she’s pointing out exactly the value of the modularity between ip 4 and 6.
I think this article was misinformed.
NAT is actually a clever thing. A host that can do local networking without relying on the ISP to provide anything. Also a host that doesn’t hand out any internal information (ie. its network address) to anyone outside of its network. And no, link local is not a replacement.
UDP in the article was used for broadcast/multicast, so this boils very much down to IPv6 implementation details.
It’ statements like yours that make IPv6 never gain traction. The way IPv4 does networking is perfectly fine. The “new” idea how to do things in IPv6 just doesn’t work well, it lacks proper isolation. Thankfully some people got that and we do have NAT and DHCP for IPv6.
Ip6 has a non-network storm solution to the problem.
You know wasn’t pointed out in the article; why the ip6 solution doesn’t solve the problem.
Being different doesn’t make it bad.
My first experience with ip6 was bad because, NAT isn’t a firewall. Any firewall related benefits you get are accidental.
I thought it was quite well-addressed in the article why I fail to see the point of IPv6 for service discovery on a LAN, namely the pile of complexity it adds for no conceivable gain over just doing an IPv4 broadcast. Once you have IPv4 broadcast working on a LAN, that’s quite literally all you need.
IPv6 can absolutely do service discovery on a LAN, so that’s a red herring. It just isn’t as simple or straighforward or well-supported as just sticking with IPv4. Which has been the theme of IPv6 adoption the past decades, pretty much.
I still remember the “good old” times when IPv4 (or just IP) was simple. You had one subnet, one address, one broadcast.
Over time some of the concepts of IPv6 have been back ported to IP. Adapters can have multiple addresses, with link local 169.254.0.0 there is a valid reason to always have multiple addresses, and nowadays addresses are usually bound to a lifetime by the OS with some concept to renew them behind the scenes.
So modern IPv4 sits somewhere between traditional IP and IPv6. Add Route Advertisement and Prefix Delegation and you are there. From that point of view it isn’t much work to get it done with IPv6, and I’d argue that it is even required to look into it to understand modern IPv4.
PS: I find DHCPv6 is a much cleaner solution than DHCPv4. As you always have a link-local address with IPv6 the communication with the server uses link-local IPs instead of all-broadcasts. Also DHCPv6 doesn’t bother with routes, it only does name resolution.
Link-local acts like a bootstrap-IP-layer to set up the final IP layer, so you can always assume you have working IP.
It’s 2026.
The road might have been a but rougher than would be liked, but yet here we are.
I decided to re-build an IoT I built previously, it’s pretty simple 2 pairs of 7 segment displays running from a Pico W. It was configured to connect to an MQTT server, from which it would receive scores from a live NHL game.
I didn’t love the setup for various reasons. I decided to re-do it and use IPV6 Multicasting instead. (ACK!)
So, as of this afternoon it appears on my IPv6 network, registers itself with mdns, registers a service as “_scoreboard._udp” and identifies its group address as ff15::dead:beef, on port 5000.
I didn’t change the type of information it expects, so at the moment it weirdly expects a packet containing json, pretty simple expected format:
{ “away”: 1, “home”: 2 }
When it receives such a packet it publishes the scores to the appropriate 2 digit 7 segment displays.
macOS cli examples:
% echo ‘{ “away”: 1, “home”: 1 }’ | nc -6 -w 1 -u ‘ff15::dead:beef%en0’ 5000
% dns-sd -B _scoreboard._udp local.
Timestamp A/R Flags if Domain Service Type Instance Name
22:28:50.072 Add 2 14 local. _scoreboard._udp. Scoreboard
% dns-sd -L “Scoreboard” _scoreboard._udp
22:29:45.638 Scoreboard._scoreboard._udp.local. can be reached at pico-scoreboard.local.:5000 (interface 14)
version=1 group=ff15::dead:beef role=display
I disabled IPv4; been working all day, including after Network reboots.
shrug.
“Although it’s still very much a rumor at this point, supposedly IPv6 is slated to replace the venerable IPv4 protocol.”
“Let’s go.” “We can’t.” “Why not?” “We’re waiting for Godot.”
IPv6 has left a bad taste in my mouth for decades. The new IPv8 proposal makes sense on a human level. Let’s go.
The premise of this piece suggests that Broadcast UDP the standard and lots of protocols use it for “service discovery” on a local IPv4 network. I believe this premise is false, possibly invented to support an IPv6 is too complicated argument. The only widely deployed IPv4 Broadcast UDP service discovery protocol is the NetBIOS-over-TCP/IP name service. NetBIOS-over-TCP/IP was already in use before multicast was introduced for IPv4. There really aren’t any other standard IPv4 protocols that use the broadcast address to find responders. It is possible there are lots of non-standard things that abuse broadcasts.
The use of a broadcast IPv4 address requires the upper layers to also use a broadcast address. For most things these days this would be an “ethernet” compatible layer.
Broadcasts are bad. Bad for everyone; for senders because they must pass them on (there is no nuance), they are bad for receivers because they must consume resources and process them, as a receiver do they then have to forward them to their other networks resulting in a broadcast “storm” for multiply connected networks (ethernet bridges, WiFI repeaters)?
The designers of ethernet knew broadcasts were bad in the 1970s. Ethernet has, broadcast, multicast and unicast addresses. Some of the earliest complex ethernet silicon, the Intel 82586, from 1982 has the ability to support multicast addresses.
There are some IPv4 rules for broadcasts that aren’t explicit. Broadcasts don’t get forwarded by a router. On a multiuser system, you have to have system “privilege” to send to a broadcast address, you have to send on an appropriate “interface”. So even if you send to 255.255.255.255 it won’t go to every node on the Internet. Where it might go isn’t really defined by IPv4, but by implementation, configuration and policy. For IPv6, forcing the use of multicast and which addresses to use makes it much clearer where the packets might end up going. End nodes can decide for themselves if they want to see that traffic.
Here are some real world examples of why broadcasts are BAD; (1) a WiFi network with many transmit nodes, with a Broadcast, they all have to transmit the packet, likely all at once, this is a shut-up and everyone must listen state (MIMO off / unusable) – likely causing collisions, interference and multiple retransmits. It also messes with encrypted transmissions – sending it as one packet to everyone requires the existence of a globally shared key so that everyone can decrypt the message – if you don’t have this, then every message has to be sent individually to each node currently listening, using their individual key, swamping bandwidth. When do / can you rotate that global key and how often, if you send unicast back what key do you use? (2) it is bad for listeners because they have to “accept” the packet (likely an interrupt) and pass it up beyond the Ethernet layer for processing, possibly wasting a lot of battery power even if the message was not for them. For slower systems, a lot of broadcasts might mean they do nothing else but process and drop packets not intended for them, consuming all CPU because of the
“network weather”.
Based on the comment from Mark Topham, I now see that Maya created a service discovery protocol using broadcast IPv4; which I missed when I originally read the article. Sorry Maya. I do think that using broadcast for the foundation of the service discovery protocol was a poor choice. Any Next-Gen IP protocol was going to be a problem, whatever the address size.
I think all of the issues raised and some of the objections to IPv6, do suggest that there ought to be a different networking protocol to support lightweight “local” nodes v.s. globally visible nodes, with a; proxy, broker, or pub-sub model (not a bridge!) when a local node needs something from a more global resource. Pretty sure this path would upset the purists and does cause questions about at what scale or depth causes a switch from one to the other. Maybe IPv4 for local, IPv6 for global is the way to do it – but IPv4 can still be pretty taxing for a node will only a small amount (<256KiB) of RAM.
This will likely need to be revisited again if we ever manage to live at any distance from Earth.
I am happy just so long as I have at least one publicly routable ip address. NAT and port forwarding are indeed hacks. But they are very well established hacks that do the job just fine. IPV6 makes my head spin.
Despite that.. I do occasionally check and although my ISP does advertise IPV6 they really only mean that they use it internally in some way I know nothing about. There is no IPV6 on the network layer that us users can access.
At one point I was all excited about the idea of having the ‘latest and greatest’. I wanted to go to those websites where they put the little ‘Congrats, you are on IPV6!’ messages and see the message. So I was going to get a tunnel. But.. then I read about how some content providers (looking angrily at you Netflix) block those because their whole industry likes to be able to over-charge certain regions. I hate that but there isn’t anything I can do about it so.. no tunnel.
But like I said, one publicly routable address and I am good. I forward what I need and for greater access to home I even have a VPN server.
I read here that some people have ISPs who only give them private LAN addresses and keep them behind a NAT. I would be pissed! I don’t ever want that and if IPV6 is necessary to prevent it then bring it on!
I decide to write a Substack post in reply to this article.
https://mtopham.substack.com/p/a-fundamental-misunderstanding?r=3jw7zj&utm_campaign=post-expanded-share&utm_medium=web
I include sample code for Client and Server processes using IPv6 Multicast.