Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Nathaniel Filardo <>
To: "Daniel Gröber" <>
Subject: Re: IPv6-only flag set on v6 sockets prevents the use of v4-mapped addresses
Date: Sat, 19 Aug 2023 17:34:00 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Daniel,

DNS absolutely can and does store and return those addresses; look at for an example (AAAA ::ffff:
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.


On Sat, Aug 19, 2023 at 8:22 AM Daniel Gröber <> 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

  reply	other threads:[~2023-08-19 16:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-22  6:48 Nathaniel Filardo
2023-08-19  7:22 ` Daniel Gröber
2023-08-19 16:34   ` Nathaniel Filardo [this message]
2023-08-19 19:16     ` Daniel Gröber

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).