On Mon, Jun 29, 2026 at 6:17 AM Eric C. Landgraf <[email protected]> wrote: > The short version is that glibc's implementation has been lagging well > over a decade behind the internet standardization process. Most versions > of glibc adopt the obsoleted RFC 3484 prefix table, which has many > problems described in RFC 5220. RFC 6724 makes some attempts to improve > the situation,
Thanks Eric, If I read the materials correctly, it boils down to source address selection. There are several key scenarios in which ULA can be deployed for off-Internet use and it only works right in one of them. Scenario 1: The host is not connected to the Internet at all and has only a ULA IPv6 address. This scenario works without problems. If you replace the ULA address with an ARIN-assigned address still for off-Internet use, it also works. Scenario 2: The host has an IPv4 address connected to the Internet and an IPv6 ULA address autoconfigured from the route advertisement. Because the host has an IPv6 address and an IPv6 default route, applications attempt to connect to the Internet via IPv6 and fail before falling back to IPv4. If the ULA addresses are replaced with ARIN-assigned addresses, still off-Internet, the failure mode is the same. Scenario 3: The host has an IPv4 address connected to the Internet and an IPv6 ULA address autoconfigured from the route advertisement. The route advertisement suppresses the default route and offers a more specific fc00::/7 route to connect to other ULA hosts. This fails because most hosts reject the route that is more specific than default, leaving them unable to route with IPv6 at all. Some hosts don't support the route option. Others (like Linux) have it disabled by default. If the ULA addresses are replaced with ARIN-assigned addresses, still off-Internet, the failure mode is about the same. Scenario 4: The host has both ULA addresses for internal communication and ISP IPv6 addresses for access to the Internet. The IPv6 network stack does not match routes to addresses when selecting a source address, so if an interface with an IPv6 default route has both an ISP-assigned address and a ULA address, it won't reliably select the ISP address for Internet communication. If the ULA addresses are replaced with ARIN-assigned addresses, still off-Internet, the failure mode is about the same. In all four scenarios, the operation is similar or identical regardless of the off-Internet use of ULA versus ARIN-assigned addresses. RFC 6724 attempts to mitigate these problems by labelling supernets where a source address in the same supernet as the destination should be preferred. If I understand it right, this would actually be worse in the ARIN-assigned address case since the off-Internet addresses would be in the same 2000::/3 supernet as the Internet addresses. Did I miss or misunderstand anything? Would you mind delving into the missing parts for me? Regards, Bill _______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
