3 ms·

Most of the bitching about IPv6 is from those who really, really want IP addresses to identify machines or users. IP addresses (including IPv4) were never inten

Most of the bitching about IPv6 is from those who really, really want IP addresses to identify machines or users. IP addresses (including IPv4) were never intended to do that and it was never a good idea to put them in that position. There was a time when most devices had 1 network interface and didn't move. But that was never a guarantee. People thought it was a guarantee when your $400-in-1988-dollars Madge ISA full-height full-width token-ring NICs with dangling AUI dongles next to your tank of an ST225 hard drive were a thing, but we're past that. Today most things that aren't servers have at least 2 - wired/Wi-Fi for laptops, Wi-Fi/cellular for phones. You can talk about NAT and security and mapping all you want, but if I can bypass your corporate internal network security simply by turning off my phone's Wi-Fi, yet still get to your resources - then NAT is a legacy chore that IPv6 makes unnecessary.

menotyou 6mo ago
My IPS changes my prefix once in while. I consider this a privacy feature, not a bug. Now I find myself in a situation that my devices are not reachable anymore as when the IPv6 address changes and both DNS entries and firewall need to be updated each time when the prefix changed (In between connections break, but this might be a lesser problem) As far as I understand the only solution which does not include some complex scripting of ip change detection and automatically updating the firewall rules is to use NAT66 and ULA. But even then I have a protocol whose most advertised feature is not to rely on NAT and puts mit fast in a situation in need to use NAT. And the privacy extension of every device or the devices using SLAC and not DHCPv6 are problematic. IPv6 is just not able to steup efficiently for where IP addresses are changing. Not with moving mobile devices, not in wifi environments with multiple access points, not with changing prefixes, not in failover scenarios. Bottom Line: I disabled IPv6 again here without any intentions to look for complex workarounds. All outbound traffic is now IPv4 again. IPv6 is providing no benefit but causes additional problems over IPv4 due to issues with the design. I am waiting for IPv7 (or whatever will be the next successor of IPv4) will arrive.
- Dagger2 6mo ago
  Are you talking about reaching the devices from inside the network, or outside? If inside then you don't need NAT66 and ULA, you just need ULA. Use both ULA and the ISP GUAs on the network, and do your internal connections over ULA. If outside, then NAT66+ULA doesn't help because connections from outside will still fail until you update DNS for the new prefix. NAT66 doesn't help in either situation, so why do you think you need to use it here? > automatically updating the firewall rules You can probably structure your firewall rules to not rely on the prefix, e.g. by doing "connections from WAN to LAN where the address matches ::42/-64" -- you might to write it with a mask instead (::42/::ffff:ffff:ffff:ffff), which looks awful but works fine. There's no point in putting a specific prefix into the rule if you're just going to change it to match the network anyway.
  - bigfatkitten 6mo ago
    If you’re dual stack, your OS will prefer IPv4 to ULA and ULA won’t be used at all, and so the extra config overhead of deploying ULA is pointless.
    - Dagger2 6mo ago
      It'll prefer ULAs when connecting to hosts without A records. Programs will use ULAs if you connect to an IP literal, or if connecting to the A records fails. Also, Linux/glibc will prefer ULAs if you have a ULA assigned to the machine, and so will anything using the update to RFC 6724. So "ULA won't be used at all" is definitely not correct.

menotyou 6mo ago

My IPS changes my prefix once in while. I consider this a privacy feature, not a bug. Now I find myself in a situation that my devices are not reachable anymore as when the IPv6 address changes and both DNS entries and firewall need to be updated each time when the prefix changed (In between connections break, but this might be a lesser problem) As far as I understand the only solution which does not include some complex scripting of ip change detection and automatically updating the firewall rules is to use NAT66 and ULA. But even then I have a protocol whose most advertised feature is not to rely on NAT and puts mit fast in a situation in need to use NAT. And the privacy extension of every device or the devices using SLAC and not DHCPv6 are problematic. IPv6 is just not able to steup efficiently for where IP addresses are changing. Not with moving mobile devices, not in wifi environments with multiple access points, not with changing prefixes, not in failover scenarios. Bottom Line: I disabled IPv6 again here without any intentions to look for complex workarounds. All outbound traffic is now IPv4 again. IPv6 is providing no benefit but causes additional problems over IPv4 due to issues with the design. I am waiting for IPv7 (or whatever will be the next successor of IPv4) will arrive.

Dagger2 6mo ago
Are you talking about reaching the devices from inside the network, or outside? If inside then you don't need NAT66 and ULA, you just need ULA. Use both ULA and the ISP GUAs on the network, and do your internal connections over ULA. If outside, then NAT66+ULA doesn't help because connections from outside will still fail until you update DNS for the new prefix. NAT66 doesn't help in either situation, so why do you think you need to use it here? > automatically updating the firewall rules You can probably structure your firewall rules to not rely on the prefix, e.g. by doing "connections from WAN to LAN where the address matches ::42/-64" -- you might to write it with a mask instead (::42/::ffff:ffff:ffff:ffff), which looks awful but works fine. There's no point in putting a specific prefix into the rule if you're just going to change it to match the network anyway.
- bigfatkitten 6mo ago
  If you’re dual stack, your OS will prefer IPv4 to ULA and ULA won’t be used at all, and so the extra config overhead of deploying ULA is pointless.
  - Dagger2 6mo ago
    It'll prefer ULAs when connecting to hosts without A records. Programs will use ULAs if you connect to an IP literal, or if connecting to the A records fails. Also, Linux/glibc will prefer ULAs if you have a ULA assigned to the machine, and so will anything using the update to RFC 6724. So "ULA won't be used at all" is definitely not correct.