UDP Broadcasting and the Brave New World of IPv6

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.

Multicast address structure of IPv6. There’s a broadcast in here somewhere. (Credit: Michel Bakni, Wikimedia)

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 2⁶⁴ 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.

The timeline of IPv6 RFCs up till its Internet Standard level. (Credit: Michel Bakni, Wikimedia)

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

NPTv6 Translator interconnects two network links, one of which is an “internal” network, and one of which is an “external” network. (Credit: EidenNor, Wikimedia)

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.