3 ms·

One reason could be the proliferation of prefix delegation, meaning an ISP now controls the numbering of your internal network, and it keeps constantly changing

One reason could be the proliferation of prefix delegation, meaning an ISP now controls the numbering of your internal network, and it keeps constantly changing the net block, so you can never get stable local addressing… so you just keep running dual stack or try to use nat66 with a ULA network as a kludge or something.

crest 3y ago
The only in theory clean alternative to the kludges you mentioned is to let DHCPv6 renumber your network automatically which is a major change in how you have to think about your network.
pantalaimon 3y ago
You can have multiple IPv6 addresses on your interface, so you can have both the ULA address for internal use as well as the global address - no need for NAT
- stock_toaster 3y ago
  Source address selection for multiple non-loopback addresses was (maybe still is?) notoriously bad in many OS’s for years.
- Macha 3y ago
  However, the priority order on your OS for address selection, even when it comes to stuff like choosing which DNS results to use is IPv6 global address > IPv4 > ULAs. So on a dual stack network, ULAs with not be used unless the only address is a ULA. And even if you run your internal services with only an AAAA record pointing to the ULA, the client's source address will likely be the global address of the client device unless you tweak the tables on each client, which then means you'll need to have your global address in all your firewall rules to access the internal services on ULAs, which then means you're not saved from having your ISP-provided global address in your configuration, which is what you were trying to avoid by using ULAs.
  - throw0101c 3y ago
    > IPv6 global address > IPv4 > ULAs. The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority: > The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724]. * https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula
    - yyyk 3y ago
      Leaving aside that the draft is badly worded (there are long descriptions of the problem, but no short paragraph saying what must be changed), the long time until this is deployed if ever, the new order will still leave ULA below IPv6 global addresses - which means it doesn't solve stock_toaster's problem at all.

crest 3y ago

The only in theory clean alternative to the kludges you mentioned is to let DHCPv6 renumber your network automatically which is a major change in how you have to think about your network.

pantalaimon 3y ago

You can have multiple IPv6 addresses on your interface, so you can have both the ULA address for internal use as well as the global address - no need for NAT

stock_toaster 3y ago
Source address selection for multiple non-loopback addresses was (maybe still is?) notoriously bad in many OS’s for years.
Macha 3y ago
However, the priority order on your OS for address selection, even when it comes to stuff like choosing which DNS results to use is IPv6 global address > IPv4 > ULAs. So on a dual stack network, ULAs with not be used unless the only address is a ULA. And even if you run your internal services with only an AAAA record pointing to the ULA, the client's source address will likely be the global address of the client device unless you tweak the tables on each client, which then means you'll need to have your global address in all your firewall rules to access the internal services on ULAs, which then means you're not saved from having your ISP-provided global address in your configuration, which is what you were trying to avoid by using ULAs.
- throw0101c 3y ago
  > IPv6 global address > IPv4 > ULAs. The problems this caused/s seems to have been an unintended / unforeseen consequence that was more exposed as people gained experience. There's a draft being worked on to officially change the priority: > The behavior of ULA addressing as defined by [RFC6724] is preferred below legacy IPv4 addressing, thus rendering ULA IPv6 deployment functionally unusable in IPv4 / IPv6 dual-stacked environments. The lack of a consistent and supportable way to manipulate this behavior, across all platforms and at scale is counter to the operational behavior of GUA IPv6 addressing on nearly all modern operating systems that leverage a preference model based on [RFC6724]. * https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-ula
  - yyyk 3y ago
    Leaving aside that the draft is badly worded (there are long descriptions of the problem, but no short paragraph saying what must be changed), the long time until this is deployed if ever, the new order will still leave ULA below IPv6 global addresses - which means it doesn't solve stock_toaster's problem at all.