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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
https://lore.kernel.org/netdev/20260319151230.655687-1-ralf@...
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.
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.
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.
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.
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
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.
It’s probably not a big deal and NAT etc. is no protection but it gave me the heebie jeebies.