IPv6-only flag set on v6 sockets prevents the use of v4-mapped addresses

IPv6-only flag set on v6 sockets prevents the use of v4-mapped addresses

[Nathaniel Filardo]

Hello wireguard@,

I recently found out that in-Linux wireguard has, since its inception,
set its v6 sockets to v6-only
(https://github.com/torvalds/linux/blob/e7096c131e5161fa3b8e52a650d7719d2857adfd/drivers/net/wireguard/socket.c#L381)
and it keys only off the address family  to decide which socket to use
(https://github.com/torvalds/linux/blob/e7096c131e5161fa3b8e52a650d7719d2857adfd/drivers/net/wireguard/socket.c#L188).
This means that v4-mapped v6 addresses (::ffff:a.b.c.d) can be
registered as peer endpoints, but the kernel very silently won't try
to reach out.  Is that deliberate for some reason that eludes me?  If
it is, could the userspace tooling be educated about v4-mapped
addresses and translate them accordingly before handing them up to the
kernel; if it isn't, could we drop the v6-only flag on the kernel
socket?

Thanks for any input,
--nwf;

Re: IPv6-only flag set on v6 sockets prevents the use of v4-mapped addresses

[Daniel Gröber]

Hi Nathaniel,

On Mon, May 22, 2023 at 07:48:04AM +0100, Nathaniel Filardo wrote:
> This means that v4-mapped v6 addresses (::ffff:a.b.c.d) can be
> registered as peer endpoints, but the kernel very silently won't try
> to reach out.  Is that deliberate for some reason that eludes me?  If
> it is, could the userspace tooling be educated about v4-mapped
> addresses and translate them accordingly before handing them up to the
> kernel; if it isn't, could we drop the v6-only flag on the kernel
> socket?

Since I recently sent some patches touching the socket binding code I'm
worndering what the exact use case is here? DNS will never return these
addressess, I've only ever seen them used (internally to programs) when the
kernel returns them in non-v6only sockets. Is there some other context
these get returned in I'm missing?

I considered dropping the v6only flag for the new bind-to-address code path
I introduced but couldn't convince myself that there really is a good
reason to deviate from established wg behaviour here.

--Daniel

Re: IPv6-only flag set on v6 sockets prevents the use of v4-mapped addresses

[Nathaniel Filardo]

Hi Daniel,

DNS absolutely can and does store and return those addresses; look at
mapped46.test.ietfng.org for an example (AAAA ::ffff:1.2.3.4).
In my use case they arise because I have scripts that take wireguard
peer addresses and register them with my DNS service provider, and
it's simpler to update a single AAAA record per peer regardless of
address family than it is to switch between having an AAAA and A
record for the name.

At the very least, the radio silence after the kernel accepts a
v4-mapped v6 address is unexpected behavior.
More generally, I don't see what good setting the v6only flag here is
doing (in fact, that's true in general; there are very few
circumstances, and most of those are for *listening* sockets, where
v6only seems remotely sensible; the v4 to v6 migration is such a
mess), so "the established wg behavior" makes no sense to me.
(It's also plausibly true that I'm the first to *notice* this aspect
of the established behavior!)

In any case, in decreasing order of preference, I'd suggest:
1. Drop the v6only flag on peer sockets and allow the kernel speak to
v4-mapped v6 addresses.
2. I missed something and v6only does serve a purpose; add special
handling for v4-mapped v6 addresses to the wg kernel interface,
bending them into v4 sockaddrs internally.
3. For some reason 2 isn't acceptable either, so add special handling
to the wg userspace tools and do the transmogrification there.
4. For some reason none of that is tolerable, so have the kernel
reject v4-mapped v6 addresses rather than silently accept them and
fail to speak.

Cheers,
--nwf;

On Sat, Aug 19, 2023 at 8:22 AM Daniel Gröber <dxld@darkboxed.org> wrote:
>
> Hi Nathaniel,
>
> On Mon, May 22, 2023 at 07:48:04AM +0100, Nathaniel Filardo wrote:
> > This means that v4-mapped v6 addresses (::ffff:a.b.c.d) can be
> > registered as peer endpoints, but the kernel very silently won't try
> > to reach out.  Is that deliberate for some reason that eludes me?  If
> > it is, could the userspace tooling be educated about v4-mapped
> > addresses and translate them accordingly before handing them up to the
> > kernel; if it isn't, could we drop the v6-only flag on the kernel
> > socket?
>
> Since I recently sent some patches touching the socket binding code I'm
> worndering what the exact use case is here? DNS will never return these
> addressess, I've only ever seen them used (internally to programs) when the
> kernel returns them in non-v6only sockets. Is there some other context
> these get returned in I'm missing?
>
> I considered dropping the v6only flag for the new bind-to-address code path
> I introduced but couldn't convince myself that there really is a good
> reason to deviate from established wg behaviour here.
>
> --Daniel

Re: IPv6-only flag set on v6 sockets prevents the use of v4-mapped addresses

[Daniel Gröber]

Hi Nathaniel,

On Sat, Aug 19, 2023 at 05:34:00PM +0100, Nathaniel Filardo wrote:
> DNS absolutely can and does

I mean I can (and used to) enter fe80::/64 link local addressess into DNS
but it turns out this is actually forbidden by the RFCs but nothing will
stop you. I'm not convinced putting ::ffff: into DNS is a legitimate
use-case given that it it entirely up to an application whether it uses the
IPV6_V6ONLY socket option or dual-stack sockets instead as you've
noticed. This is supported by my reading of RFC4038.

I checked RFC4291/5156 for mentions of how IPv4-mapped v6 addresses are to
be treated but they don't mention any restrictions. So I guess it's up to
us to decide whether it's a legitimate use-case or not. Unless anyone else
has a reference to the contrary?

> In my use case they arise because I have scripts that take wireguard peer
> addresses and register them with my DNS service provider, and it's
> simpler to update a single AAAA record per peer regardless of address
> family than it is to switch between having an AAAA and A record for the
> name.
> 
> At the very least, the radio silence after the kernel accepts a
> v4-mapped v6 address is unexpected behavior.

Not really, in networking traffic black holes are pretty common. I'd expect
the ::ffff:0.0.0.0/96 traffic to get sent via the default route and being
filtered somewhere. Expected behaviour, some people might want to use
::ffff:0.0.0.0/96 as their NAT64 prefix for example. Though that might be
ill advised when a standardized local prefix exists ;)

> More generally, I don't see what good setting the v6only flag here is
> doing (in fact, that's true in general; there are very few
> circumstances, and most of those are for *listening* sockets, where
> v6only seems remotely sensible; the v4 to v6 migration is such a
> mess), so "the established wg behavior" makes no sense to me.

What you're probably not seeing is that there's a technical reason wg
doesn't use a single socket: The code currently supports CONFIG_IPV6 not
being set, so then it can't rely on being able to create a v6 socket! The
way it's written it's just easier to have two sockets and not switch
between v4-only and v6-mapped sockets.

I'm a IPv6-only-or-bust kind of guy so IMO we should just mandate
CONFIG_IPV6 and get rid of a whole bunch of legacy IPv4 code (yey), but
eh. someones probably going to complain about code-size for their v4-only
legacy use-case then :]

> (It's also plausibly true that I'm the first to *notice* this aspect
> of the established behavior!)

You're not, I noticed too when I was working-around the lack of the
AddressFamily= option with a PostUp= script using `getent ahostsv6` and
while the additional `| sed -n '/^::ffff:/d;s/\s*DGRAM.*$//p'` pushed the
PostUp= line over 80 characters I don't consider it an overly onerous
requirement :)

> In any case, in decreasing order of preference, I'd suggest:
> 1. Drop the v6only flag on peer sockets and allow the kernel speak to
> v4-mapped v6 addresses.
> 2. I missed something and v6only does serve a purpose; add special
> handling for v4-mapped v6 addresses to the wg kernel interface,
> bending them into v4 sockaddrs internally.
> 3. For some reason 2 isn't acceptable either, so add special handling
> to the wg userspace tools and do the transmogrification there.
> 4. For some reason none of that is tolerable, so have the kernel
> reject v4-mapped v6 addresses rather than silently accept them and
> fail to speak.

I don't like any of those. The way I see it your DynDNS approach is broken
please use the appropriate rrtype for each address-family. Note my opinion
is not authoritive here, Jason likely has the final say or, recently, more
likely lack of say ;)

In userspace we ask getaddrinfo() not to return v4-mapped addressess by
having AI_V4MAPPED unset, unfortunately this doesn't work when you enter
those addresses into DNS (a libc bug perhaps? *hint* *hint*). I would
suggest filtering them on our side if they get returned anyway and emitting
a warning so this is less of a stumbling block for the next poor soul.

I do wonder what the behavoir of the other wg implementations is on this
point, if it's inconsistent with the kernel impl. that's even more reason
to warn about it.

--Daniel