3 ms·

I think two major problems that IPv6 failed to account for are the unreasonable ambiguity and "global registry" proposed by the Unique Local Address range, e.g

I think two major problems that IPv6 failed to account for are the unreasonable ambiguity and "global registry" proposed by the Unique Local Address range, e.g. fc00::/7. This was even after having the opportunity to fix the previous mistakes in the fec0::/10 range. It was entirely inappropriate for small scale personal networking and assumed an "administrative scope" that's too cumbersome and without purpose for most implementations. I wonder if a dedicated "local" network prefix with a fixed /64 mask and an operating system recognized "alias" would have been a good mechanism to introduce. Something like fec0::/64 with an option to call it "local::". Then you might be able to more easily move from a world of 192.168.10.1, 192.168.10.2 to a world of local::1, local::2, that being translated to fec0::1 and fec0::2.

orangeboats 3y ago
What do you mean by global registry? ULAs do have a local bit, by setting it to 1 (i.e., fd00::/8) you can have your own ULA range. I am using ULA in my own home network.
- akira2501 3y ago
  Right, and the local bit being 0 is currently undefined, but the original and lasting idea (apparently) is to create a central registry for it, so that in some future case where you have to merge corporate networks with their own ULAs there is zero chance that there would ever be a collision between the two. Even in so far as the local bit being 1, there have been at least two attempts to create a "voluntary global registry" for your randomly generated prefix, mostly for the same "collision avoidance" stated above. In either case, somewhat unintuitively, those are still _global_ addresses, and don't have the same level of "non local routing" restrictions that the RFC1918 address space explicitly gained. It's been a mess, and at some point, the IETF just seems to have given up on it.
  - burnerthrow008 3y ago
    > Even in so far as the local bit being 1, there have been at least two attempts to create a "voluntary global registry" for your randomly generated prefix, mostly for the same "collision avoidance" stated above. Like most things people don't like about IPv6, you don't like this because you misunderstand how it's supposed to work. There is no need for a ULA registry because you're supposed to pick a random prefix within the ULA space. The ULA space has 7 bits already defined, so you're picking a random prefix from a space 57 bits big. The chance that you will pick the same prefix as some other specific person is effectively zero. (the birthday paradox does not apply because we don't care if your prefix matches anyone else on earth, just the one specific person/organization that you want to merge networks with). > In either case, somewhat unintuitively, those are still _global_ addresses, and don't have the same level of "non local routing" restrictions that the RFC1918 address space explicitly gained. Err, what? ULAs are routable and "global" addresses in exactly the same way that RFC1918 addresses are routable and global. They are valid addresses within the address space and the only thing that makes them "not globally routable" is that all routers have certain prefixes baked into the firmware as non-routable. If you don't trust your router not to route them for IPv6, why do you trust it for IPv4?
    - akira2501 3y ago
      > Like most things people don't like about IPv6, you don't like this because you misunderstand how it's supposed to work. Thanks for explaining my own motivations to me, while at the same time denying that any discussed changes are relevant to anyone. > There is no need for a ULA registry I was merely summarizing what the public opinion on the matter happens to currently be. Which suggests that the current recommendation to pick a random address and be happy with it is inadequate. The original posts dissatisfaction with being able to deploy IPv6 _conveniently_ also hints that improvements would be welcome by most people. > ULAs are routable and "global" addresses in exactly the same way that RFC1918 addresses are routable and global. RFC1918 explicitly defines it's addresses as local and not globally unique. RFC4193 specifies that these addresses are meant to be globally unique. RFC1918 requires a more specific level of filtering than RFC4193, and the definition of "site local" has always had some ambiguity to it. So, within the very specific and nuanced points I was trying to make, no, they're different.
  - orangeboats 3y ago
    > those are still _global_ addresses They are meant to be globally _unique_ (or effectively so, by utilizing RNG you ensure that it is very, very unlikely for two organizations to have the same ULA), but they are not globally routable.

orangeboats 3y ago

What do you mean by global registry? ULAs do have a local bit, by setting it to 1 (i.e., fd00::/8) you can have your own ULA range. I am using ULA in my own home network.

akira2501 3y ago
Right, and the local bit being 0 is currently undefined, but the original and lasting idea (apparently) is to create a central registry for it, so that in some future case where you have to merge corporate networks with their own ULAs there is zero chance that there would ever be a collision between the two. Even in so far as the local bit being 1, there have been at least two attempts to create a "voluntary global registry" for your randomly generated prefix, mostly for the same "collision avoidance" stated above. In either case, somewhat unintuitively, those are still _global_ addresses, and don't have the same level of "non local routing" restrictions that the RFC1918 address space explicitly gained. It's been a mess, and at some point, the IETF just seems to have given up on it.
- burnerthrow008 3y ago
  > Even in so far as the local bit being 1, there have been at least two attempts to create a "voluntary global registry" for your randomly generated prefix, mostly for the same "collision avoidance" stated above. Like most things people don't like about IPv6, you don't like this because you misunderstand how it's supposed to work. There is no need for a ULA registry because you're supposed to pick a random prefix within the ULA space. The ULA space has 7 bits already defined, so you're picking a random prefix from a space 57 bits big. The chance that you will pick the same prefix as some other specific person is effectively zero. (the birthday paradox does not apply because we don't care if your prefix matches anyone else on earth, just the one specific person/organization that you want to merge networks with). > In either case, somewhat unintuitively, those are still _global_ addresses, and don't have the same level of "non local routing" restrictions that the RFC1918 address space explicitly gained. Err, what? ULAs are routable and "global" addresses in exactly the same way that RFC1918 addresses are routable and global. They are valid addresses within the address space and the only thing that makes them "not globally routable" is that all routers have certain prefixes baked into the firmware as non-routable. If you don't trust your router not to route them for IPv6, why do you trust it for IPv4?
  - akira2501 3y ago
    > Like most things people don't like about IPv6, you don't like this because you misunderstand how it's supposed to work. Thanks for explaining my own motivations to me, while at the same time denying that any discussed changes are relevant to anyone. > There is no need for a ULA registry I was merely summarizing what the public opinion on the matter happens to currently be. Which suggests that the current recommendation to pick a random address and be happy with it is inadequate. The original posts dissatisfaction with being able to deploy IPv6 _conveniently_ also hints that improvements would be welcome by most people. > ULAs are routable and "global" addresses in exactly the same way that RFC1918 addresses are routable and global. RFC1918 explicitly defines it's addresses as local and not globally unique. RFC4193 specifies that these addresses are meant to be globally unique. RFC1918 requires a more specific level of filtering than RFC4193, and the definition of "site local" has always had some ambiguity to it. So, within the very specific and nuanced points I was trying to make, no, they're different.
- orangeboats 3y ago
  > those are still _global_ addresses They are meant to be globally _unique_ (or effectively so, by utilizing RNG you ensure that it is very, very unlikely for two organizations to have the same ULA), but they are not globally routable.