6 ms·

What's the advice on ULAs? On my internet-connected VLANs, I have a -er- site-local IPv4 subnet, a unique local IPv6 subnet, and a global IPv6 subnet. This work

What's the advice on ULAs? On my internet-connected VLANs, I have a -er- site-local IPv4 subnet, a unique local IPv6 subnet, and a global IPv6 subnet. This works just fine. Does the "advice" boil down to "You should NEVER use ULAs and ALWAYS use GUAs!" and is given by the same very, very loud subset of people who seemed to feel very strongly that IPv6 implementations should explicitly make it impossible to do NAT?

UltraSane 7mo ago
Why would IPv6 ever need NAT?
- simoncion 7mo ago
  Why would anyone need IPv6 to be incapable of doing NAT? To answer your question: Who knows? Perhaps you have a shitlord ISP that only provides you with a /128 (such as that one "cloud provider" whose name escapes me). [0] It's a nice tool to have in your toolbox, should you find that you need to use it. [0] Yes, I'm aware that a "cloud provider" is not strictly an ISP. They are providing your VMs with access to the Internet, so I think the definition fits with only a little stretching-induced damage.
  - UltraSane 7mo ago
    As a network admin I can say that NAT makes everything much harder and that the source and destination IP should stay the same from source to destination whenever possible.
    - simoncion 7mo ago
      Sure. I agree. That doesn't help when your shitbag ISP has given you exactly one /128.
- jcgl 7mo ago
  In any scenario where you want to do traffic steering at a network level. Managing multiple network upstreams (e.g. for network failover or load balancing) is a common example that is served well by numerous off-the-shelf routers with IPv4. That's an important feature that IPv6 cannot offer without using NPTv6 or NAT66. It's conceivable that OSes could support some sort of traffic steering mechanism where the network distributes policy in some sort of dynamic way? But that also sounds fragile and you (i.e. the network operator) still have to cope with the long tail of devices that will never support such a mechanism.
  - simoncion 7mo ago
    > Managing multiple network upstreams (e.g. for network failover or load balancing) is a common example ... that IPv6 cannot offer without using NPTv6 or NAT66. I don't think that's true. I haven't had reason to do edge router failover, but I am familiar with the concepts and also with anycast/multihoming... so do make sure to cross-check what I'm saying here with known-good information. My claim is that the scenario you describe is superior in the non-NATted IPv6 world to that of the NATted IPv4 world. Let's consider the scenario you describe in the IPv4-only world. Assume you're providing a typical "one global IP shared with a number of LAN hosts via IPv4 NAT". When one uplink dies, the following happens: * You fail over to your backup link * This changes your external IP address * Because you're doing NAT, and DHCP generally has no way to talk back to hosts after the initial negotiation you have no way to alert hosts of the change in external IP address * Depending on your NAT box configuration, existing client connections either die a slow and painful death, or -ideally- they get abruptly RESET and the hosts reestablish them Now consider the situation with IPv6. When one uplink dies: * You fail over to your backup link * This changes your external prefix * Your router announces the prefix change by announcing the new prefix and also that the now-dead one's valid lifetime is 0 seconds [0] * Hosts react to the change by reconfiguring via SLAAC and/or DHCPv6, depending on the settings in the RA * Existing client connections are still dead, [1] but the host gets to know that their global IP address has changed and has a chance to take action, rather than being entirely unaware Assuming that I haven't screwed up any of the details, I think that's what happens. Of course, if you have provider-independent addresses [2] assigned to your site, then maybe none of that matters and you "just" fail over without much trouble? [0] I think this is known as "deprecating" the prefix [1] I think whether they die slow or fast depends on how the router is configured [2] ...whether IPv4 or IPv6...
- aboardRat4 7mo ago
  This is how the majority of ipv6 is deployed where I live. The router in a coffee shop gives you an ULA, and NATs everything to a single globally routable public ipv6 address.
  - fulafel 7mo ago
    That's completely f'd of course (and unlike any deployment i've seen).
    - aboardRat4 7mo ago
      It's not. It's simple, understandable, straightforward. Only natting to a single address is flawed, but also understandable, because they want to charge you for a prefix.
      - simoncion 7mo ago
        > It's not [fucked up]. It's simple, understandable, straightforward. Things that are fucked up can also be simple, understandable, and straightforward. Unless you're claiming that DHCPv6 is not simple, understandable, and straightforward... in which case: DHCPv4 is "Give me an IP address, please.". DHCPv6 is "Give me an IP address, please. And also give me what I need for all of my directly-connected friends to have one, too, if you don't mind.".
        aboardRat4 7mo ago
        Dhcpv6 is not simple because it's not universally available. A lot of devices don't support it and likely never will.
        simoncion 7mo ago
        If your edge router supports IPv6, it almost certainly can make a DHCPv6-PD request and handle advertising the assigned prefix on its LAN side. Because of Google's continued (deliberate?) misunderstanding of what DHCPv6 is for, Android clients don't do anything sane with it. That doesn't mean that DHCPv6 isn't simple. Again, DHCPv6 is "Please give me an IP address, and maybe also what my directly-attached friends need to get IP addresses.". Simple, straightforward, and easy to understand. Even if it were relevant, Google's chronic rectocranial insertion doesn't change that.

UltraSane 7mo ago

Why would IPv6 ever need NAT?

simoncion 7mo ago
Why would anyone need IPv6 to be incapable of doing NAT? To answer your question: Who knows? Perhaps you have a shitlord ISP that only provides you with a /128 (such as that one "cloud provider" whose name escapes me). [0] It's a nice tool to have in your toolbox, should you find that you need to use it. [0] Yes, I'm aware that a "cloud provider" is not strictly an ISP. They are providing your VMs with access to the Internet, so I think the definition fits with only a little stretching-induced damage.
- UltraSane 7mo ago
  As a network admin I can say that NAT makes everything much harder and that the source and destination IP should stay the same from source to destination whenever possible.
  - simoncion 7mo ago
    Sure. I agree. That doesn't help when your shitbag ISP has given you exactly one /128.
jcgl 7mo ago
In any scenario where you want to do traffic steering at a network level. Managing multiple network upstreams (e.g. for network failover or load balancing) is a common example that is served well by numerous off-the-shelf routers with IPv4. That's an important feature that IPv6 cannot offer without using NPTv6 or NAT66. It's conceivable that OSes could support some sort of traffic steering mechanism where the network distributes policy in some sort of dynamic way? But that also sounds fragile and you (i.e. the network operator) still have to cope with the long tail of devices that will never support such a mechanism.
- simoncion 7mo ago
  > Managing multiple network upstreams (e.g. for network failover or load balancing) is a common example ... that IPv6 cannot offer without using NPTv6 or NAT66. I don't think that's true. I haven't had reason to do edge router failover, but I am familiar with the concepts and also with anycast/multihoming... so do make sure to cross-check what I'm saying here with known-good information. My claim is that the scenario you describe is superior in the non-NATted IPv6 world to that of the NATted IPv4 world. Let's consider the scenario you describe in the IPv4-only world. Assume you're providing a typical "one global IP shared with a number of LAN hosts via IPv4 NAT". When one uplink dies, the following happens: * You fail over to your backup link * This changes your external IP address * Because you're doing NAT, and DHCP generally has no way to talk back to hosts after the initial negotiation you have no way to alert hosts of the change in external IP address * Depending on your NAT box configuration, existing client connections either die a slow and painful death, or -ideally- they get abruptly RESET and the hosts reestablish them Now consider the situation with IPv6. When one uplink dies: * You fail over to your backup link * This changes your external prefix * Your router announces the prefix change by announcing the new prefix and also that the now-dead one's valid lifetime is 0 seconds [0] * Hosts react to the change by reconfiguring via SLAAC and/or DHCPv6, depending on the settings in the RA * Existing client connections are still dead, [1] but the host gets to know that their global IP address has changed and has a chance to take action, rather than being entirely unaware Assuming that I haven't screwed up any of the details, I think that's what happens. Of course, if you have provider-independent addresses [2] assigned to your site, then maybe none of that matters and you "just" fail over without much trouble? [0] I think this is known as "deprecating" the prefix [1] I think whether they die slow or fast depends on how the router is configured [2] ...whether IPv4 or IPv6...
aboardRat4 7mo ago
This is how the majority of ipv6 is deployed where I live. The router in a coffee shop gives you an ULA, and NATs everything to a single globally routable public ipv6 address.
- fulafel 7mo ago
  That's completely f'd of course (and unlike any deployment i've seen).
  - aboardRat4 7mo ago
    It's not. It's simple, understandable, straightforward. Only natting to a single address is flawed, but also understandable, because they want to charge you for a prefix.
    - simoncion 7mo ago
      > It's not [fucked up]. It's simple, understandable, straightforward. Things that are fucked up can also be simple, understandable, and straightforward. Unless you're claiming that DHCPv6 is not simple, understandable, and straightforward... in which case: DHCPv4 is "Give me an IP address, please.". DHCPv6 is "Give me an IP address, please. And also give me what I need for all of my directly-connected friends to have one, too, if you don't mind.".
      - aboardRat4 7mo ago
        Dhcpv6 is not simple because it's not universally available. A lot of devices don't support it and likely never will.
        simoncion 7mo ago
        If your edge router supports IPv6, it almost certainly can make a DHCPv6-PD request and handle advertising the assigned prefix on its LAN side. Because of Google's continued (deliberate?) misunderstanding of what DHCPv6 is for, Android clients don't do anything sane with it. That doesn't mean that DHCPv6 isn't simple. Again, DHCPv6 is "Please give me an IP address, and maybe also what my directly-attached friends need to get IP addresses.". Simple, straightforward, and easy to understand. Even if it were relevant, Google's chronic rectocranial insertion doesn't change that.