Show Posts
1
General Discussion / Re: [SOLVED]Assign dynamically provided IPv6 GUA & ULA via DHCPv6 to same LAN subnet
« on: October 03, 2024, 07:45:16 pm »
I don't think people understand the design or the decisions that were made.
IPv6 should be setup as if IPv4 doesn't exist. In that case in order to have a local network that has more than basic link-local and MDNS it needs to have a ULA subnet in order to allow consistent static numbering for servers and communication across different interconnected networks. In the past RFC1918 filled this roll for most organizations since they don't have static public IPv4 delegations. The large majority of IPv6 GUA delegations now happen via DHCPv6 PD, and that's subject to arbitrarily change and so can't be relied upon for statically numbering a local network, thus you need a ULA subnet if you don't have a static IPv6 delegation in order to accomplish a stable local network.
If deciding between using IPv4 and IPv6 local addresses as the source:
- For any endpoint IPv4 address (RFC1918 or public), assume that is the currently working system for any local IPv4 address (RFC1918 or public).
- For endpoint IPv6 address that are GUA assume local ULA has no connectivity. From their view nobody should be using NAT66 for general connectivity, and most ULA configuration in the past has not actually used it.
- For endpoint IPv6 address that are ULA outside of local subnet, you are safer assuming no connectivity, because inter-organization routing of private ULA addresses remains uncommon unlike inter-organization routing of RFC1918 in the past.
- For endpoint IPV6 address that are GUA, if you have a local GUA address you can safely assume connectivity to that IP.
The problem is that the majority of ULA use in the past was without, or problematic public IPv6 Internet connectivity. So it makes perfect sense to choose a local IPv4 to connect to a IPv4 over a local ULA to a GUA IPv6, because we can assume in almost all cases that the existing legacy local connectivity is working.
It shouldn't really be a problem, because if dual stack, then the hostnames should map to the same service endpoints, and the highest probability of connectivity by far is to pick IPv4 under those circumstances.
However, I think most people will continue to use IPv4 RFC1918 as the stable numbered local connectivity forever in the future. The only use case left if IPv4 never goes away is stable inter-organizational routing becoming more problematic with conflicting RFC1918 space.
IPv6 should be setup as if IPv4 doesn't exist. In that case in order to have a local network that has more than basic link-local and MDNS it needs to have a ULA subnet in order to allow consistent static numbering for servers and communication across different interconnected networks. In the past RFC1918 filled this roll for most organizations since they don't have static public IPv4 delegations. The large majority of IPv6 GUA delegations now happen via DHCPv6 PD, and that's subject to arbitrarily change and so can't be relied upon for statically numbering a local network, thus you need a ULA subnet if you don't have a static IPv6 delegation in order to accomplish a stable local network.
If deciding between using IPv4 and IPv6 local addresses as the source:
- For any endpoint IPv4 address (RFC1918 or public), assume that is the currently working system for any local IPv4 address (RFC1918 or public).
- For endpoint IPv6 address that are GUA assume local ULA has no connectivity. From their view nobody should be using NAT66 for general connectivity, and most ULA configuration in the past has not actually used it.
- For endpoint IPv6 address that are ULA outside of local subnet, you are safer assuming no connectivity, because inter-organization routing of private ULA addresses remains uncommon unlike inter-organization routing of RFC1918 in the past.
- For endpoint IPV6 address that are GUA, if you have a local GUA address you can safely assume connectivity to that IP.
The problem is that the majority of ULA use in the past was without, or problematic public IPv6 Internet connectivity. So it makes perfect sense to choose a local IPv4 to connect to a IPv4 over a local ULA to a GUA IPv6, because we can assume in almost all cases that the existing legacy local connectivity is working.
It shouldn't really be a problem, because if dual stack, then the hostnames should map to the same service endpoints, and the highest probability of connectivity by far is to pick IPv4 under those circumstances.
However, I think most people will continue to use IPv4 RFC1918 as the stable numbered local connectivity forever in the future. The only use case left if IPv4 never goes away is stable inter-organizational routing becoming more problematic with conflicting RFC1918 space.