Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FS#3813 - OpenWRT not compliant with RFC6724 #8815

Closed
openwrt-bot opened this issue May 16, 2021 · 2 comments
Closed

FS#3813 - OpenWRT not compliant with RFC6724 #8815

openwrt-bot opened this issue May 16, 2021 · 2 comments
Labels

Comments

@openwrt-bot
Copy link

@openwrt-bot openwrt-bot commented May 16, 2021

tsunulukai:

Summary:

  • 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
  • Discussion thread that lead to opening this bug report: https://forum.openwrt.org/t/howto-make-openwrt-rfc6724-compliant/

Systems on which this has been tested with identical results

  • GL.iNet GL-B1300 - ipq40xx/generic - arm_cortex-a7_neon-vfpv4 - OpenWrt 21.02.0-rc1 r16046
  • NetGear WNDR3700 - ar71xx/generic - mips_24kc - OpenWrt 19.07.6 r11278
  • NetGear WNDR4300 - ar71xx/nand - mips_24kc - OpenWrt 19.07.6 r11278

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)

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented May 17, 2021

jow-:

Please take this discussion upstream to musl libc, I don't see OpenWrt altering such core libc resolver functions anytime soon.

@openwrt-bot
Copy link
Author

@openwrt-bot openwrt-bot commented May 17, 2021

bjonglez:

Musl does implement (a minimal subset of) RFC 6724, see https://git.openwrt.org/7fea9d9f5dd282a7

Allowing to configure the policy table is a SHOULD in the RFC so it's not mandatory to do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant