You want a ULA (unique local address) instead of link-local.

Link-local can sometimes mean needing to append the interface name to your address and a bunch of other weirdness. If you pick a ULA prefix and announce it (or assign some statically) everything pretty much just works.

I’ve been using them internally for over a year and it’s been great, they basically feel like RFC 1918 addresses.

+1. Link local is like connecting to a computer by mac address. The only time you’d ever want it is if you for some ungodly reason are worried that all other addressing systems have failed, or to bootstrap said systems.

Can you recommend a good book on the subject? Especially one which includes the transitioning pitfalls. I have been living through it all and can get a little confused as to what is status quo. First I heard that SLAAC was great. Then came DHCPv6 and some complained it was an ill concieved bandaid. Now I was under the impression that link local addresses would make my day easier but not you indicate that ULAs are the way to go.

All of this is made much harder by ISPs actively fighting IPv6 adoption. They have the usual moat babble that users do not request it. But in my case they even blocked /protocol/ 40. This was not documented anywhere. Imagine the layers of support I had to work through. Imagine working with new technology and be sure enough that you have exhausted all other possibilities. So learning practical IPv6 has been an uphill struggle for me. Years ago I had a SixXS tunnel going before major adoption took off. Now I am living in another place and wanted to look at it seriously. SixXS was no more so I went with HE. To my dismay dark corners of the Internet have abused these offerings so I have my tunnel disabled most of the time as it gives too much grief. And I have even worked in operations at a large ISP in the 90s. Adoption is not easy even for the willing.

But the reason? No one here seems to mention it: Money. There are no technical excuses left. But it is surely a nice moat.

Sorry for the rant! A good up to date book recommendation would be appreciated :-)

Thew rant is justified. Link local addresses were cool at first but then people realized they were actually a really bad leak of layer 2 into layer 3 and that you need something truly layer 3 but for private networks and abstracted over link hardware. I’ve just read the RFCs and have first hand experience working with a home router mesh networking product that supports IPv6 and uses link local addresses to bootstrap the management layer.

SLAAC is still the way to go downstream, or upstream when you don’t have an ISP doing prefix delegation with DHCPv6. ISPs just want more downward control probably for money and maybe a tiny bit for legal/abuse/security reasons, so they use dhcpv6. secure neighbor discovery would probably be the non-dhcpv6 solution to having link-layer identity, would be cool if isps gave you slaac+send as an alternative to dhcpv6, but that would require average consumers to understand certificates and pki, so fat chance.

edit:

so there’s address assignment and addresses themselves. slaac and dhcpv6 are assignment mechanisms. global, ula, link-local are types of addresses. so the story isn’t really that people hopped from slaac to dhcpv6 to link-local to ula. it’s that slaac is how you configure ipv6 addresses in high trust environments and dhcpv6 came later when isps needed more control rolling things out. I actually don’t understand what problem dhcpv6 solves other than isps presumably wanting to spend less effort to work v6 into their existing systems than to write new utility that monitors their last mile segments for router solicitations and maps to customers that way. slaac is still the preferred mechanism.

then there’s the link-local to ULA transition . really it’s the site-local to ula transition. site local was the indended way to have a private network but had problems. so ot was deptecated. i think maybe before there was a ULA alternative, for link-local made sense in the scene for a hot minute, but now ULAs are here amd they are designed specifically for private site-wide addressing. so thats what is preferred for that.

slaac+ula for private home stuff

nat and dhcp are bad relics

whatever your isp supports/required to get a global prefix delegation. fun fact, you’re supposed to be handed a /48 by your isp so you can have the freedom of 65k subnets but few are so generous.

You'll also need a router that's not stuck in the 90's.

I never got IPv6 working well until I switched from pfSense to OpenWRT, due to my residential ISP switching prefixes very frequently.

For example, there was no way to get pfSense to not publish the public address of the router as the internal DNS, so every time the prefix changed internet effectively broke.

By the way, you can use a separate Linux box (if you have any) to announce your ULA and DNS using radvd. Just remember to set AdvDefaultLifetime to 0 or else your devices will attempt to route their packets to the Linux box.

It was what I did when I had a router that announced only public IPv6 prefixes to the LAN.

Why would things be faster over v6?

On networks using NAT64 (and maybe also for DS-Lite, although I'm not so sure there), the IPv6 path is more direct than the IPv4 one since it doesn't need to go through a CG-NAT, which might be at capacity (tracking every TCP connection requires memory) or located farther away than the nearest IPv6 egress router, making routing more indirect.

I believe all three large US mobile carriers use NAT64 at this point exclusively, and CG-NAT is quite common in DOCSIS cable networks.

I am stuck in DS-Lite, and indeed IPv6 is direct while v4 is served via shitty CGNAT

Simpler routing because address blocks are not fragmented. IPv6 does not have a header checksum so that's one less task for routers. Packet fragmentation is no longer done by routers. IPv6 capable gear tends to be newer and higher performance. There's no NAT step or even worse CGNAT.

For those that were wondering: Unlike in IPv4, IPv6 routers never fragment IPv6 packets. Packets exceeding the size of the maximum transmission unit (MTU) of the destination link are dropped and this condition is signaled by a Packet too big ICMPv6 message to the originating node, similarly to the IPv4 method when the Don't Fragment bit is set.

> Packet fragmentation is no longer done by routers.

The overwelming majority of IPv4 packets have the DF bit set. A large number of services drop inbound fragments anyway (if you get more than a couple a minute, it's almost certainly abuse).

> By reducing header complexity, IPv6 contributes to better overall network performance and efficiency. This is especially noticeable in applications sensitive to latency, such as real-time communication and online gaming.

https://www.prefixbroker.com/news/is-ipv6-faster-than-ipv4-a....

This is the theoretical benefit. These have never materialize in real life.

See https://community.cisco.com/kxiwq67737/attachments/kxiwq6773...

Sometimes networks will route IPv6 traffic over different paths compared to IPv4 although that could actually be either an improvement or an regression depending on which gets the better path.

IPv6 was a lot more than a numbering scheme, there are performance (and security?) improvements in a number of aspects of IP networking, like more compression in parts of the messages IIRC.

Gonna have to disagree with that. IPv6 was designed in the 90s and lots of it feels like it is. Icmpv6 is fundamental to the implementation and already responsible for multiple remotely exploitable vulnerabilities. Couple that with almost no one understanding it well besides a true handful of engineers and you have yourself a security nightmare. Proof of this is this very thread with the talk about “trying a local link address”.

Everything about v6 is over engineered with sharp edges.

A possible explanation is the service provider routes IPv4 over their old routers but routes IPv6 over their new routers.

> Can you explain this more? Why are you so tied to ipv4?

For me, IPv4 doesn't break the privacy barrier, IPv6 blasts a huge hole straight into each and every household, office and IoT device on the planet. No, privacy fixes put into IPv6 do not work.

Can you explain this more? I realize that one IP address per device poses a major problem for privacy, but I thought we somewhat mitigated that by dynamically reassigning IPs.

What exactly is the problem with the privacy fixes that were put into IPv6? Why don't they work?

I'm guessing that the GP is talking about the fact that if there were two persons in a household using the Internet at the same time, with IPv4 they would connect from the same IP address (though of course with different port numbers), but with IPv6 they would likely connect from distinct IP addresses, and usually only sharing a /64 prefix.

You are correct that this isn't a big issue. SLAAC addresses are generally changed fairly frequently by the OS.

IPv6 privacy extensions are only switched around once a day or so in most default configurations.

You can change that, of course, and switch addresses every minute if you want to, but I do find the default a little high.

Once a day is still way more frequent than most routers switch IPv4 addresses, so I'm not sure that the net result is any worse.

The difference is that the average household shares multiple devices behind that single IP address, whereas IPv6 addresses are unique to the device you're using.

Identification to the level of IPv4 can still be done with IPv6 by using the /64 where you would previously take the /32, but with IPv6 you also get identifiers from within the network as well.

With how much IPv6 space is available, I'm not sure why SLAAC-based networks don't just assign different IP addresses to different use cases. I can see this becoming a problem on large company networks, but in home networks you could generate a random IPv6 address every hour for every website you visit and still never run out of address space.

Operating systems aren't exactly geared up for per-application outgoing IP addresses, and perhaps handling tens of thousands of IP addresses will bog down the kernel somehow, but in terms of privacy protection we could be doing a lot more than what IPv6 Privacy Extensions are doing right now.

You're not completely wrong, but that ship has sailed a long time ago: https://amiunique.org

Until browser fingerprinting is addressed, there will be no real privacy.

I turned it off on my home network. I have a multi-wan setup (fiber + 5g). The 5g provider supports v6, but only delegates a /64. The fiber provider will delegate me a /56, which is plenty for both my home and guest networks. Failover for v4 works great, as everything's behind NAT so the route just changes when my firewall detects an issue, but clients accessing v6 resources have a hard time, as you're waiting on each device to figure out that the old route is dead. So that's problem number one.

Problem number two is that the fiber provider doesn't support native v6; it's actually a 6rd tunnel. Latency isn't great compared to v4.

I need to go figure out the ULA situation and do NPTv6. But last I checked, my firewall wasn't able to do NPTv6 with delegated ranges. That may have changed, but I've not found any substantial reason to actually put in the effort to figure out it when my v4 network works fine.