You shouldn’t have to?? Maybe you might need to change the mask in your firewall settings if the ipv6 allocation block size changes but that should be it.
You should only assign static ipv6 to servers, in theory you could just define a host id and use a prefix too. But, most people at home really aren't running enough servers to make that worthwhile. Everything else should just pick up new addresses fine using ND.
Will the app for the smart thermostat be updated three years from now and still be useful? If it was instead a web server app on a routable IP, it wouldn't matter provided they didn't fuck up the authentication and access control.
Yeah, but they're not. That's the modern world. But also even if it was a web server there's usually ways to advertise the IP for the app to connect to. I've seen other stuff do that. So getting an IP is easy. Once the app knows the IP and if you really want to allow connections from outside to your IOT devices (I wouldn't) it could remember the IP and allow that.
You really don't need to give a fixed IP to everything. I think I've given 1 or 2 things fixed IPv6 IPs. Everything else is fine with what it assigns itself.
The other app off the top of my head is VoIP. You should be able to "dial" a number directly. Most solutions go through the company's data center first in order to pierce through NAT. Which makes it more expensive, less reliable, slower, and more susceptible to snooping.
There's a "if you build it, they will come" effect here. Once you can address hosts directly, a whole bunch of things become better, and new ideas that were infeasible are now feasible. They don't exist now because they can't.
You can use ULAs (unique local addresses) or that purpose. Your devices can have a ULA IPv6 address that's constant, and a public IPv6 that changes. Both can be assigned using SLAAC (no manual config required).
I do this because the /56 IPv6 range provided by my ISP is dynamic, and periodically changes.
Yes but you’d still be performing NAT. It’s at least 1:1.
You’ll need to deal with firewall rules regardless, and drop IPs into policies. IPv6 doesn’t remove any of those chores but gets rid of having to maintain tables to deal with many-to-one NAT.
There's no translation between them. With IPv6, one network interface can have multiple IPs. A ULA (internal IP) is only used on your local network. Any internet-connected devices will also have a public IPv6 address.
ULAs aren't too common. A lot of IPv6-enabled systems only have one IP: The private one.
If you use a single shared public ip then you’re using some amount of address translation
This is practically never the case with IPv6. Usually, each device gets its own public IP. This is how the IPv4 internet used to work in the old days (one IP = one device), and it solves so many problems. No need for NAT traversal since there's no NAT. No need for split horizon DNS since the same IP works both inside and outside your network.
There's still a firewall on the router, of course.
At least that’s how I understand ipv4 and I don’t think ipv6 is much different.
With IPv6, each network device can have multiple IPs. If you have an internal IP for whatever reason, it's in addition to your public IP, not instead of it.
IPs are often allocated using SLAAC (stateless address auto config). The router tells the client "I have a network you can use; its IP range is 2001:whatever/64, and the client auto-generates an IP in that range, either based on the MAC address (always the same) or random, depending on if privacy extensions are enabled - usually on for client systems and off for servers.
Just like ipv4 though, you wouldn’t use external addresses internally because your external IPs might change, such as when moving between ISPs. You would NAT a hosts external address to its internal address.
your external IPs might change, such as when moving between ISPs
This is true
You would NAT a hosts external address to its internal address.
This is usually not true.
If you're worried about your external IP changing (like if you're hosting a server on it), you'd solve it the same way you solve it with IPv4: Using dynamic DNS. The main difference is that you run the DDNS client on the computer rather than the router. If there's multiple systems you want to be able to access externally, you'd habe multiple DDNS hostnames.
1:1 stateless NAT is useful for static IPs. Since all your addresses are otherwise global, if you need to switch providers or give up your /64, then you'll need to re-address your static addresses. Instead, you can give your machines static private IPs, and just translate the prefix when going through NAT. It's a lot less horrible than IPv4 NAT since there's no connection tracking needed.
This is something I probably should have done setting up my home Kubernetes cluster. My current IPv6 prefix is from Hurricane Electric, and if my ISP ever gives me a real IPv6 prefix, I will have to delete the entire cluster and recreate it with the new prefix.
It should only be needed if your ISP is brain-dead and only gives you a /64 instead of what they should be doing and also giving you a /56 or /48 with prefix delegation (I.e it should be getting both a 64 for the wan interface, and a delegation for routing)
You router should be using that prefix and sticking just a /64 on the lan interface which it advertises appropriately (and you can route the others as you please)
Internal ipv6 should be using site-local ipv6, and if they have internet access they would have both addresses.
Site-local ipv6 would work here as well, true. But then my containers wouldnt have internet access. Kubernetes containers use Ipam with a single subnet, they can't use SLAAC.
Point is, you should be able to have them have both. Or stick a reverse proxy in front that can translate. Unless they're somehow meant to be directly internet reachable the public addresses could be autogenerated
Full disclosure though I don't know anything about kubernetes.
I haven't really looked into it, but it doesn't seem like it.
Heres the documentation about having multiple cidr pools in one cluster with the Cilium network driver, and it seems to imply that each Pod only gets one IP.
There's something called Multus that I haven't looked into, but even then it looks like that is for multiple interfaces per Pod, not multiple IPS per interface.
Containers are just network namespaces on Linux, and all the routing is done in iptables or ebpf, so it's theoretically possible to have multiple IP addresses, but doesn't look like anybody has started implementing it. There's actually a lot of Kubernetes clusters that just use stateful IPv6 NAT for the internal Pod network, unfortunately.
Weird! Though I guess a lot of these would be sitting behind load balancers / reverse proxies anyway (so ipv4 is fine) and unlikely to up and change isps very often? Lol
I have static IPs for my Kubernetes nodes, and I actually use DHCPv6 for dynamic dns so I can reach any device with a hostname, even though most of my devices don't have static IPs.
The issue is those static IPs are tied to my current ISP, preventing me from changing ISPs without deleting my entire Kubernetes cluster.
My ISP does this right (provides a /56 for routing), but unfortunately both are dynamic and change periodically. Every time I disconnect and reconnect from the internet, I get a different prefix.
I ended up needing to have ULAs for devices where I need to know the IPv6 address on my network (e.g. my internal DNS servers).
I use openwrt on my home network which uses dnsmasq for dhcp. It can give a static suffix which just works with the global prefix on the interface and the site local / ula prefix it uses