You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug: OpenWRT (musl/getaddrinfo) implements the now obsolete [[https://datatracker.ietf.org/doc/html/rfc3484|RFC3084]] instead of [[https://datatracker.ietf.org/doc/html/rfc6724|RFC6724]]
Feature Request: OpenWRT (musl/getaddrinfo) lacks a policy configuration mechanism, similar to [[https://man7.org/linux/man-pages/man5/gai.conf.5.html|/etc/gai.conf]] available with glibc/getaddrinfo
A call to getaddrinfo(3) might return multiple answers.
According to RFC 3484/6724 these answers must be sorted so that the answer with the highest success rate is first in the list. The RFC provides an algorithm for the sorting. The static rules are not always adequate, though. For this reason, the RFC also requires that system administrators should have the possibility to dynamically change the sorting. For the glibc implementation, this can be achieved with the /etc/gai.conf file.
By default, the following policy table should be applied for destination-address selection when multiple alternatives are possible:
In this context, IPv4 addresses are matched with the ::ffff:0:0/96 prefix.
Therefore, for hosts whose address is obtained by DNS and for wich both A & AAAA record are returned, Openwrt should prefer gloobaly routable IPv6 destination address over IPv4 over IPv6 ULA addresses.
Nevertheless, OpenWrt seems to systematically prefer IPv6 over IPv4, as was foreseen in RFC3084 whose policy table was as follows:
Both RFCs state that "IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here."
Linux systems based on glibc provide such a mechanism with the [[https://man7.org/linux/man-pages/man5/gai.conf.5.html|/etc/gai.conf]] file. But it seems that musl/getaddrinfo implementation lacks such a configuration mechanism.
The behaviour can be tested by using uclient-fetch towards hosts for which both AAAA & A records exist.
┌──[SSH://root@openwrt]──[~]────────
tsunulukai:
Summary:
Systems on which this has been tested with identical results
A call to getaddrinfo(3) might return multiple answers.
According to RFC 3484/6724 these answers must be sorted so that the answer with the highest success rate is first in the list. The RFC provides an algorithm for the sorting. The static rules are not always adequate, though. For this reason, the RFC also requires that system administrators should have the possibility to dynamically change the sorting. For the glibc implementation, this can be achieved with the /etc/gai.conf file.
By default, the following policy table should be applied for destination-address selection when multiple alternatives are possible:
Prefix Precedence Label ::1/128 50 0 ::/0 40 1 ::ffff:0:0/96 35 4 2002::/16 30 2 2001::/32 5 5 fc00::/7 3 13 ::/96 1 3 fec0::/10 1 11 3ffe::/16 1 12
In this context, IPv4 addresses are matched with the ::ffff:0:0/96 prefix.
Therefore, for hosts whose address is obtained by DNS and for wich both A & AAAA record are returned, Openwrt should prefer gloobaly routable IPv6 destination address over IPv4 over IPv6 ULA addresses.
Nevertheless, OpenWrt seems to systematically prefer IPv6 over IPv4, as was foreseen in RFC3084 whose policy table was as follows:
Prefix Precedence Label ::1/128 50 0 ::/0 40 1 2002::/16 30 2 ::/96 20 3 ::ffff:0:0/96 10 4
Both RFCs state that "IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here."
Linux systems based on glibc provide such a mechanism with the [[https://man7.org/linux/man-pages/man5/gai.conf.5.html|/etc/gai.conf]] file. But it seems that musl/getaddrinfo implementation lacks such a configuration mechanism.
The behaviour can be tested by using uclient-fetch towards hosts for which both AAAA & A records exist.
┌──[SSH://root@openwrt]──[~]────────
nslookup google.com
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: google.com
Address 1: 172.217.168.206
Address 2: 2a00:1450:400e:80c::200e
┌──[SSH://root@openwrt]──[~]────────
nslookup nas.lan
Server: 127.0.0.1
Address: 127.0.0.1#53
Name: nas.lan
Address 1: 192.168.1.1
Address 2: fd6a:1d5e:8a36:2337::1
┌──[SSH://root@openwrt]──[~]────────
uclient-fetch -O /dev/null http://google.com
Downloading 'http://google.com'
Connecting to 2a00:1450:400e:803::200e:80
Redirected to / on www.google.com
Writing to '/dev/null'
Download completed (13759 bytes)
┌──[SSH://root@openwrt]──[~]────────
uclient-fetch -O /dev/null http://nas.lan
Downloading 'http://nas.lan'
Connecting to fd6a:1d5e:8a36:2337::1:80
Writing to '/dev/null'
Download completed (3506 bytes)
The text was updated successfully, but these errors were encountered: