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

inet6 to inet fallback in networks without ipv6 support #8548

Open
ruslandoga opened this issue Jun 5, 2024 · 10 comments
Open

inet6 to inet fallback in networks without ipv6 support #8548

ruslandoga opened this issue Jun 5, 2024 · 10 comments
Assignees
Labels
enhancement team:PS Assigned to OTP team PS

Comments

@ruslandoga
Copy link

ruslandoga commented Jun 5, 2024

👋

Is your feature request related to a problem? Please describe.

Not sure yet. First I'd like double check if gen_tcp:connect and ssl:connect with inet6 option are supposed to fallback to inet when IPv6 connection is not successful. And if it's not supposed to work this way, I'd like to request this feature!

Right now I'm not able to make this sort of fallback work. Here're some examples from Fly.io dual-stack machine and from an IPv4-only container running on AWS EC2. I'm using IPv4-only and IPv6-only hosts from http://dual.tlund.se

From Fly.io Machine
1> inet:getifaddrs().
{ok,[{lo,[{flags,[up,loopback,running]},
             {addr,{127,0,0,1}},
             {netmask,{255,0,0,0}},
             {addr,{0,0,0,0,0,0,0,1}},
             {netmask,{65535,65535,65535,65535,65535,65535,65535,65535}},
             {hwaddr,[0,0,0,0,0,0]}]},
     {dummy0,[{flags,[broadcast]},
                {hwaddr,[150,232,97,230,238,118]}]},
     {eth0,[{flags,[up,broadcast,running,multicast]},
              {addr,{172,19,136,2}},
              {netmask,{255,255,255,248}},
              {broadaddr,{172,19,136,7}},
              {addr,{172,19,136,3}},
              {netmask,{255,255,255,248}},
              {broadaddr,{172,19,136,7}},
              {addr,{9733,19520,344,51602,0,62017,27426,1}},
              {netmask,{65535,65535,65535,65535,65535,65535,65535,65534}},
              {addr,{64938,0,24663,2683,129,62017,27426,2}},
              {netmask,{65535,65535,65535,65535,65535,65535,65535,0}},
              {addr,{65152,0,0,0,56493,55039,65078,12685}},
              {netmask,{65535,65535,65535,65535,0,0,0,0}},
              {hwaddr,[222,173,214,54,49,141]}]},
     {teql0,[{flags,[]}]}
    ]}.

Connecting to IPv4-Only Host works with default inet option

2> {ok, Socket} = gen_tcp:connect("ipv4.tlund.se", 80, [{active, false}]).
3> inet:peername(Socket).
{ok,{{193,15,228,195},80}}.

But fails when inet6 option is provided

4> gen_tcp:connect("ipv4.tlund.se", 80, [inet6, active, false]).
{error,nxdomain}.

ipv6_v6only doesn't Help

5> gen_tcp:connect("ipv4.tlund.se", 80, [inet6, {ipv6_v6only, false}, active, false]).
{error,nxdomain}.

Default options (inet) don't work with IPv6-only host

6> gen_tcp:connect("ipv6.tlund.se", 80, [active, false]).
{error,nxdomain}.

inet6 works with IPv6-only host

7> {ok, Socket} = gen_tcp:connect("ipv6.tlund.se", 80, [inet6, {active, false}]).
8> inet:peername(Socket).
{ok,{{10752,2049,15,0,0,0,0,405},80}}.
From IPv4-only container on AWS EC2
1> inet:getifaddrs().
{ok,[{lo,[{flags,[up,loopback,running]},
             {addr,{127,0,0,1}},
             {netmask,{255,0,0,0}},
             {hwaddr,[0,0,0,0,0,0]}]},
     {eth0,[{flags,[up,broadcast,running,multicast]},
              {addr,{172,24,0,3}},
              {netmask,{255,255,0,0}},
              {broadaddr,{172,24,255,255}},
              {hwaddr,[2,66,172,24,0,3]}]}
    ]}.

No fallback to inet

2> gen_tcp:connect("ipv6.tlund.se", 80, [inet6, {active, false}]).
{error,eaddrnotavail}.

Describe the solution you'd like

inet6 would fallback to inet automatically when needed so that providing inet6 option would always increase the chance of a successful connection.

Describe alternatives you've considered

Some Elixir libraries perform a manual fallback from inet6 to inet like Mint and some other libraries like Postgrex allow a list of endpoints to be provided for connection attempts.

Additional context

Relevant discussion (where this question originated): phoenixframework/phoenix#4289 (comment)

@IngelaAndin IngelaAndin added the team:PS Assigned to OTP team PS label Jun 7, 2024
@wojtekmach
Copy link
Contributor

I believe built-in happy eyeballs implementation would be a huge win for the ecosystem. 👍

@essen
Copy link
Contributor

essen commented Jun 27, 2024

Yes!

@u3s u3s assigned bmk Jul 2, 2024
@bmk
Copy link
Contributor

bmk commented Jul 3, 2024

I believe that the idea is that gen_tcp (and gen_udp, gen_sctp) should be "close to the metal".
And these kinds of features are up to the application.

I my memory is correct the inets (httpd and httpc) had a similar config option (inet6fb4 or something like it).

I do not know if ssl has this feature.

'socket' is very much "close to the metal". But gen_tcp could maybe be considered to be a layer that
should provide this kind of a feature. We will discuss ASAP (vacation times here at OTP central).

@essen
Copy link
Contributor

essen commented Jul 3, 2024

This is the kind of feature that sits between OTP and application I think. It makes sense to have it in OTP because many would use it, but not all network connections require it either. It could be a separate open source project, but then who has the will and the bandwidth to maintain it?

Happy Eyeballs is also tricky in that it pretty much requires connecting via 4/6 concurrently. The socket module's nowait could come in handy there. Try to connect to all then wait for the winner. But once we have the right socket connected, we need to be able to hand it off to gen_tcp or ssl. So OTP changes would be required.

The alternative is building on top of gen_tcp or ssl but that means having concurrent processes and much higher complexity.

If we could "upgrade" a socket socket to gen_tcp / ssl / others, in a documented way, then I believe we wouldn't be far from actually implementing this in a fairly straightforward way.

@ruslandoga
Copy link
Author

ruslandoga commented Jul 3, 2024

It could be a separate open source project, but then who has the will and the bandwidth to maintain it?

FWIW, I started working on https://github.com/ruslandoga/happy_tcp and will be trying to implement Happy Eyeballs by using prim_inet:async_connect but it's quite hacky:

  • collect (sequentially for now) ipv4 and ipv6 addresses, sort them using Happy Eyeballs rules
  • pass them as a list arg to happy_tcp:connect/1
  • use async nature prim_inet:async_connect to do the Happy Eyeballs thing

I haven't looked into socket yet, just gen_tcp with inet backend.

So OTP changes would be required.

So far, happy_tcp seems to work without any changes but it would be nice if inet_tcp_backend "behaviour" could connect to multiple addresses instead of just one, then my hack of passing a list of addresses could go away.

But my ideal would be having inet6_tcp do all this. So that gen_tcp:connect(Domain, Port, [inet6]) "would just work", the way it already works for gen_tcp:listen (which afaik binds on both ipv4 and ipv6 when inet6 option is provided).

@essen
Copy link
Contributor

essen commented Jul 3, 2024

The OTP changes are needed to keep the same interface, i.e. once the connection has succeeded you use gen_tcp or ssl as you normally would. There's no reason to have yet another interface today, other than the fact that we can't upgrade the socket or prim_inet socket to gen_tcp without using undocumented functions. Note that the code exists but it is not a public interface from OTP (same goes for prim_inet:async_connect).

msfstef added a commit to electric-sql/electric that referenced this issue Feb 3, 2025
When `DATABASE_USE_IPV6` is enabled, but the provided DB URL has no
resolvable IPv6 address (no AAAA record), naively fallback to IPv4.

A more general discussion on this fallback behaviour for Erlang's
networking stack can be found here
erlang/otp#8548

Ideally we would be able to handle this sort of fallback directly with
Postgrex, and it used to have the possibility to specify multiple
endpoints with different options that it would try sequentially, but it
is no longer supported.

I have opened an issue to see if there is a potential solution to this
that can be supported by Postgrex directly
elixir-ecto/postgrex#730

Perhaps once we are happy with both IPv6 and IPv4 being supported out of
the box we can remove the `DATABASE_USE_IPV6` option and always default
to supporting it, but I think it's safer to explore this a bit further.
This PR introduces a naive fix that does not cover all possible failure
and fallback cases, but unblocks the basic case of AAAA records missing
while also supporting IPv6.
@ruslandoga
Copy link
Author

ruslandoga commented Feb 6, 2025

👋 everyone :)

I ran into this issue again today. I wonder if it would be OK for me to explore a possible solution and PR it? I would be super honored to contribute at least something to the great OTP!.. And I have a lot of free time these days :)

@flexagoon
Copy link

Sorry if that's a dumb question, but why isn't inet6 on by default? It seems like passing both inet and inet6 allows connection to both ipv4 and ipv6 addresses, so why aren't they both just on by default?

@ruslandoga
Copy link
Author

ruslandoga commented Feb 16, 2025

👋 @flexagoon

It doesn't always work, and making it work well requires algorithms like Happy Eyeballs, not just a naive fallback. Here's a recent post I saw on HN today about some of the possible problems: https://techlog.jenslink.net/posts/ipv6-is-hard/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement team:PS Assigned to OTP team PS
Projects
None yet
Development

No branches or pull requests

7 participants