Do you actually own that /48? The problem with using the globally routable addresses internally is that your public /48 might change in the future, and and that will force you to change a bunch of internal stuff.
I have my router set up to advertise two /64 prefixes on each LAN subnet: one from fddd:deca:fbad::/56* that I use for all internal communication, and one from 2001:5a8:xxxx:xxxx::/56 that is only used for talking to the internet. Every device I've ever tested supports this configuration flawlessly, including linux/apple/windows laptops, apple/android mobile devices, an IoT vacuum, and a 10+ year old VoIP phone.
My router is a Linux PC, so I can configure radvd however I want (no GUI, I just edit the configs over SSH). Maybe home routers won't let you do this.
* You're really supposed to pick a random prefix in fd00::/8, but uniqueness only matters if you intend to merge networks with somebody else later, I care more about it being easy to remember.
Ideally it'll be standard that your DHCP will assign you both an internet IP from your ISP-provided prefix (dynamic or static), and private IP from a ULA prefix, which can be made static through address reservation.
Don't use DCHPv6 at home. I tried: you will hate your life, lots of stuff doesn't support it. Android specifically has zero support for it, google says it never will.
I haven't yet found a way to specify a local NTP server though, which is a drag. So everything not manually configured (like the voip phone) talks to the local NTP over ipv4.
Sure. And how does that internal DNS server know about your devices? I connect laptop1 and laptop2 to my network. With DHCP, they each told eg. dnsmasq their name when they connected so laptop1.mydomain.internal and laptop2.mydomain.internal both resolve to the IPs that were handed out to each device. With RDNSS+DNSSL I can tell them that they should look up records on my internal domain and against my internal DNS server, but I can't see a good way for that DNS server to know that they exist or what their hostnames are.
Oh I see. You're supposed to use mdns, but I haven't actually done that yet, it's sort of the last thing on my list.
Mine is all static. I run a bind9 forwarder for DNS, and KEA for dhcp4. I have a little list of machines/macs/addresses as the source of truth, and a pair of python scripts that generates kea-dhcp4.conf and a bind9 zone file from that table.
When I enabled IPv6, I just put all the SLACC addresses in that table, and made the python script generate AAAA records too. But this is honestly really stupid, I need to actually use mdns...
I thought about writing a little systemd oneshot that used rfc2136 dyndns updates for home. But it feels like reinventing the wheel a bit...
> Er, isn't that just manual static assignment, then? Not SLAAC?
Haha no, much dumber than that: I boot the machine, get the permanent SLAAC address it comes up with, put that in the static table, and re-run the script to generate the zone files. The downside is the address changes if you reinstall the OS, but I do that so rarely it honestly hasn't been a problem (and you can force the older MAC-based address generation if you want it to be stable). I wouldn't recommend this setup though...
I do also have some static addresses, like that DNS server address.
LLOL, okay yes that is. Er. An unusual setup:D As the guy who usually says "if it works"... I'm surprised that works. But only because I thought SLAAC addresses changed at least per-boot. But since that clearly isn't the case: Well, if it works...
P.S. thanks for the funniest HN comment I've read in a while
Nothing is stopping your router which does RA to also work in tandem with an internal dns server that can do hostnames for you mapped to slaac addresses.
I'm not sure I follow? AIUI, RA lets you tell hosts about a DNS server, and an internal DNS server could have AAAA records pointing at SLAAC addresses, but how would it know what hostnames go to those addresses?
I'm pretty sure that you can use both. RAs even have bits to indicate if one is supposed to autoconfigure, [0] hit up a DHCPv6 server for some or all configuration, [1] or both. radvd refers to them as AdvAutonomous and AdvOtherConfigFlag/AdvManagedFlag, respectively.
This is exactly what I do. Almost everything has a nice DHCPv6 address so that I can actually remember the ULA + the suffix, but then for the two devices on my network that don't do DHCPv6 they get a SLAAC. One oddity though is that it means most devices on my network have both a SLAAC and a DHCP-provided one, since I wasn't able to be able to get it to prioritize a DHCP. Combine that with them having both ULA addresses and public addresses and some stuff on my network have way more addresses than you'd expect
You can use both, but I've never found a good reason to at home. The DHCPv6 option for specifying an NTP server might be a good reason to... but even Linux machines ignored it when I tried. Maybe in five years :)
In my experience the ISP generally fixes a /64 for each customer. So if in the future you change your ISP, you might want to keep the remaining addresses same while just using a script to replace the preceding /64 address.
My ISPs change the /64 more often. So I use the ULA a lot more often. My router runs its own DNS server and then it advertises this DNS server using a ULA address.
I've never heard of an end user ISP that would announce and route a customer owned block of addresses. They'll all give you a static allocation, but it will be in their block. Maybe if you were a huge customer they could do it... but I can't believe they would go to that much trouble for the measly <$100/month they get from me.
Also, I very much don't want all my outbound internet traffic to come from a permanent address range I am publicly known to own. I'd still want an ephemeral /56 for outbound traffic that changed from time to time.
Typically it's similar to ipv4, they try to assign the same address/prefix for the same MAC/DUID. The most common reason to lose your addresses is replacing your router. Hopefully new routers allow you to set the dhcpv6 DUID somehow...
I haven't experienced this. For me it's statically assigned but my guess is that the PON serial and/or MAC is being used or the customer ID. I think the ISPs have gotten very automated these days and everything seems to be some sort of SDN. It saves lot of labour hours in troubleshooting like customer forgetting their wifi passwords to their routers.
Interesting. Honestly I like having control over it, that would annoy me. I deliberately change the DUID in dhcpcd to force my public addresses to change every so often.
So I decided to use Free Range Cloud service provider to lease a /48, which cost me around C$10/year. I also used their tunnel service to then route this over to me.
The link embedded in the pull quote is [0], which isn't maximally helpful, but it's useful. Approximately 60 seconds of poking around there brings us to [1], which quotes a "ARIN - /48 IPv6 lease ... Use on our network or yours" for $8/year with a $2 setup fee. That sounds a lot like what's mentioned in TFA.
> * You're really supposed to pick a random prefix in fd00::/8, but uniqueness only matters if you intend to merge networks with somebody else later, I care more about it being easy to remember.
If you don't care about collision resistance, why didn't you pick fd00:: ? That's way easier to remember than that jumble of letters you selected. It's actually my go-to subnet when someone claims that local-only IPv6 addresses are "hard to remember". fd00::1 is notably shorter than 10.0.0.1.
I find it much simpler for troubleshooting etc to have simple IPv4 addresses. But cool that it can be done :)
I've switched off IPv6 on my router anyway, I haven't yet needed it. My provider didn't offer it last time I checked but when they do enable it I don't want it suddenly popping up against an untested router configuration.
NAT in general where if you need/want peer-to-peer (P2P) you're suddenly in the realm of STUN/TURN/ICE infrastructure. Depending on your ISP, there's also CG-NAT, in which case (double) hole punching is basically impossible.
If you're 'just' a user, then that may have been dealt with the for you by whatever app/service you're using (e.g., video game companies), but if you're the one having to push out the good/service, it's an entire layer of complexity that has to be dealt with.
I don't know your background, but I find that the people who feel that there's nothing wrong with IPv4 have never done any work with UPNP or NAT. For them it's always "just worked" and they don't recognise what pain has gone into trying to keep it working well despite our usage of it bordering abusive.
NAT is the devil.
If anyone replies to this with the myth that NAT is a security mechanism I will firmly, yet politely, point them to a network development course because they don't know what they're talking about and I'm sick of hearing it. It's not true, I will not entertain this falsehood anymore.
I dunno, I've manually set up NAT (down to the sysctls and iptables) and it's... fine. There's a small learning curve, but it's small. You should of course run a firewall which NAT is not; that's also simple and just basic hygiene.
Well yes, a stateful NAT is stateful. But as that article notes:
> For most workloads, there’s plenty of headroom in the table and this will never be an issue.
And yes, if you're doing thousands of connections per second then you should evaluate things more carefully for performance, but again... That's rather a lot.
Connection table of a single IP is as high (by default) as 16,383[0].
I've hit this limit personally, and due to limitations in stateful firewalling we had to move to stateless filters inside our network equipment instead.
It's interesting that I agree with the article that you linked?
I'm not contesting that it's completely possible to hit the limits in play, but 16k connections (per IP) is high enough that I don't think that's a common problem, even in public-facing web services. Granted, I suspect the services I've run professionally all dealt with it by making it the problem of a load balancer in front of the application and internal network, but... you probably have that anyways, so I'm still not seeing the problem.
it’s interesting because I think youve internalised the constraint and built mechanisms around it rather than engaging directly with it, subconsciously.
I'm not sure why that would be interesting either, but no, it's not a constraint I've ever hit so I doubt that I'd bother avoiding it, subconsciously or otherwise.
I do work with NAT, but the stuff I use does hole-punching pretty transparently. I run 2 VPSes to facilitate this. I don't use UPNP, I have it explicitly disabled everywhere (too much malware that tries to leverage it)
And yes I know that NAT has the same effect as a "deny all inbound" on IPv6. Which is something I would set there too if I did use IPv6 so I'd still have to do hole-punching anyway.
For my own networks I use the private range internally (fd00::/8). That way the addresses remain the same when we move or change the pipe to a bigger one. Also, they can be routed, just not on the Internet. It's easy to join remote networks over wireguard and there's plenty of room for experimentation.
I suspect I am going to be running dual stack for at least the next decade, IPv4 switch off feels very far away. I don't think there is much advantage or disadvantage to running IPv4 compared to translation. The current internet doesn't feel ready. I have had less issues with IPv6 this year compared to last so there has been some progress but I am still getting fallbacks to IPv4, some companies don't seem to care much about IPv6 outages currently.
I never understood the rationale of giving out /64 and /48 like candy after what happened with ipv4. I know it's still a massive increase in capacity and I know it makes the networking easier but it seems like we went from something that definitely won't run out (ipv6 addresses) to something that probably won't (number of /48 ranges)
I can think of at least two reasons why this isn't worth worrying about.
One is quantitative: you have to remember that 2^48 is a much much bigger number than 2^32. With 2^32 IPv4 addresses, you have about 0.5 addresses per human being on the planet, so right away you can tell that stringent allocation policies will be needed. On the other hand, with 2^48 /48 ranges, there are about 8,000 ranges per human being.
So even if you hand a few /48s out free to literally everyone who asks, the vast majority will still be unallocated. A /48 is only about 0.01% of what could be said to be a "fair" allocation. (And yet, a /48 is so huge in absolute terms that even the vast majority of organizations would never need more than one of them, let alone individuals.)
The other is that unlike, say, the crude oil we pump out of the ground, IP address ranges are a renewable resource. If you hand out a free /48 to every person at birth, then long before you start running out of ranges, people will start dying and you can just reclaim the addresses they were using.
/48s are "small" enough that we could give ~8 billion people each 35,000 of them and we'd still have ~1.5 trillion (over 300x the size of the ipv4 space) left over. Addresses are basically infinite, but routing table entries (which fragmentation necessitates) have a cost.
In IPv6 the smallest 'subnet' is /64 if I recall correctly.
It's weird having a subnet size equal to a complete IPv4 Internet worth of IPv6 Internets but I believe the rationale was that you would never in practise run of out IPs in your subnet. A lot of Enterprise IPv4 headaches are managing subnets that are not correctly sized (organic growth, etc.). IPv6 is always routable for the same reason (companies reusing RFC1918 making connecting networks a pain).
There are different headaches with IPv6 - such as re-IPing devices if they move subnet - i.e. move physical location, or during a failover etc.
I'm not sure what the best practise there is as many enterprises don't use IPv6 internally. In my experience anyway.
The big issue I see is every enterprise has a solid numbering plan for RFC1918 networks. Unfortunately, many of them have the SAME plan, and when peering networking between SaaS vendors and customers was more popular (now, of course, privatelink seems to be the move) we constantly ran into conflicts. There's still the risk of conflict with IPv6, but I think if numbering decisions are made thoughtfully, they can be avoided.
There's no risk at all if you're using your own allocated prefix, because those are managed by IANA/RIRs/LIRs to not overlap.
Incidentally, if you find yourself experiencing an RFC1918 clash, one simple way of fixing it is to use NAT64 to map the remote side's RFC1918 into a /96 from your v6 allocation. You can write the last 32 bits of a v6 address in v4 format, so this leads to addresses like 2001:db8:abc:6401::192.168.0.10 and 2001:db8:abc:6402::192.168.0.10, which don't overlap from your perspective.
(If you wanted something simpler to type you could put them at e.g. fd01::192.168.0.10... but then you do start running the risk of collisions with other people who also thought they could just use a simple ULA prefix.)
Yes. I wish they had simply used a more sane address length instead, and maybe given everyone 65535 addresses at most. More than enough for the craziest home lab ever.
Really, just adding 2 bytes to IPv4 would have fixed everything and made it a lot simpler to move over. IPv6 is overkill and I think that really hurt its adoption. I remember being at uni and being told "this is the next big thing". In 1993. And it's not even a big thing now. Not on the user side anyway, I can still access everything from IPv4.
Adding two bytes would have been just as much work as adding 12 bytes, and would have left us with too few addresses rather than too many. The MAC address space is now 64 bits and L3 is necessarily less dense than L2, so 128 bits is the smallest power of 2 where we can be reasonably sure we won't end up with too few addresses.
Considering how hard deploying a new L3 protocol is, we're only going to get one shot at it so it's a lot better to end up with too many addresses rather than too few.
Ehm but IPv6 packets still have the L2 layer as well right? Which already includes the MAC address. So that 64 address MAC space is doubled, it's not like you're saving any. It was a pretty arbitrary decision to accommodate the MAC address inside the IPv6 address and these days it's usually randomised anyway for privacy purposes, so the MAC part of an IPv6 packet doesn't have to be the size of the MAC address.
L3 has nothing to do with MAC addresses anyway so I've always found that a pretty weird decision anyway. Sure, it avoids having to implement ARP but we need that again now anyway with the randomisation. And ARP is like a one-time in a few minutes kinda thing anyway.
I'm pretty sure that if we'd just gone for "a couple bytes extra" we'd have long been completely over. It's the whole L3 transition itself that suffers from the complexity. I remember it well in the 2000s, nobody in telecoms wanted to touch it. And when IPv6 was invented in '93 or so, the installed base was extremely small. It'd have been a piece of cake to get it over with then.
If we actually get to the point of address shortages,
Either, NATv6 would become a thing, or instead I hope SLAAC would get deprecated and dhcpv6 would become mandatory so we could give out smaller than /64s
2^64 is 18,446,744,073,709,551,616. That's 18 quintillion. 10^19. There are ~10^10 people on the planet. Each person could have a 10^9 networks (not even devices) before we ran out of /64s.
> able to run ~340 undecillion devices on my home network
You now can have these devices connected to network called Internet.
Unlike IPv4 were the number of devices on the Internet in home network is one (the main router) or zero (in case if CGNAT) and the others just pretend.
Where I live, the benefit of IPv6 is it's a lot faster than IPv4. All of IPv4 goes through various centralized tunnels and CG-NAT which adds bottlenecks and latency.
IPv4 pricing isn't a good enough reason? If all of my devices had nice ipv6 connectivity I could ditch the public ipv4 addresses, but I have to keep them so that my ipv4-only devices can still reach them.
For home use biggest advantage is that it avoids NAT, which breaks end to end connectivity. Lot of services use hacks to try to mitigate broken connectivity.
Public IPs are a huge benefit and are enough to justify the switch. And there really aren't any headaches in this day and age with IPv6. Once you set it up it works just fine.
Even without CGNAT you'll only get one IPv4 address forcing a absurd amount of workarounds to be usable, that are mostly hidden in firmwares but sill there.
Until the place you're VPNing to happens to use the same RFC1918 network address as your LAN (that is, your LAN is 192.168.10.x and the network on the other side of your work's VPN is also 192.168.10.x). Or either of them use the same RFC1918 network address libvirt is using for its virtual network. Or you want to route between several LANs (for instance, after a company merger) and some of them (but not all) were using the same RFC1918 network addresses.
All of this is avoided by using public addresses for LANs, but address scarcity makes that hard with IPv4 (unless it's a legacy LAN from the 1900s which happens to still use public addresses form the pre-NAT era).
Don't confuse "simple and good" with "flawless" :-)
There are indeed only a few private-reserved IPv4 ranges, and almost everyone prefers to keep things memorable and easy to type; you get a lot of 10.0.0.0/24, 192.168.0.0/24, 192.168.1.0/24 as a result. That, and common household routers tend to default to one of these three /24 subnets. (Hardly anyone seems to remember that 172.16.0.0/12 exists, feel free to use that if it happens to work for you.)
IPv6 does solve this issue in a few major ways, one of which is the greater expectation to rely on globally routable addresses, of which every one of your devices will have at least one such address. There's also fc00::/7 which is fairly equivalent to the IPv4 private ranges, though to avoid conflicts in random VPNs you should generate a random /64 prefix inside of this, otherwise you run the risk of everyone picking fc00::/64 because it's easy to remember/type (I'm guilty of this myself, but the VPNs I've configured just go into a random 172.16.0.0/12 subnet and no v6 assigned. I have the liberty that I currently don't need/use any VPNs that I haven't personally configured, and that may not hold true in the future.)
Huh, I have matter devices working here and IPv6 is off on my router and DHCP. And on home assistant too which does the matter router. Does it use link local or something?
That depends very much on your ISP. Mine (Comcast) does give out a stable prefix. It's not guaranteed to be static forever, but in practice it never changes unless I release it from my router or on the rare occasion they replace their network hardware.
I attempted a similar effort, and found my router had critical ipv6 vulnerabilities including binding the admin and SSH to the WAN on ipv6 (not on ipv4) , and disabling IPv6 firewall altogether so the LAN services were exposed to the internet.
I had the vendor publish their GPL drop, and their upstream vendor did not even have IPv6 support in the product ( the firmware init scripts & admin UI) . So the IPv6 support in the finished product was a rushed copy-paste of IPv4 setup.
I encourage full black box testing of your IPv6 setup, as IPv6 is not in the critical path for QA or consumers, so vulns can persist for years.
I messed with this at one point and gave up when I realized every device would have a permanent externally addressable IP within a block that is basically linked to me (good luck trying to change your IPv6 /48 every month or whatever you get with consumer IP addresses)
It’s probably not a big deal and NAT etc. is no protection but it gave me the heebie jeebies.
Bad generalization. I'm sure policy about this differs a lot, but my consumer ISP definitely reassigns my home's v4 address periodically. I don't track it closely, but it seems that when my ONT power cycles more often than not it pulls a new v4 address.
Now, basing my privacy/security on this would be bad, but to GP's point, if I was using a static v6 block, not only would this address never change, each device in my LAN would have an extra identifier attached to it. External hosts wouldn't merely be able to identify "my house", but traffic from "my phone", "my kid's switch", and "my spouse's phone" would all have distinct addresses.
Of course, my ISP doesn't do v6 at all, so there's no dilemma :')
That's why I specified if one was using a static v6 network. There are several reasons why this might not be true, from ipv6 CGNAT like what cell providers do, to ISP rotation, to randomization in your own network, to NATing from the private network if you wanted.
But it does seem like it would be far more likely de facto for an ISP to not randomly rotate v6 networks, except maybe to discourage hosting on consumer connections?
> using a static v6 block, not only would this address never change, each device in my LAN would have an extra identifier attached to it.
This is not true.
IPv6 stack allocates at least 3 addresses:
- Link-local
- "Permanent" Address derived from the subnet and MAC
- Temporary address that changes several times per day
The default address for new connections is always the temporary address. So IP-based tracking from outside your network will be no better than it was before from one day to the next—the /64 will be the only constant here, just as your router's WAN IPv4 is for v4 connections.
Ah, handy! Though it can't always be true, at least for manual configuration ;-) I have two VPSes with v6 addresses (the others don't have it configured...), and both only have LL and their permanent Internet addresses.
My understanding is v6 has two different autoconf schemes, DHCPv6 and a more "native" solution. Do these both always result in interfaces having multiple (routable) addresses?
Most of my IPv6 experience has been setting it up on aforementioned VPS, and being rewarded with slow OS updates, since NetBSD's default CDN, Fastly, blackholes PMTUD, so I had to drop the MTU on the interface just to get v6 TCP connections to work at all[0]. And for point-to-point networking in an overlay VPN, where I just discovered that Chromium has an 11-year outstanding "bug" where it refuses to perform AAAA lookups if you don't have public IPv6 routing.
[0] I could switch mirrors, but the bandwidth drop isn't quite bad enough for me to bother...
If you had v6, they'd probably also reassign your IPv6 prefix delegation, too.
Also, v6 supports "privacy extensions", essentially randomizing the host portion of the address and periodically rotating it, so it is not accurate to say your address would never change.
> This is where DHCPv4 Option 108 comes into the picture. This simply tells the client that IPv6 only mode is preferred. Clients that do not honor this will get a IPv4 address as normal. Those who do have an option can setup 464XLAT to handle IPv4 literals and disable IPv4 addresses.
Do you actually own that /48? The problem with using the globally routable addresses internally is that your public /48 might change in the future, and and that will force you to change a bunch of internal stuff.
I have my router set up to advertise two /64 prefixes on each LAN subnet: one from fddd:deca:fbad::/56* that I use for all internal communication, and one from 2001:5a8:xxxx:xxxx::/56 that is only used for talking to the internet. Every device I've ever tested supports this configuration flawlessly, including linux/apple/windows laptops, apple/android mobile devices, an IoT vacuum, and a 10+ year old VoIP phone.
My router is a Linux PC, so I can configure radvd however I want (no GUI, I just edit the configs over SSH). Maybe home routers won't let you do this.
* You're really supposed to pick a random prefix in fd00::/8, but uniqueness only matters if you intend to merge networks with somebody else later, I care more about it being easy to remember.
Ideally it'll be standard that your DHCP will assign you both an internet IP from your ISP-provided prefix (dynamic or static), and private IP from a ULA prefix, which can be made static through address reservation.
Don't use DCHPv6 at home. I tried: you will hate your life, lots of stuff doesn't support it. Android specifically has zero support for it, google says it never will.
Use SLAAC. It just works.
How do you handle internal DNS? I'd really like `curl http://mylaptop.internal` (or so) to work; that's easy with DHCP.
You can specify the DNS server in the router advertisements. This is how you do it in radvd.conf:
I haven't yet found a way to specify a local NTP server though, which is a drag. So everything not manually configured (like the voip phone) talks to the local NTP over ipv4.Sure. And how does that internal DNS server know about your devices? I connect laptop1 and laptop2 to my network. With DHCP, they each told eg. dnsmasq their name when they connected so laptop1.mydomain.internal and laptop2.mydomain.internal both resolve to the IPs that were handed out to each device. With RDNSS+DNSSL I can tell them that they should look up records on my internal domain and against my internal DNS server, but I can't see a good way for that DNS server to know that they exist or what their hostnames are.
Oh I see. You're supposed to use mdns, but I haven't actually done that yet, it's sort of the last thing on my list.
Mine is all static. I run a bind9 forwarder for DNS, and KEA for dhcp4. I have a little list of machines/macs/addresses as the source of truth, and a pair of python scripts that generates kea-dhcp4.conf and a bind9 zone file from that table.
When I enabled IPv6, I just put all the SLACC addresses in that table, and made the python script generate AAAA records too. But this is honestly really stupid, I need to actually use mdns...
I thought about writing a little systemd oneshot that used rfc2136 dyndns updates for home. But it feels like reinventing the wheel a bit...
Perhaps I should give mDNS another look, then. Feels like a regression, but if it works.
> When I enabled IPv6, I just put all the SLACC addresses in that table, and made the python script generate AAAA records too.
Er, isn't that just manual static assignment, then? Not SLAAC? Don't get me wrong, static addresses do make DNS easy...
> Er, isn't that just manual static assignment, then? Not SLAAC?
Haha no, much dumber than that: I boot the machine, get the permanent SLAAC address it comes up with, put that in the static table, and re-run the script to generate the zone files. The downside is the address changes if you reinstall the OS, but I do that so rarely it honestly hasn't been a problem (and you can force the older MAC-based address generation if you want it to be stable). I wouldn't recommend this setup though...
I do also have some static addresses, like that DNS server address.
LLOL, okay yes that is. Er. An unusual setup:D As the guy who usually says "if it works"... I'm surprised that works. But only because I thought SLAAC addresses changed at least per-boot. But since that clearly isn't the case: Well, if it works...
P.S. thanks for the funniest HN comment I've read in a while
Every device on my LAN handles mDNS, or at least the ones I SSH to do.
Nothing is stopping your router which does RA to also work in tandem with an internal dns server that can do hostnames for you mapped to slaac addresses.
I'm not sure I follow? AIUI, RA lets you tell hosts about a DNS server, and an internal DNS server could have AAAA records pointing at SLAAC addresses, but how would it know what hostnames go to those addresses?
I'm pretty sure that you can use both. RAs even have bits to indicate if one is supposed to autoconfigure, [0] hit up a DHCPv6 server for some or all configuration, [1] or both. radvd refers to them as AdvAutonomous and AdvOtherConfigFlag/AdvManagedFlag, respectively.
[0] <https://datatracker.ietf.org/doc/html/rfc4861#section-4.6.2>
[1] <https://datatracker.ietf.org/doc/html/rfc4861#section-4.2>
This is exactly what I do. Almost everything has a nice DHCPv6 address so that I can actually remember the ULA + the suffix, but then for the two devices on my network that don't do DHCPv6 they get a SLAAC. One oddity though is that it means most devices on my network have both a SLAAC and a DHCP-provided one, since I wasn't able to be able to get it to prioritize a DHCP. Combine that with them having both ULA addresses and public addresses and some stuff on my network have way more addresses than you'd expect
You can use both, but I've never found a good reason to at home. The DHCPv6 option for specifying an NTP server might be a good reason to... but even Linux machines ignored it when I tried. Maybe in five years :)
>Do you actually own that /48?
In my experience the ISP generally fixes a /64 for each customer. So if in the future you change your ISP, you might want to keep the remaining addresses same while just using a script to replace the preceding /64 address.
My ISPs change the /64 more often. So I use the ULA a lot more often. My router runs its own DNS server and then it advertises this DNS server using a ULA address.
I have mentioned this elsewhere, but ISPs should make BYOIPv6 more common, not just to the Business customers.
Their are people like OP who do this via a VPS provider that supports BYOIP and then tunnel to the VPS network, so there is a demand.
https://news.ycombinator.com/item?id=47355038
I've never heard of an end user ISP that would announce and route a customer owned block of addresses. They'll all give you a static allocation, but it will be in their block. Maybe if you were a huge customer they could do it... but I can't believe they would go to that much trouble for the measly <$100/month they get from me.
Also, I very much don't want all my outbound internet traffic to come from a permanent address range I am publicly known to own. I'd still want an ephemeral /56 for outbound traffic that changed from time to time.
Typically it's similar to ipv4, they try to assign the same address/prefix for the same MAC/DUID. The most common reason to lose your addresses is replacing your router. Hopefully new routers allow you to set the dhcpv6 DUID somehow...
I haven't experienced this. For me it's statically assigned but my guess is that the PON serial and/or MAC is being used or the customer ID. I think the ISPs have gotten very automated these days and everything seems to be some sort of SDN. It saves lot of labour hours in troubleshooting like customer forgetting their wifi passwords to their routers.
Interesting. Honestly I like having control over it, that would annoy me. I deliberately change the DUID in dhcpcd to force my public addresses to change every so often.
> Do you actually own that /48?
Well. From TFA:
The link embedded in the pull quote is [0], which isn't maximally helpful, but it's useful. Approximately 60 seconds of poking around there brings us to [1], which quotes a "ARIN - /48 IPv6 lease ... Use on our network or yours" for $8/year with a $2 setup fee. That sounds a lot like what's mentioned in TFA.So. You tell me?
[0] <https://freerangecloud.com/>
[1] <https://freerangecloud.com/products.php>
It's was a rhetorical question, he doesn't own it. And it takes much less than sixty seconds to figure that out:
If that VPN provider goes out of business, he probably loses those addresses.> * You're really supposed to pick a random prefix in fd00::/8, but uniqueness only matters if you intend to merge networks with somebody else later, I care more about it being easy to remember.
If you don't care about collision resistance, why didn't you pick fd00:: ? That's way easier to remember than that jumble of letters you selected. It's actually my go-to subnet when someone claims that local-only IPv6 addresses are "hard to remember". fd00::1 is notably shorter than 10.0.0.1.
Heh, fair enough. I picked it because it makes me laugh when I have to type it (say it in Elmer Fudd's voice). I don't actually type it very often.
You can write it as 10.1 though
You could, sure. You shouldn't, because not only is it nonstandard, roughly noone writes it that way.
Without consulting documentation or otherwise querying external memory, tell me what is 10.1.1?
Why though? What's the problem with ipv4?
I find it much simpler for troubleshooting etc to have simple IPv4 addresses. But cool that it can be done :)
I've switched off IPv6 on my router anyway, I haven't yet needed it. My provider didn't offer it last time I checked but when they do enable it I don't want it suddenly popping up against an untested router configuration.
> Why though? What's the problem with ipv4?
NAT in general where if you need/want peer-to-peer (P2P) you're suddenly in the realm of STUN/TURN/ICE infrastructure. Depending on your ISP, there's also CG-NAT, in which case (double) hole punching is basically impossible.
If you're 'just' a user, then that may have been dealt with the for you by whatever app/service you're using (e.g., video game companies), but if you're the one having to push out the good/service, it's an entire layer of complexity that has to be dealt with.
I don't know your background, but I find that the people who feel that there's nothing wrong with IPv4 have never done any work with UPNP or NAT. For them it's always "just worked" and they don't recognise what pain has gone into trying to keep it working well despite our usage of it bordering abusive.
NAT is the devil.
If anyone replies to this with the myth that NAT is a security mechanism I will firmly, yet politely, point them to a network development course because they don't know what they're talking about and I'm sick of hearing it. It's not true, I will not entertain this falsehood anymore.
I dunno, I've manually set up NAT (down to the sysctls and iptables) and it's... fine. There's a small learning curve, but it's small. You should of course run a firewall which NAT is not; that's also simple and just basic hygiene.
Well, if you've set it up then you're aware that you need conntrack;
Conntrack is not always your friend, and even when it is: it's adding a lot of overhead.
https://www.tigera.io/blog/when-linux-conntrack-is-no-longer...
Well yes, a stateful NAT is stateful. But as that article notes:
> For most workloads, there’s plenty of headroom in the table and this will never be an issue.
And yes, if you're doing thousands of connections per second then you should evaluate things more carefully for performance, but again... That's rather a lot.
It's interesting that you'd think that.
Connection table of a single IP is as high (by default) as 16,383[0].
I've hit this limit personally, and due to limitations in stateful firewalling we had to move to stateless filters inside our network equipment instead.
[0]: https://learn.microsoft.com/en-us/troubleshoot/windows-clien...
It's interesting that I agree with the article that you linked?
I'm not contesting that it's completely possible to hit the limits in play, but 16k connections (per IP) is high enough that I don't think that's a common problem, even in public-facing web services. Granted, I suspect the services I've run professionally all dealt with it by making it the problem of a load balancer in front of the application and internal network, but... you probably have that anyways, so I'm still not seeing the problem.
it’s interesting because I think youve internalised the constraint and built mechanisms around it rather than engaging directly with it, subconsciously.
I'm not sure why that would be interesting either, but no, it's not a constraint I've ever hit so I doubt that I'd bother avoiding it, subconsciously or otherwise.
I do work with NAT, but the stuff I use does hole-punching pretty transparently. I run 2 VPSes to facilitate this. I don't use UPNP, I have it explicitly disabled everywhere (too much malware that tries to leverage it)
And yes I know that NAT has the same effect as a "deny all inbound" on IPv6. Which is something I would set there too if I did use IPv6 so I'd still have to do hole-punching anyway.
This video summarizes it nicely
https://www.youtube.com/watch?v=42Hy4JtBeQA
Thanks for sharing this! Every few years, i forget the "why" advantage of IPv6. :-)
For my own networks I use the private range internally (fd00::/8). That way the addresses remain the same when we move or change the pipe to a bigger one. Also, they can be routed, just not on the Internet. It's easy to join remote networks over wireguard and there's plenty of room for experimentation.
I suspect I am going to be running dual stack for at least the next decade, IPv4 switch off feels very far away. I don't think there is much advantage or disadvantage to running IPv4 compared to translation. The current internet doesn't feel ready. I have had less issues with IPv6 this year compared to last so there has been some progress but I am still getting fallbacks to IPv4, some companies don't seem to care much about IPv6 outages currently.
Finally. I will now be able to run ~340 undecillion devices on my home network. I'll have the smartest "smart home" on the block.
I never understood the rationale of giving out /64 and /48 like candy after what happened with ipv4. I know it's still a massive increase in capacity and I know it makes the networking easier but it seems like we went from something that definitely won't run out (ipv6 addresses) to something that probably won't (number of /48 ranges)
I can think of at least two reasons why this isn't worth worrying about.
One is quantitative: you have to remember that 2^48 is a much much bigger number than 2^32. With 2^32 IPv4 addresses, you have about 0.5 addresses per human being on the planet, so right away you can tell that stringent allocation policies will be needed. On the other hand, with 2^48 /48 ranges, there are about 8,000 ranges per human being.
So even if you hand a few /48s out free to literally everyone who asks, the vast majority will still be unallocated. A /48 is only about 0.01% of what could be said to be a "fair" allocation. (And yet, a /48 is so huge in absolute terms that even the vast majority of organizations would never need more than one of them, let alone individuals.)
The other is that unlike, say, the crude oil we pump out of the ground, IP address ranges are a renewable resource. If you hand out a free /48 to every person at birth, then long before you start running out of ranges, people will start dying and you can just reclaim the addresses they were using.
/48s are "small" enough that we could give ~8 billion people each 35,000 of them and we'd still have ~1.5 trillion (over 300x the size of the ipv4 space) left over. Addresses are basically infinite, but routing table entries (which fragmentation necessitates) have a cost.
Current recommendation (afaict ianant) for ISPs is to give everyone a /56. Not every isp does that, ofc
In IPv6 the smallest 'subnet' is /64 if I recall correctly.
It's weird having a subnet size equal to a complete IPv4 Internet worth of IPv6 Internets but I believe the rationale was that you would never in practise run of out IPs in your subnet. A lot of Enterprise IPv4 headaches are managing subnets that are not correctly sized (organic growth, etc.). IPv6 is always routable for the same reason (companies reusing RFC1918 making connecting networks a pain).
There are different headaches with IPv6 - such as re-IPing devices if they move subnet - i.e. move physical location, or during a failover etc.
I'm not sure what the best practise there is as many enterprises don't use IPv6 internally. In my experience anyway.
The big issue I see is every enterprise has a solid numbering plan for RFC1918 networks. Unfortunately, many of them have the SAME plan, and when peering networking between SaaS vendors and customers was more popular (now, of course, privatelink seems to be the move) we constantly ran into conflicts. There's still the risk of conflict with IPv6, but I think if numbering decisions are made thoughtfully, they can be avoided.
There's no risk at all if you're using your own allocated prefix, because those are managed by IANA/RIRs/LIRs to not overlap.
Incidentally, if you find yourself experiencing an RFC1918 clash, one simple way of fixing it is to use NAT64 to map the remote side's RFC1918 into a /96 from your v6 allocation. You can write the last 32 bits of a v6 address in v4 format, so this leads to addresses like 2001:db8:abc:6401::192.168.0.10 and 2001:db8:abc:6402::192.168.0.10, which don't overlap from your perspective.
(If you wanted something simpler to type you could put them at e.g. fd01::192.168.0.10... but then you do start running the risk of collisions with other people who also thought they could just use a simple ULA prefix.)
Yes. I wish they had simply used a more sane address length instead, and maybe given everyone 65535 addresses at most. More than enough for the craziest home lab ever.
Really, just adding 2 bytes to IPv4 would have fixed everything and made it a lot simpler to move over. IPv6 is overkill and I think that really hurt its adoption. I remember being at uni and being told "this is the next big thing". In 1993. And it's not even a big thing now. Not on the user side anyway, I can still access everything from IPv4.
Adding two bytes would have been just as much work as adding 12 bytes, and would have left us with too few addresses rather than too many. The MAC address space is now 64 bits and L3 is necessarily less dense than L2, so 128 bits is the smallest power of 2 where we can be reasonably sure we won't end up with too few addresses.
Considering how hard deploying a new L3 protocol is, we're only going to get one shot at it so it's a lot better to end up with too many addresses rather than too few.
Ehm but IPv6 packets still have the L2 layer as well right? Which already includes the MAC address. So that 64 address MAC space is doubled, it's not like you're saving any. It was a pretty arbitrary decision to accommodate the MAC address inside the IPv6 address and these days it's usually randomised anyway for privacy purposes, so the MAC part of an IPv6 packet doesn't have to be the size of the MAC address.
L3 has nothing to do with MAC addresses anyway so I've always found that a pretty weird decision anyway. Sure, it avoids having to implement ARP but we need that again now anyway with the randomisation. And ARP is like a one-time in a few minutes kinda thing anyway.
I'm pretty sure that if we'd just gone for "a couple bytes extra" we'd have long been completely over. It's the whole L3 transition itself that suffers from the complexity. I remember it well in the 2000s, nobody in telecoms wanted to touch it. And when IPv6 was invented in '93 or so, the installed base was extremely small. It'd have been a piece of cake to get it over with then.
[dead]
If we actually get to the point of address shortages,
Either, NATv6 would become a thing, or instead I hope SLAAC would get deprecated and dhcpv6 would become mandatory so we could give out smaller than /64s
2^64 is 18,446,744,073,709,551,616. That's 18 quintillion. 10^19. There are ~10^10 people on the planet. Each person could have a 10^9 networks (not even devices) before we ran out of /64s.
/48 because ethernet mac addresses are that length and so you can assign everything that and find it.
> able to run ~340 undecillion devices on my home network
You now can have these devices connected to network called Internet.
Unlike IPv4 were the number of devices on the Internet in home network is one (the main router) or zero (in case if CGNAT) and the others just pretend.
It looks like an in-kernel replacement for jool is coming
https://lore.kernel.org/netdev/20260319151230.655687-1-ralf@...
That's fantastic news; there weird friction around NAT64 on Linux has been a real pain point.
IPv6 isn’t that compelling on a simple home network, but avoiding NAT and easier end-to-end connectivity are pretty real advantages.
Wish I could use ipv6. My ISP doesn’t support it (yea, I know tunnels exists but then it’s just more pain than just using ipv4)
Much less pain than people wanting to have something you could connect to would experience.
I can’t understand benefits of having ipv6. The only one is public ips but rest is just headache. In my home network I specify disabled v6 everywhere.
Where I live, the benefit of IPv6 is it's a lot faster than IPv4. All of IPv4 goes through various centralized tunnels and CG-NAT which adds bottlenecks and latency.
IPv4 pricing isn't a good enough reason? If all of my devices had nice ipv6 connectivity I could ditch the public ipv4 addresses, but I have to keep them so that my ipv4-only devices can still reach them.
For home use biggest advantage is that it avoids NAT, which breaks end to end connectivity. Lot of services use hacks to try to mitigate broken connectivity.
video games
It doesn’t matter in home networks, it’s a major pain in the ass if you are a Fortune 500 company and want to set up more intercompany vpn links
A site-to-site VPN of two previously unrelated local networks is a pure gamble with IPv4. It would be almost straight forward with IPv6.
Yes but these days overlay networks are a way more common practice for that, with their own benefits (overlay IPs are always encrypted)
imo one huge benefit is that ipv6 is much easer for hardware to process.. ipv4 headers are messy and change size.
ipv6 headers are 40 bytes! routers have less thinking.
this visualisation might help to dive deeper - https://vectree.io/c/ipv6
Public IPs are a huge benefit and are enough to justify the switch. And there really aren't any headaches in this day and age with IPv6. Once you set it up it works just fine.
Public IPs is a huge huge huge benefit. Your connection is also faster because your IPv6 packets don't have to be processed by a centralised CGNAT.
That's only if you are behind CGNAT though. My fixed ISP doesn't use it.
Yet.
Many ISPs are pushing v4 users into CGNAT so they're easier and cheaper to manage.
This is a big reason why Netflix and YouTube are on v6. To avoid the cost of service over v4.
Even without CGNAT you'll only get one IPv4 address forcing a absurd amount of workarounds to be usable, that are mostly hidden in firmwares but sill there.
Ipv4 is the headache. What are you talking about, ipv6 is simpler in my experience.
IPv4 is pretty simple and good for LANs. Nothing wrong with sticking to it.
> IPv4 is pretty simple and good for LANs.
Until the place you're VPNing to happens to use the same RFC1918 network address as your LAN (that is, your LAN is 192.168.10.x and the network on the other side of your work's VPN is also 192.168.10.x). Or either of them use the same RFC1918 network address libvirt is using for its virtual network. Or you want to route between several LANs (for instance, after a company merger) and some of them (but not all) were using the same RFC1918 network addresses.
All of this is avoided by using public addresses for LANs, but address scarcity makes that hard with IPv4 (unless it's a legacy LAN from the 1900s which happens to still use public addresses form the pre-NAT era).
Don't confuse "simple and good" with "flawless" :-)
There are indeed only a few private-reserved IPv4 ranges, and almost everyone prefers to keep things memorable and easy to type; you get a lot of 10.0.0.0/24, 192.168.0.0/24, 192.168.1.0/24 as a result. That, and common household routers tend to default to one of these three /24 subnets. (Hardly anyone seems to remember that 172.16.0.0/12 exists, feel free to use that if it happens to work for you.)
IPv6 does solve this issue in a few major ways, one of which is the greater expectation to rely on globally routable addresses, of which every one of your devices will have at least one such address. There's also fc00::/7 which is fairly equivalent to the IPv4 private ranges, though to avoid conflicts in random VPNs you should generate a random /64 prefix inside of this, otherwise you run the risk of everyone picking fc00::/64 because it's easy to remember/type (I'm guilty of this myself, but the VPNs I've configured just go into a random 172.16.0.0/12 subnet and no v6 assigned. I have the liberty that I currently don't need/use any VPNs that I haven't personally configured, and that may not hold true in the future.)
Matter requires IPv6
Huh, I have matter devices working here and IPv6 is off on my router and DHCP. And on home assistant too which does the matter router. Does it use link local or something?
I'd be so much more interested in ipv6 if ISPs would just hand out a stable prefix. as it is ipv6 makes very little sense to me
That depends very much on your ISP. Mine (Comcast) does give out a stable prefix. It's not guaranteed to be static forever, but in practice it never changes unless I release it from my router or on the rare occasion they replace their network hardware.
I attempted a similar effort, and found my router had critical ipv6 vulnerabilities including binding the admin and SSH to the WAN on ipv6 (not on ipv4) , and disabling IPv6 firewall altogether so the LAN services were exposed to the internet.
I had the vendor publish their GPL drop, and their upstream vendor did not even have IPv6 support in the product ( the firmware init scripts & admin UI) . So the IPv6 support in the finished product was a rushed copy-paste of IPv4 setup.
I encourage full black box testing of your IPv6 setup, as IPv6 is not in the critical path for QA or consumers, so vulns can persist for years.
Dual stack IPv4+IPv6 is still the easiest, but at least the author learned a lot and it helps finding issues in software.
I messed with this at one point and gave up when I realized every device would have a permanent externally addressable IP within a block that is basically linked to me (good luck trying to change your IPv6 /48 every month or whatever you get with consumer IP addresses)
It’s probably not a big deal and NAT etc. is no protection but it gave me the heebie jeebies.
You know your external IPv4 address rarely changes and also basically linked to you too, right?
> your external IPv4 address rarely changes
Bad generalization. I'm sure policy about this differs a lot, but my consumer ISP definitely reassigns my home's v4 address periodically. I don't track it closely, but it seems that when my ONT power cycles more often than not it pulls a new v4 address.
Now, basing my privacy/security on this would be bad, but to GP's point, if I was using a static v6 block, not only would this address never change, each device in my LAN would have an extra identifier attached to it. External hosts wouldn't merely be able to identify "my house", but traffic from "my phone", "my kid's switch", and "my spouse's phone" would all have distinct addresses.
Of course, my ISP doesn't do v6 at all, so there's no dilemma :')
That's also a poor generalization, though. Some ISPs rotate customer subnets, and devices can rotate their randomized IPs.
That's why I specified if one was using a static v6 network. There are several reasons why this might not be true, from ipv6 CGNAT like what cell providers do, to ISP rotation, to randomization in your own network, to NATing from the private network if you wanted.
But it does seem like it would be far more likely de facto for an ISP to not randomly rotate v6 networks, except maybe to discourage hosting on consumer connections?
> using a static v6 block, not only would this address never change, each device in my LAN would have an extra identifier attached to it.
This is not true.
IPv6 stack allocates at least 3 addresses:
- Link-local - "Permanent" Address derived from the subnet and MAC - Temporary address that changes several times per day
The default address for new connections is always the temporary address. So IP-based tracking from outside your network will be no better than it was before from one day to the next—the /64 will be the only constant here, just as your router's WAN IPv4 is for v4 connections.
Ah, handy! Though it can't always be true, at least for manual configuration ;-) I have two VPSes with v6 addresses (the others don't have it configured...), and both only have LL and their permanent Internet addresses.
My understanding is v6 has two different autoconf schemes, DHCPv6 and a more "native" solution. Do these both always result in interfaces having multiple (routable) addresses?
Most of my IPv6 experience has been setting it up on aforementioned VPS, and being rewarded with slow OS updates, since NetBSD's default CDN, Fastly, blackholes PMTUD, so I had to drop the MTU on the interface just to get v6 TCP connections to work at all[0]. And for point-to-point networking in an overlay VPN, where I just discovered that Chromium has an 11-year outstanding "bug" where it refuses to perform AAAA lookups if you don't have public IPv6 routing.
[0] I could switch mirrors, but the bandwidth drop isn't quite bad enough for me to bother...
If you had v6, they'd probably also reassign your IPv6 prefix delegation, too.
Also, v6 supports "privacy extensions", essentially randomizing the host portion of the address and periodically rotating it, so it is not accurate to say your address would never change.
"mostly" (...) "only"
? I thought they did still support v4?
> This is where DHCPv4 Option 108 comes into the picture. This simply tells the client that IPv6 only mode is preferred. Clients that do not honor this will get a IPv4 address as normal. Those who do have an option can setup 464XLAT to handle IPv4 literals and disable IPv4 addresses.