IPV6_RECVPKTINFO not working for IPv4-mapped addresses on Linux?

[Hannes Frederic Sowa]

On Mon, Jan 20, 2014 at 01:20:08PM +0100, Tore Anderson wrote:
> * Hannes Frederic Sowa
> 
> > In its current form, not so good. If you can tell me specific software
> > that *breaks*, I can ask. At first I thought I might be able to just
> > switch an 'if' but the patch got a bit more complex.
> 
> What breaks is OpenVPN servers listening on an UDP IPv6 socket with
> IPV6_V6ONLY=0. If an IPv4 client attempts to set up a tunnel to a
> non-primary address of the server (for example in the case of a server
> with multiple interfaces or dedicated service OpenVPN service
> addresses), the OpenVPN process fails to use the address it was
> contacted on when replying to the client, instead using the default IPv4
> source address of the system. This in turn leads to the tunnel failing
> to establish.
> 
> See: https://community.openvpn.net/openvpn/ticket/306

Ok, I see.

The patch is pretty big for stable submission and does not fix a real
kernel bug, I fear. I have some doubt if it is a valid stable submission.

Maybe Gert can evaluate if this can easily be fixed in OpenVPN and if yes,
how fast they could push out an update. Maybe we can solve this just from
the OpenVPN side (with ipv4 PKT_INFO). Networking stable submissions
need their time, too, as they have to take an extra hop to the stable
queue. So it would be available at the earliest in 2-3 weeks.

> FWIW: So far the "solution" has been to simply keep the UDP server
> IPv4-only, which works fine since with current versions of OpenVPN you
> have to explicitly ask for IPv6 to be used, which nobody (except I)
> does. However when OpenVPN 2.4 gets released the client will start using
> standard getaddrinfo() and thus prefer IPv6 when available, and then
> having no process listening on IPv6 in the server end becomes a real
> problem - nobody likes timeouts...
> 
> > Maybe the workaround with IPv4 PKT_INFO does help for the time being.
> 
> Probably, although I'm guessing Gert would rather not go there when your
> more proper fix is right around the corner. No worries, I'll look into
> backporting the patch to the kernel I'm currently running or upgrading
> to 3.14 once it's released. Thanks again!

Actually this would be my preferred solution. Also note, that lot's of systems
don't get their kernels updated *ever*. I sometimes evaluate that via IPv4
packet changes from kernel version to version. ;)

Let me know if you have problems with backporting. ;)

Greetings,

  Hannes