On Jun 28 18:12, William Herrin wrote: > On Fri, Jun 26, 2026 at 2:05 PM Eric C. Landgraf <[email protected]> wrote: > > I'd like to see ULAs go the way of the dodo in enterprise environments. > > They have caused me nothing but problems, in part because of glibc's > > address selection algorithm. > > Would you mind expanding on this? I have little operational experience > with IPv6 RFC 4193 addresses and I expect most folks here are in the > same boat. I understand that glibc would only be involved in setting > the order in which DNS lookup results are returned to a program. Is > that correct? When I look at my local /etc/gai.conf, it doesn't call > out fc00::/7 for different treatment than any other IPv6 address. For > off-Internet use, where does that end up creating a problem?
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, but this is not implemented by glibc upstream. (for the record, there is a 2-year-old open pull request implementing it: https://patchwork.sourceware.org/project/glibc/patch/[email protected]/) In an environment where ULAs coexist with GUAs, it is relatively unpredictable which source address will be selected, especially for internet-bound traffic. In addition, for all but trivial cases (i.e. ULA-only or single GUA-only) you will likely have to edit the gai.conf configuration of each endpoint. Ideally a daemon with more awareness of the network would shim in for address selection, but this creates complexity. Note: these issues are actually mitigated by strictly off-internet use, for the case where hosts (say a printer) *only* has the off-internet address, and other systems only have GUAs. DNS order is somewhat orthogonal, but putting ULAs in public DNS is considered to be in poor form, same as with rfc1918 addresses. Multi-view DNS is a solved problem. Eric C. Landgraf Virginia Tech _______________________________________________ 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.
