[lwip-devel] [bug #61230] Improve Dual-Stack support for getaddrinfo, return both IPv4 and IPv6 results

[Simon Kueppers]

URL:
  <https://savannah.nongnu.org/bugs/?61230>

                 Summary: Improve Dual-Stack support for getaddrinfo, return
both IPv4 and IPv6 results
                 Project: lwIP - A Lightweight TCP/IP stack
            Submitted by: skuep2
            Submitted on: Mon 27 Sep 2021 07:37:20 AM UTC
                Category: sockets/netconn
                Severity: 3 - Normal
              Item Group: Change Request
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None
            lwIP version: git head

    _______________________________________________________

Details:

Currently _getaddrinfo_ only returns a single _struct addrinfo_ with either an
IPv4 or IPv6 address (with IPv4 being preferred if _AF_UNSPEC_ is given). This
is true for either server application usage (i.e. _getaddrinfo(NULL, 1234,
IPPROTO_TCP, AI_PASSIVE)_) or client application usage (i.e.
_getaddrinfo("hostname.domain", 1234, IPPROTO_TCP, 0)_).

This behaviour is not entirely correct and prevents some server applications
(such as open62541) from being able to listen on IPv6 addresses, when they use
dedicated sockets for IPv4 and IPv6 connections (using _IPV6_V6ONLY_ on IPv6
sockets). Note that server applications that do not set _IPV6_V6ONLY_ on the
socket and listen on the IPv6 address *only* already work perfectly in a
dual-stack configuration with LWIP.
When running the _getaddrinfo_ function on a Ubuntu based system, the results
are as followed:

python3 -c "import socket; print(socket.getaddrinfo(None, 1234,
proto=socket.IPPROTO_TCP, flags=socket.AI_PASSIVE))"
[
  (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('0.0.0.0',
1234)), 
  (<AddressFamily.AF_INET6: 10>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('::',
1234, 0, 0))
]

This is the intended behaviour and it would be best if LWIP's implementation
of _getaddrinfo_ could be closer to this behaviour.

I propose a two-step approach regarding this bug/feature:

* When using _getaddrinfo_ in server applications (AI_PASSIVE):
_getaddrinfo_ should return both IPv4 and IPv6 listen addresses (e.g.
"0.0.0.0" and "::") to support dual-stack server applications that listen on
each of the returned sockets separately and use _IPV6_V6ONLY_ on the IPv6
socket. 
This should be relatively straight forward to implement. We could add an LWIP
configuration option to explicitly enable this behaviour in order to not break
things for existing applications and stay compatible to the current behaviour
by default.

* When using _getaddrinfo_ as client:
This is probably a bit harder to solve, since we rely on
_netconn_gethostbyname_addrtype_ calling _dns_gethostbyname_ which is only
able to return a single address at once. It may be possible, but wasteful to
run two successive calls to _netconn_gethostbyname_addrtype_ to retrieve both
IPv4 and IPv6 addresses. 
This issue would need to be tackled first, before continuing to implement this
feature in _getaddrinfo_.



In addtion, when returning multiple _struct addrinfo_ entries, the question of
their order arises. I.e. whether the IPv4 or IPv6 address should be returned
first. Since _netconn_gethostbyname_addrtype_ already uses a prioritization
scheme (e.g. _NETCONN_DNS_IPV4_IPV6_) when looking up hostnames via DNS, we
could implement a similar behaviour in case _getaddrinfo_ being called with
_AF_UNSPEC_.
On desktop OSes such as Ubuntu, there is a system-wide gai.conf file that
controls the order of entries returned by _getaddrinfo_.
I am suggesting adding another LWIP configuration option to explicitly set the
priority/order of IPv4/IPv6 addresses returned by the _getaddrinfo_ function
to "emulate" the functionality of gai.conf.




    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?61230>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/