[FS#3813] OpenWRT not compliant with RFC6724

[OpenWrt Bugs]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Tsuñami Ulukaï (tsunulukai) 

Attached to Project - OpenWrt/LEDE Project
Summary - OpenWRT not compliant with RFC6724
Task Type - Bug Report
Category - Base system
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Low
Priority - Very Low
Reported Version - openwrt-21.02
Due in Version - Undecided
Due Date - Undecided
Details - 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)



More information can be found at the following URL:
https://bugs.openwrt.org/index.php?do=details&task_id=3813

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.