This article hints at what I consider to be the biggest technical drawback to IPv6 for residential use, which is that dynamic prefixes mean your internal LAN IPs are never stable.
The answer to this is usually something like “duh, use DNS”, but how are you going to configure that DNS server if your whole network’s IP address range could change at any time? Yes, multicast DNS is a thing, but it’s not supported in all software (I’m looking at you, OpenBSD, which has no out of the box support for it and I’ve not figured out how to configure it.)
So the real answer is to create a ULA prefix on the side that you generate randomly (or make an easy to remember one because this is residential use, who cares about collisions, it’s a private space) and use that for any use case that involves hardcoded IPs, like DNS server configuration.
But it still feels like a compromise to me. I wish more software was “prefixless”, including DNS server indication and even DNS zone files, such that a lack of prefix means “prepend the prefix you are already communicating on”… Firewall configuration would be simpler, DNS zone files could survive re-prefixing, all sorts of configuration could be made to work this way, but instead you’re left with either a ton of automation to reconfigure things when the prefix changes, a bunch of manual work, or just bite the bullet and use ULA.
Oh, and did I mention that in my particular setup, all my devices would keep trying to communicate on their old addresses even after a new prefix gets assigned and the new RA’s are sent? Meaning they essentially lose all connectivity if you’re using an IPv6-mostly setup like I have? Oh sure, they grab addresses on the new prefix, but they don’t drop the old one until the lifetime expires, which defaults to 4 hours in the environment I’m in (I think the rad daemon in OpenBSD inherits the lifetimes from its upstream router’s lifetimes, which makes the duration Comcast’s fault, but the proper thing to do is rescind the old RA’s when the interface changes addresses, and rad does not do this out of the box for me, or if it does it doesn’t work right.)
Ok rant over. I want to like IPv6 but dynamic prefixes are really the Achilles heel for me.
With ipv6, one ethernet interface is _supposed_ to have multiple addresses. You wouldn't want your lan routing to stop working when your ISP goes down, right? So configure your internal DNS with ULA (which should be stable for each machine for a given prefix, even with SLAAC) and be done with it, much like internal DNS using private addresses in ipv4.
For externally visible servers, do the normal thing, that is, those servers dynamically update global dns, much the same way with ipv4 dyndns.
Another learning curve for ipv6 is that people get frustrated by dynamic prefixes, but it's the nature of residential networks: the ISPs want a stateless solution, so customers get a dynamic prefix. Maintaining the same prefix across power outages needs a stateful solution, so only business plans offer them for an extra fee, much like static ipv4 addresses.
And we've had dyndns for decades now for exactly that use case. Just keep using that.
What's the point of using IPv6 at all on a home network if you use ULA though? If you continued to use an IPv4 setup you were familiar with but allowed your router to talk both or v6 only, wouldn't it be the same?
Is it that you'd still have the globally addressable addresses on NICs with a ULA too, just that's not what you'd use for routing internally? (Not that I'm really sure of the benefit of that residentially either?)
With ULA you generate a random prefix which means it's extremely unlikely there's a collision. So no need for internal NATing or interface disambiguation because a machine is connected to two networks (e.g. via tunnels) that are both using 192.168.0.0/24. Which also means less book-keeping for collision avoidance. Just roll the dice.
> the ISPs want a stateless solution, so customers get a dynamic prefix. Maintaining the same prefix across power outages needs a stateful solution, so only business plans offer them for an extra fee, much like static ipv4 addresses.
I'm surprised based on my experience: in 15 years of residential IPv6 usage I've always had the same IPv6 prefix (for a given ISP contract of course), even for those ISPs that insisted on handing out dynamic IPv4 with no option for a static one plus had no qualms renewing the IP at any moment, not just power down.
> stateful solution
I'm seeing this the other way around: dynamic needs lease tracking while static just needs a permanent record attached to the already present auth mechanism.
My ISP-given IPv6 (/57 for whatever reason) prefix is also stable, however beware that, at least on my OpenWRT based router, the option to release the prefix back to the ISP when the router is shut down is checked by default. I discovered this when I rebooted for a firmware update and when it came back up my network had renumbered itself.
- I think Free had it since forever and a half, although IIRC it was some weird 6rd or something. Freebox v6 (2011) for sure had it, v5 (2006) may had supported it from the start and for sure supported it down the road, I think v4 could have had it too through an update at least but honestly can't recall.
- Orange in France had a public opt-in experiment for native IPv6 over ADSL to which I enrolled at the time.
- Then I lost IPv6 because I moved to a cable operator which did not support DOCSIS 3.0 (a requirement for IPv6 on cable connections) at the time.
- After that FTTH rolled out and basically every ISP provided native IPv6 on it from the get go.
Non-biz IPv6 support in France is sitting in the ballpark of 99% these days, both residential and mobile. National regulations helped a lot. Residentially there has been a huge plan towards a national FTTH rollout, including in remote areas (the idea being that no one should be cast aside of a full speed internet); this plan also had specific requirements to enforce competition to prevent regional or local monopolistic situations such as the one that historically happened with cable operators (or like the ones I keep hearing about in the US). For mobile it was simpler: you want a radio license for 5G? you have to support IPv6, or else.
> Maintaining the same prefix across power outages needs a stateful solution, so only business plans offer them for an extra fee, much like static ipv4 addresses.
Whose power outage?
The ISP needs to reliably track allocations despite some of their equipment going out, except in the extreme edge case of their entire operation cold starting.
If the client modem goes out it can just be told the same number again when it boots.
And that's not even getting into how trivially small this amount of information is to save to disk.
Non-persistent allocation has technical benefits when your devices keep moving between nodes or when they're offline most of the time. Otherwise not so much.
I never heard of ULA before, and it sounded a bit overwhelming at first. But on a Fritz!Box with recent firmware, it's very easy to enable, and voila! - just works.
Yep! ULA should be thought of as the IPv6 equivalent of RFC 1918 space... with the added bonus that -unlike with IPv4- ULA prefixes are very unlikely to collide, so merging internal networks will very rarely require renumbering.
For those with flatter home network needs but still wanting a few things internal to be reachable by IP I'll throw in you can also use static link locals on fe80:: instead of a random ULA prefix. You'll still need the ULA method if you have multiple subnets and want static services reachable via routing though.
Unless the router says the old prefix now has a valid lifetime of 0 the proper thing to do is actually to wait for the prefix to expire like it seems to be doing. I never had this missing lifetime change problem with Comcast but it's very possible they do things differently in different service areas/for different service types.
Link local addresses work the same as IPv6 addresses in the url bar, just make sure you're entering the full link local and not the first portion only. Static IPv6 is horrible to enter in browsers in general because you have to remember to [address] as well. Of course, if you're doing it for statically configured local DNS entries as in above then all of this is moot as you'd just use the name.
My IPv6 address is perfectly stable. It's up to the ISP to decide if they bully you into paying extra for a static network or not, but it's an implementation problem. Same with IPv4 assignment, necessitating hacks like DynDNS.
If you want stable local addressing, announce a ULA on your LAN. Not all routers support it, unfortunately, but you can announce a ULA from any device. Just don't announce your raspberry Pi as an outbound router.
ULAs use SLAAC and will derive at least one IP address from your devices' MAC address. There's a chance of instability if you have devices with the same MAC addresses (there's detection for that problem but you end up with a race condition after a network reboot), but your network will probably break in other ways if you have such a setup.
Your rant doesn't make sense. The solution is already known and you mention it: ULA. It's not a compromise. You don't need to bite the bullet. Just use it. It's designed for this use case. Fixed IP address for every single device.
If I use a global unicast prefix, the IPs I see on my devices are their real honest to goodness routable IP. That is great!
But I can’t use that IP in any configuration because it will change. That’s not so great.
So I have to compromise by not using the routable IP in places where I need to put the address in a config file.
Nobody wants ULA. ULA is a solution for the fact that your prefix will change, which I wish didn’t happen.
You can say it’s unreasonable to expect a stable prefix (and we could argue about that all day) but don’t pretend it wouldn’t be massively beneficial if I could rely on one. It is absolutely a compromise. A necessary one? Yes. A reasonably simple solution to implement? Yes. But it’s still a compromise.
Well as someone else mentioned, do you want your devices to have no address when your internet connection goes down? A global IP is also a compromise unless you have your own ASN.
> don’t pretend it wouldn’t be massively beneficial
Homie likes to pretend to overcomplicate things. Check the comment history, this rant isn't new.
And yeah, folks need to understand that ULA addresses are functionally equivalent to RFC 1918 addresses, and ask themselves why they'd expect an ISP who charges extra for an unchanging globally-routable IPv4 address to give you an unchanging globally-routable IPv6 prefix for free.
id assume those unchanging ipv4 addresses are not shared and natted with other customs and thus charging for them makes sense as you're consuming a limited resource they are paying for.
That's not the same for not changing an ipv6 address
> id assume those unchanging ipv4 addresses are not shared and natted with other customs...
Over the last several decades of me having residential Internet service from a variety of ISPs here in the US, I've never had an IPv4 address that was not globally-accessible. Relatedly, I've never had a guaranteed-static IPv4 address, but I COULD get one if I paid the ISP additional money.
I understand that in other regions of the world NOT being behind CGN is not guaranteed.
> That's not the same for not changing an ipv6 address
Hopefully you now understand the context in which I made my remarks. In the world that I (and many other folks) live in, I get one globally-accessible, but definitely-not-static IPv4 address.
> ...they don’t drop the old one until the lifetime expires...
That's a configuration problem on your end. Your border router needs to notice that it's being instructed to switch delegated prefixes and instruct radvd (or whatever route advertising daemon it's using) to advertise the now-defunct prefixes with a zero lifetime just before or just as you're advertising the new prefixes.
With this information, devices on your LAN that aren't asleep will do the right thing, and devices that were asleep should reconfigure their network interfaces when they wake up... assuming that the world hasn't changed while they've been asleep is something only morons would do (coughAppleComputerscough).
Oh just fuck right off. You’re already following me around from thread to thread calling me names and now you’re saying I’m using “bad software” for using the built-in, recommended router advertisement daemon on the operating system that has historically always been the absolute best in class at IPv6. You’re being argumentative, you won’t admit when you’re wrong, you treat me like an idiot; in short, you’re a fucking troll. Stop posting.
Ah. Apologies. With the benefit of hindsight, I can see how my "Oh, that's sad." comment could be misconstrued.
My intention here was to say that the fact that the 'rad' software fails to advertise prefixes with a zero lifetime is sad. That's like basic, essential functionality and it's always sad when software fails to implement basic, essential functionality.
My intention was NOT to assert that your configuration (or -worse- you, yourself) was sad or whatever.
> ...now you’re saying I’m using “bad software” for using the built-in, recommended router advertisement daemon...
Yes? It's possible for the recommended thing to be bad software. If you haven't discovered this, you DEFINITELY will as time goes on.
Also, apologies for the huge delay in replying. Apparently my comment to you and your comment to me got flagged. I don't read replies while logged in, so I totally missed that this conversation was ongoing.
I wish getting and using an IPv6 subnet was like buying a domain name, and that residential ISPs would be required to use your subnet for your service, a bit like portable phone numbers.
The current IP allocation/usage procedures are a bit beyond most people
A good compromise between this (lots of routing work on the internet) and random prefixes all the time (lots of work on the end user networks) is setting DHCP-PD to do consistent PD assignments. Sure, you're space isn't portable between carriers if you move/have redundant internet but you can also rely on a static address in your assigned range working 3 years from now even if your router is offline for a month. ATT fiber does this. I haven't done a survey of who else.
ULA would let you maintain your internal lan with custom subnets and DNS even if you switch carriers or use multiple carriers. No need to update your internal DNS servers for ULA.
If you're running a server on your dynamic residential service, you must be using dyndns for ipv4. So do the same with ipv6.
Residential random prefixes is the nature of residential networks, as ISPs don't want to preserve state. With a business grade service, you'd get a static prefix, much like static ipv4. Then the only time you need to update anything is when you switch your ISP and need to update global DNS addresses for your servers.
I guess I'll ask here... How do I learn this? I'm comfortable with IPv4, including DHCP, DNS, VPNs, NAT, whatever. I'd like to be able to set up a v6 network[0] in whatever is the Correct and sane way. Is there a good end-to-end tutorial to set it all up by hand and explain what all these things (RA/DHCPv6/fe80::/ULA/etc.) are and how to use them or why not to use them?
[0] Ideally pure v6 if possible; I think there's some way to encapsulate/NAT v4 traffic out from a pure v6 network so I don't actually need dual stack.
For a typical network you usually don't need to do anything. For a geek's network it depends exactly what you're wanting to geek out on. E.g. NAT64 will do what you're looking for at the end (with some caveats depending on what else you're wanting to geek out on) but it's more a carrier focused solution so you don't find as much info about it when reading about consumer tutorials and vice versa.
As for the actual configuration you'll want something specific to your exact network device as learning any of it with a guide for how another device expects the configuration to be entered will be hair pulling.
Static addresses in your carrier assigned public range are actually very similar to static ULA in terms of what happens with multiple carriers. The same is even somewhat true for moving carriers unless you specifically want to talk to that exact /64 again. That said I'd still recommend cleaning them up in such an event as the main advantage of utilizing the public addresses is things like your DNS servers can be exposed to the internet without the need of NAT. To me that's a lot more the "right solution" than making trade offs for fear of re-iping your devices for the times in your life you change carriers.
Multiple carriers has no (consumer level) solution I've found myself happy with. It's anywhere from "hope all your devices handle multiple public prefixes quickly and without errors" to "NAT and deal with the pain you had from v4 again" to "Use some other way to relay or host your static services which need to be externally accessible" to "go back to dealing with trying to automatically update that DNS server entry on and making sure it always stays consistent"
That would make the routing table exponentially larger though, which would become unworkable… That’s why they mostly only do it for networks big enough to need it.
Unfortunately, it seems that support for automatically configuring multiple addresses is quite poor. Linux it can be done with NetworkConfiguration or Netplan: use SLAAC to get a GUA and DHCPv6 for a ULA. NetworkManager also seems to use both by default. Android does not support DHCPv6 at all. I don't know about Windows, iOS, or macOS.
> Unfortunately, it seems that support for automatically configuring multiple addresses is quite poor.
What? SLAAC configures addresses on all -er- not-expired prefixes advertised on the link. So, if the border router advertises a ULA prefix and a globally-routeable prefix, SLAAC assigns two addresses to the computer.
If whatever network-configuration tooling you're using causes your computer to not generate an address for every advertised prefix (and you've not told the tooling to behave in this way) then it's broken.
My only gripe with IPv6 is that clients use an entire /64, I get it's useful for SLAAC, but I wish I could make clients receive a /68 or more with DHCPv6 so that the address space can be subdivided even when you are already behind a /64 prefix.
ISPs do give enough where I am the issue is usually when you are behind 2 firewalls past that or have VMs that you want to DHCP, things like that.
A real world example my ISP provides /56 at the router level but if you put a firewall behind it, that gets a /64 (cannot be changed). Now the firewall cannot further delegate prefixes since it's already used. Some firewalls allow RA pass-through but in my case this wasn't an option so I had to set up NAT66 (non-standard :/) just to get outbound ipv6 connectivity.
Yes, as far as I know, the order of preference is GUA > IPv4 > ULA. Which I guess basically means you either have to tweak the preference on each device in your network or you have to go IPv6-only.
While the article is focused on OpenBSD, implementing DHCPv6 with systemd-networkd is really slick and typically a 1-2 line config for your interfaces:
It's working on my fios connection, but I remember that wasn't always the case. Verizon may have changed something recently or the issue was fixed in a recent systemd release.
That lan config can be re-used on other vlan interfaces too, to take full advantage of the /56 prefix. Just increment the SubnetID (hex only for some reason, so the next is 0x1).
I haven't tried it in about 6 months using whatever version was packaged with Ubuntu 22.04. My configuration was basically the same as yours. systemd-networkd seemed to always be a moving target as far as configuration syntax but mine was mostly the same as yours syntactically and functionally the same.
It is mute now. I deployed a new Ubiquiti network including cameras about 6 months ago resulting in the linux router/firewall being replaced with a Dream Machine Pro.
While I understand that this would not be a situation that's typical for a residential LAN, how does systemd-networkd handle assigning prefixes assigned from multiple DHCPv6-PD assignments?
To make it more concrete, imagine for a moment that one's border router has multiple WAN interfaces, each with its own prefix delegated to it.
I notice that there's an UplinkInterface parameter [0], but if the documentation is not silent on whether or not there's any support at all for delegating multiple prefixes to the same LAN interface, then I missed it.
In IPv6, you can get an address using RA. DHCPv6 only if you want to smuggle some unrelated metadata as options (which, of course, not widely used outside enterprise).
DHCPv6-PD are used only when you need a whole prefix.
If everybody implement all the specs out there, we will have two different DNS record type, 4 or 5 address allocation schemes, a handful of IPv6-over-IPv4 protocol, whole a lots of incomplete and incompatible IPv4-ovr-IPv6 protocol.... Etc... while telling everybody ipv6 is simple and ask why we haven't got there yet
SLAAC is fine, until you somehow get a subnet smaller than /64 on your router, in which case SLAAC completely breaks. I understand why SLAAC has such a limitation, but this is what we get.
It's not optimal, but the upstream network provider does not budge, and now everything except Android devices get IPv6 address via DHCPv6.
Unicast IPv6 addresses are required to have a 64 bit interface identifier and a 64 bit network identifier (e.g. /64), handing out subnets lower than /64 is not spec compliant.
Network operators can do crazy things, but if you color outside the lines things may break.
AFAIK, it's not strictly true that unicast addresses are required to use a /64 network identifier.
It's common, almost necessary even, for environments with dynamic clients to use /64 subnets (precisely so that SLAAC works), but in a static environment it's perfectly fine to use prefixes larger than /64 (e.g. delegate a /80 to each individual host in a datacenter, for virtualization applications etc).
Hence, I'm wondering what the spec is you mention that is broken?
and to your point, yeah you can step outside the spec and things can work in controlled environments, but "there be dragons" when your dealing with interoperability on a large scale (in this case Android expecting /64s per the RFC)
Someone should double check me, but I think PD less than a /64 also just breaks (and probably is against the spec).
A lot of the complaints I have seen in the last decade is from ISPs doing silly things and cutting their teeth on fresh IPv6 deployments. My ISP seems to have their collective ducks in a row now, and it has been rock solid for years.
I actually had a case recently where a misbehaving IPv4 IoT device consumed my entire DHCP pool. IPv6 devices kept chugging along without any problem.
It probably is. I remember that putting a /72 into OpenWRT's `ip6prefix` field actually breaks the whole network stack (including IPv4, the interface no longer has any address assigned to it).
I wonder if that's an artifact of configuration-generation scripts detonating before they ever get around to writing out any configuration, leaving the network interfaces entirely unconfigured.
Out of interest as I have found IPv6 RA to work flawlessly for my home network (alongside legacy IPv4 DHCP), what advantage (if any) is there in deploying DHCPv6 within the home LAN? Or were you meaning to say DHCPv6 is great for certain (enterprise?) use cases?
When I was experimenting with IPv6 on my lan, router advertisements indeed worked great!
But the big loss was that I had no control to reserve a particular IPv6 address for a particular MAC address inside the DHCP server, or assign DNS names automatically, etc. since it's basically 1 way - device receives a RA then configures itself with a random address.
Weird indeed. It's sort of fun to see updates as you still get some random personal lashing out at one member in particular for a feud no one remembers but them, but either way it's like... why this mess we still can't have dhcpv6 on android for enterprise?
This is great! I’ve been using ipv6 on openbsd for a while now, starting with a hurricane electric tunnel years ago then to native v6 on Comcast and now Sonic. Configuring ipv6 PD has not been supported in base this whole time. I recall using wide-dhcp6c years ago and then switching to the dhcpcd in the article. The situation has improved, slowly, but it will be great to have this in the base system
They turned on native IPv6 end of last year, at least in some areas (including Berkeley where I live). You wouldn't know it from their help pages, but there are some post in the forum to that effect.
People who advocate for IPv6 are always like 'ahhhh just plug it in and its ready to go!!!' There's even twitter accounts that shame people for how they approach IPv6. But after doing a crap load of network programming I can tell you its really not simple at all.
- IPv6 has many different address types.
- Depending on the type you want to bind to it needs to be handled different.
- Some types need an interface ID appended to them.
- This is conditional on the type of the OS.
- Windows has no easy way to get the ID programmatically.
- Some address types need additional bind info like the 'scope id.'
- Whether you can reach a specific addr type in a con depend on the addr you bind to.
- IPv6 was designed to have plenty of addresses so that NAT isn't needed. Guess what: IPv6 can still do NAT like NAT6. In which case you won't have any nice global scope addresses to bind to.
Writing good network code depends on being able to list the interfaces on a machine and the addresses that they have. With IPv6 this is desirable since it lets you know if you have any global scope addresses, what your local-scope addresses are, and other kinds. But from what I've seen seen most programming languages fall back to using default routes for everything. This means that the programmer literally can't lookup the addresses and interfaces for their software.
Also lastly: getting a modern router that properly supports IPv6 isn't easy at all. I literally have a cupboard filled with PoS routers that can't do IPv6 properly. Everything that Telstra and Optus tend to give customers; most Dovado routers; GL inet routers (can do NAT6 but who wants that); 'netgear nighthawk' (I found a security vuln in netgears router when testing v6); and so on. People will say 'just slap Open-wrt on something and call it a day.' But these are the kinds of people who will spend 120+ hours reading the open-wrt wiki and learning electronic basics to setup a custom router. What they think is 'easy' doesn't take into account all the time they've already spent learning such niche BS. I have better things to do than (((just waste 1 billion hours with open-wrt and end up with someone that still doesn't work.)))
Your "end-user routers suck ass" comment is totally true. I wish the end-user and SOHO networking gear market wasn't a fucking race to the bottom.
Your other comments simply aren't a substantial concern at end-user sites in the real world.
* The only scopes that end-user sites might care about are global and link-local. I expect that situation is the same at nearly all non-end-user sites. Reading through the RFCs, it looks like the other scopes are ONLY relevant in multicast [0][1]... and even then, anything other than interface-local, link-local, and global looks like it's programmed into the routers and switches of the network, rather than host computers themselves.
* If you have functional IPv6 service at your site, your application software cares as much about the interface's fe80::/10 link-local address as it does about the 169.254.0.0/16 link-local address... that is, not at all. The rule is simple: "If you want to talk globally, use an interface with a global address. If there's no global address, send it to the 'default' router and hope for the best.". It's actually a better situation than in IPv4 where you pretty much never have a globally-connected address.
* Yes, you can do IPv6 NAT. In that case, you're no worse off than in the usual end-user IPv4 deployment. The cool thing about IPv6 is not that NAT doesn't exist, it's that there's far, far more than enough address space to make it so that you don't HAVE to deploy NAT at end-user sites. That doesn't mean that it's impossible for stupid, frightened, currently-ignorant, or revenue-maximizing ISPs to deploy NAT.
scopes are deprecated and link-local is only a thing so that the network can bootstrap itself. if you’re deploying ipv6 all you care about are global and ula, which are scope-less
My GL inet router does native IPv6 just fine, without needing NAT6 or anything. Within its interface you can turn it on as "native" and it all just works.
The answer to this is usually something like “duh, use DNS”, but how are you going to configure that DNS server if your whole network’s IP address range could change at any time? Yes, multicast DNS is a thing, but it’s not supported in all software (I’m looking at you, OpenBSD, which has no out of the box support for it and I’ve not figured out how to configure it.)
So the real answer is to create a ULA prefix on the side that you generate randomly (or make an easy to remember one because this is residential use, who cares about collisions, it’s a private space) and use that for any use case that involves hardcoded IPs, like DNS server configuration.
But it still feels like a compromise to me. I wish more software was “prefixless”, including DNS server indication and even DNS zone files, such that a lack of prefix means “prepend the prefix you are already communicating on”… Firewall configuration would be simpler, DNS zone files could survive re-prefixing, all sorts of configuration could be made to work this way, but instead you’re left with either a ton of automation to reconfigure things when the prefix changes, a bunch of manual work, or just bite the bullet and use ULA.
Oh, and did I mention that in my particular setup, all my devices would keep trying to communicate on their old addresses even after a new prefix gets assigned and the new RA’s are sent? Meaning they essentially lose all connectivity if you’re using an IPv6-mostly setup like I have? Oh sure, they grab addresses on the new prefix, but they don’t drop the old one until the lifetime expires, which defaults to 4 hours in the environment I’m in (I think the rad daemon in OpenBSD inherits the lifetimes from its upstream router’s lifetimes, which makes the duration Comcast’s fault, but the proper thing to do is rescind the old RA’s when the interface changes addresses, and rad does not do this out of the box for me, or if it does it doesn’t work right.)
Ok rant over. I want to like IPv6 but dynamic prefixes are really the Achilles heel for me.