Hi. I have put in a request to join the group, and have detailed a fix
for IPv6 DNS via implementation of RFC 6724 destination address
selection (tested in the ESP-IDF project,
https://github.com/espressif/esp-lwip/pull/66), but have had no
response yet.
I would like to be able to contribute this fix upstream, so if anyone
could help me arrange what is needed to be done that would be great
thanks. I can be contacted at sly@gamertheory.net.
Thanks,
Sly
On 29/3/24 13:42, Sly Gryphon wrote:
Hi,
Looking around some more, I have found a form on savanna.nongnu to
request membership of the group, which I think will allow me to
submit a patch / pull request for evaluation.
I have submitted the request. Please review and approve, so that I
can submit a patch with my suggested implementation of RFC 6724
destination address selection for review.
Thanks,
Sly Gryphon
On 13/3/24 22:18, Sly Gryphon wrote:
Hi,
I have been working on IPv6 in ESP32 Arduino, which led back to
ESP-IDF, and then some changes in ESP-LWIP.
As ESP-LWIP is based on LWIP, I thought it would be best to
contribute those changes upstream, as they will benefit/apply to all
users of LWIP.
The problem was certain specific scenarios don't work, e.g. with
both protocols enabled, looking up a dual-stack server from an IPv6
only network, doesn't work.
The client has IPv6 enabled, the network supports IPv6, and the
destination supports IPv6, but DNS lookup gives the wrong result.
If you don't have IPv4 enabled, then it works fine; i.e. enabling
IPv4 breaks the IPv6 scenario.
An example of the problem (ESP-IDF example) is detailed here:
https://github.com/espressif/esp-idf/issues/13255
Ultimately it came down to the current static ordering of IPv4 vs
IPv6 in LWIP DNS. (Changing the static ordering would have the same
problem in reverse.)
So, I have a working solution, using RFC 6724 destination address
selection, which dynamically selects which destination address to
use based on available source addresses. i.e. if an IPv6 global
scope address (and not IPv4) is available it will return IPv6 and
vice-versa. Posix/linux getaddrinfo() has a similar sorting
documented (RFC 6724 replaces RFC 3484):
https://man7.org/linux/man-pages/man3/getaddrinfo.3.html
So rather than a static order it has dynamic ordering. I put the
changes behind an option flag so that the old behaviour can be
preserved. The functions are also written in such a way that we
could easily add a hook to replace the default ordering if we want
to add that. The current code knows you currently only get one
result from DNS lookup, so maximum of 2 (one IPv6, one IPv4), so is
simplified for that case, but could be extended in the future to
compare multiple and keep the best (or even sort results).
Note that RFC 6724 _source_ address selection is already implemented
in `ip6_select_source_address()` in `ip6.c`; this code implementing
destination address selection.
Proposed implementation of RFC 6724 destination address selection
(this is what I would like to contribute):
https://github.com/espressif/esp-lwip/pull/66
I am not sure how to raise a pull request against upstream LWIP.
Sly Gryphon
_______________________________________________
lwip-devel mailing list
lwip-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
_______________________________________________
lwip-devel mailing list
lwip-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
_______________________________________________
lwip-devel mailing list
lwip-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-devel
OpenPGP_0xAF30477A37423572.asc