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?)
> 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.
> 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.
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.
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.
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.
> ...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).
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.
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.
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).
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.
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.
Readit News
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.
This is the proper ipv6 solution.
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.
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?)
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.
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.
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.
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.
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.
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.
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).
I’ll let you guess what daemon is deprecated, and what daemon is the new one you’re supposed to use in OpenBSD.
https://undeadly.org/cgi?action=article;sid=20180724072205
The current IP allocation/usage procedures are a bit beyond most people
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.
I get an /56 by my ISP and have 6 or so different /64 in my residence.
Upstream:
Downstream:My config looks like this with systemd 255:
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).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.
[0] <https://man.archlinux.org/man/systemd.network.5#%5BDHCPPREFI...>
Dead Comment
So, some interesting history for the not-network-engineers out there on ipv6 fun. https://issuetracker.google.com/issues/36949085
Why do people hate ipv6? Google comes to mind as one place to start.
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
It's not optimal, but the upstream network provider does not budge, and now everything except Android devices get IPv6 address via DHCPv6.
If only RA wasn't mandatory part of IPv6, I am all for DHCPv6.
It's the fault of early IPv6 designers with NIH syndrome created this mess.
*EDIT*: dhcp6leased landed in base yesterday: https://www.undeadly.org/cgi?action=article;sid=202406040850...
Dead Comment
- 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.)))
'IPv6 is easy. It just works.'
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.
[0] <https://www.rfc-editor.org/rfc/rfc4291#section-2.7>
[1] <https://www.rfc-editor.org/rfc/rfc7346#section-2>
Deleted Comment
Deleted Comment