sgryphon
commented
6 months ago I now have a pull request up with a fix implementing the RFC 6724 algorithm to select the best destination address to return from getaddrinfo() based on the available source addresses: https://github.com/espressif/esp-lwip/pull/66
The problematic example -- connecting TLS to a dual-stack host from an IPv6-only network -- now works.
The logs show both DNS results, and then the selected one; because the device is in an IPv6-only network, the IPv6 address is selected. If connected to an IPv4-only network then the IPv4 address is used.
dns_recv: "v4v6.ipv6-test.com": response = 2001:41d0:701:1100:0:0:0:29c8
dns_recv: "v4v6.ipv6-test.com": response = 51.75.78.103
E (7791) esp-tls: [sock=54] Resolved IPv6 address: 2001:41D0:701:1100::29C8Full log on the same IPv6-only network as in the bug report. The new function logs are prefixed with dns_select, and you can see RFC 6724 Destination Address Selection Rule 2 determines the IPv6 destination address has a source address with a matching scope (both global) whereas IPv4 does not (while the DNS result is global the device only source address is localhost, which is link-local scope).
I (821) example_connect: Connecting to Wildspace...
I (821) example_connect: Waiting for IP(s)
I (3231) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (3491) wifi:state: init -> auth (b0)
I (3591) wifi:state: auth -> assoc (0)
I (3611) wifi:state: assoc -> run (10)
I (3621) wifi:connected with Wildspace, aid = 1, channel 1, BW20, bssid = 02:25:9c:13:92:ab
I (3621) wifi:security: WPA2-PSK, phy: bgn, rssi: -53
I (3631) wifi:pm start, type: 1
I (3631) wifi:dp: 1, bi: 102400, li: 3, scale listen interval from 307200 us to 307200 us
I (3721) wifi:dp: 2, bi: 102400, li: 4, scale listen interval from 307200 us to 409600 us
I (3721) wifi:AP's beacon interval = 102400 us, DTIM period = 2
I (5621) example_connect: Got IPv6 event: Interface "example_netif_sta" address: fe80:0000:0000:0000:0a3a:f2ff:fe65:db28, type: ESP_IP6_ADDR_IS_LINK_LOCAL
I (11621) example_connect: Got IPv6 event: Interface "example_netif_sta" address: 2407:8800:bc61:1300:0a3a:f2ff:fe65:db28, type: ESP_IP6_ADDR_IS_GLOBAL
I (11621) example_connect: Got IPv6 event: Interface "example_netif_sta" address: fd7c:e25e:67e8:0000:0a3a:f2ff:fe65:db28, type: ESP_IP6_ADDR_IS_UNIQUE_LOCAL
I (11631) example_common: Connected to example_netif_sta
I (11641) example_common: - IPv4 address: 0.0.0.0,
I (11651) example_common: - IPv6 address: fe80:0000:0000:0000:0a3a:f2ff:fe65:db28, type: ESP_IP6_ADDR_IS_LINK_LOCAL
I (11661) example_common: - IPv6 address: 2407:8800:bc61:1300:0a3a:f2ff:fe65:db28, type: ESP_IP6_ADDR_IS_GLOBAL
I (11671) example_common: - IPv6 address: fd7c:e25e:67e8:0000:0a3a:f2ff:fe65:db28, type: ESP_IP6_ADDR_IS_UNIQUE_LOCAL
I (11681) example: Updating time from NVS
I (11681) example: Start https_request example
I (11691) example: https_request using crt bundle
dns_enqueue: "v4v6.ipv6-test.com": use DNS entry 0
dns_enqueue: "v4v6.ipv6-test.com": use DNS pcb 0
dns_send: dns_servers[0] "v4v6.ipv6-test.com": request
sending DNS request ID 42552 for name "v4v6.ipv6-test.com" to server 0
I (11721) main_task: Returned from app_main()
dns_recv: "v4v6.ipv6-test.com": response = 2001:41d0:701:1100:0:0:0:29c8
dns_enqueue: "v4v6.ipv6-test.com": use DNS entry 1
dns_enqueue: "v4v6.ipv6-test.com": use DNS pcb 0
dns_send: dns_servers[0] "v4v6.ipv6-test.com": request
sending DNS request ID 14817 for name "v4v6.ipv6-test.com" to server 0
dns_recv: "v4v6.ipv6-test.com": response = 51.75.78.103
dns_select: selecting from 2 candidates
dns_select: precedence labels flags 0x2013, ipv6 scopes flags 0x4004, ipv4 scopes flags 0x0004
dns_select: rule 2, cand_0 scope (14) match 1, cand_1 scope (14) match 0
E (11811) esp-tls: [sock=54] Resolved IPv6 address: 2001:41D0:701:1100::29C8
dns_tmr: dns_check_entries
I (13161) esp-x509-crt-bundle: Certificate validated
dns_tmr: dns_check_entries
I (14691) example: Connection established...
I (14691) example: 113 bytes written
I (14691) example: Reading HTTP response...
dns_tmr: dns_check_entries
HTTP/1.1 200 OK
Date: Tue, 27 Feb 2024 21:33:20 GMT
Server: Apache/2.4.25 (Debian)
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
26
2407:8800:bc61:1300:a3a:f2ff:fe65:db28
0
dns_tmr: dns_check_entries
dns_tmr: dns_check_entries
dns_tmr: dns_check_entries
dns_tmr: dns_check_entries
dns_tmr: dns_check_entries
I (20211) example: connection closed
I (20211) example: 10...
dns_tmr: dns_check_entries
I (21211) example: 9...The same configuration, running on an IPv4-only network, uses the IPv4 address:
I (821) example_connect: Connecting to Shadow...
I (821) example_connect: Waiting for IP(s)
I (3231) wifi:new:<1,0>, old:<1,0>, ap:<255,255>, sta:<1,0>, prof:1
I (3491) wifi:state: init -> auth (b0)
I (3571) wifi:state: auth -> assoc (0)
I (3641) wifi:state: assoc -> run (10)
I (3661) wifi:connected with Shadow, aid = 1, channel 1, BW20, bssid = 06:25:9c:13:92:ab
I (3661) wifi:security: WPA2-PSK, phy: bgn, rssi: -52
I (3661) wifi:pm start, type: 1
I (3661) wifi:dp: 1, bi: 102400, li: 3, scale listen interval from 307200 us to 307200 us
I (3751) wifi:dp: 2, bi: 102400, li: 4, scale listen interval from 307200 us to 409600 us
I (3751) wifi:AP's beacon interval = 102400 us, DTIM period = 2
I (5621) example_connect: Got IPv6 event: Interface "example_netif_sta" address: fe80:0000:0000:0000:0a3a:f2ff:fe65:db28, type: ESP_IP6_ADDR_IS_LINK_LOCAL
I (8671) esp_netif_handlers: example_netif_sta ip: 192.168.5.146, mask: 255.255.255.0, gw: 192.168.5.1
I (8671) example_connect: Got IPv4 event: Interface "example_netif_sta" address: 192.168.5.146
I (8681) example_common: Connected to example_netif_sta
I (8681) example_common: - IPv4 address: 192.168.5.146,
I (8691) example_common: - IPv6 address: fe80:0000:0000:0000:0a3a:f2ff:fe65:db28, type: ESP_IP6_ADDR_IS_LINK_LOCAL
I (8701) example: Updating time from NVS
I (8701) example: Start https_request example
I (8711) example: https_request using crt bundle
dns_enqueue: "v4v6.ipv6-test.com": use DNS entry 0
dns_enqueue: "v4v6.ipv6-test.com": use DNS pcb 0
dns_send: dns_servers[0] "v4v6.ipv6-test.com": request
sending DNS request ID 60548 for name "v4v6.ipv6-test.com" to server 0
I (8731) main_task: Returned from app_main()
dns_recv: "v4v6.ipv6-test.com": response = 2001:41d0:701:1100:0:0:0:29c8
dns_enqueue: "v4v6.ipv6-test.com": use DNS entry 1
dns_enqueue: "v4v6.ipv6-test.com": use DNS pcb 0
dns_send: dns_servers[0] "v4v6.ipv6-test.com": request
sending DNS request ID 17189 for name "v4v6.ipv6-test.com" to server 0
dns_recv: "v4v6.ipv6-test.com": response = 51.75.78.103
dns_select: selecting from 2 candidates
dns_select: precedence labels flags 0x0013, ipv6 scopes flags 0x0004, ipv4 scopes flags 0x4004
dns_select: rule 2, cand_0 scope (14) match 0, cand_1 scope (14) match 1
dns_tmr: dns_check_entries
I (10111) esp-x509-crt-bundle: Certificate validated
dns_tmr: dns_check_entries
I (11631) example: Connection established...
I (11631) example: 113 bytes written
I (11631) example: Reading HTTP response...
dns_tmr: dns_check_entries
HTTP/1.1 200 OK
Date: Tue, 27 Feb 2024 21:35:54 GMT
Server: Apache/2.4.25 (Debian)
Vary: Accept-Encoding
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
f
220.240.255.134
0
dns_tmr: dns_check_entries
dns_tmr: dns_check_entries
dns_tmr: dns_check_entries
dns_tmr: dns_check_entries
dns_tmr: dns_check_entries
I (17171) example: connection closed
I (17171) example: 10...
AxelLin
ivancmz
espressif-abhikroy
Answers checklist.
IDF version.
master
Espressif SoC revision.
ESP32
Operating System used.
Linux
How did you build your project?
Command line with idf.py
If you are using Windows, please specify command line type.
None
Development Kit.
M5Stack Core 2
Power Supply used.
USB
What is the expected behavior?
With both IPv4 and IPv6 fully enabled, DNS lookup (via TLS) should work correctly in all network environments -- IPv4-only, IPv6-only, and dual-stack, for all reachable destinations, by taking into account available addresses.
For example when moving a device to an IPv6-only network only an IPv6 address is available (even though IPv4 is enabled), and so connections to a dual-stack host (that has both) should use the IPv6 address to make the TLS connection.
For this particular bug:
But the connection fails.
What is the actual behavior?
TLS connections fail on an IPv6-only network when connecting to a dual-stack destination, because the preference order is statically configured to IPv4 first. Even though a local IPv4 address is not currently available, for a dual-stack destination the IPv4 address is returned by
getaddrinfo()(instead of the IPv6), so the connection fails.Note that if you disable IPv4, then the connection works; if you enable IPv4 then then connection fails. Enabling IPv4 should not make IPv6 fail (and vice-versa).
Steps to reproduce.
A kind of work around is to reconfigure the application to entirely turn off IPv4, however this then stops the application from being able to roam to different network types and connect to IPv4 only servers.
Debug Logs.
More Information.
Issue
The DNS lookup function getaddrinfo() does not take into account available source address, and so does not work propertly across all network types.
In particular it preferences IPv4 over IPv6, and completely fails in an IPv6-only network for a dual-stack destination, as the IPv4 address is unreachable.
You can work around this in some cases, by checking available addresses yourself and then calling getaddrinfo() multiple times -- this approach has been used in the updated http_request example.
However HTTP is not secure and the same approach can't be used with HTTPS, as the host name is needed to TLS and resolved internally in the TLS code.
Technical details
For the https_request example the TLS code
esp_tls.ceventually callsgetaddrinfo()passing inAF_UNSPECto get any address.However the code in
netdb.cthen converts this into a fixed preference order (when both IPv4 and IPv6 are enabled) ofNETCONN_DNS_IPV4_IPV6.A client with both IPv4 and IPv6 enabled should work in any network IPv4-only, IPv6-only, or dual-stack, and to any reachable destination.
Changing to use a static order of
NETCONN_DNS_IPV6_IPV4wouldn't fully work either.This other order allows IPv6-only to work, and means that dual-stack preferences IPv6 and still falls back for IPv4-only destinations.
But it has the reverse problem that in an IPv4-only network a dual stack destination will fail, as it returns the unreachable IPv6 address.
Proposed solution
To be able to work across all networks, the address selection needs to be dynamic based on what is actually available. (Not static based on what is enabled in configuration)
For a dual-stack destination, if a global (including ULA) IPv6 address is available, then use IPv6, but if it a gobal IPv6 address is not available (even though IPv6 is enabled it may not be provided, e.g. if currently on an IPv4-only network) then the IPv4 address needs to be used.
A full implementation of this approach is detailed in RFC 6724, taking into account not only what addresses are available, but their scopes and with special allowances for deprecated address ranges.
Available addresses should be sorted according to RFC 6724, with the application using the first address returned.
The standard linux function
getaddrinfo()takes this approach "The sorting function used within getaddrinfo() is defined in RFC 3484" (RFC 3484 was replaced by RFC 6724). See https://man7.org/linux/man-pages/man3/getaddrinfo.3.htmlThis new DNS resolution dynamically based on available addresses could be configuration flagged to allow the old behaviour (fixed prefrence of IPv4) to continue to be an option.