Recently I was following issue #17380 [0] "No router advertisements sent out over wireguard link" which resulted in PR #21692 [1] "network: wireguard: allow to start ndisc or radv".

Shortly after the issue was closed Jason Donenfeld (alias zx2c4 - author of Wireguard) added a comment [2]:

"Please revert this. WireGuard does not work with LLv6 by design."

As a strong proponent and designer/developer/operator of IPv6-only networks and services I was unpleasantly surprised by this comment since we rely on IPv6 link-local functionality and also use Wireguard extensively including with link-local addresses and try to ensure everything we deploy is conformant with industry standards to ensure inter-operability.

I thought I may have misunderstood the IPv6 standards from RFC4291 "IP Version 6 Addressing Architecture" section 2.1 "Addressing Model" [3] which says:

"All interfaces are required to have at least one Link-Local unicast address (see Section 2.8 for additional required addresses)."

After mentioning this in the issue zx2c4 replied with:

"I'm aware of that text. It doesn't change the fact that this isn't how WireGuard works."

In my mind point-to-point tunnels like Wireguard are closely aligned with link-local addressing so this was somewhat of a surprise!

Which leaves us with a dilemma - if we can't rely on standard IPv6 link-local behaviour on Wireguard links what similar tunnelling options should we consider? I did recently reconsider IPSec since it was originally designed as part of IPv6 although ended up being an optional extra and can be much more complex to manage.

What alternatives would the Linux-focused network professionals recommend ?

[0] https://github.com/systemd/systemd/issues/17380

[1] https://github.com/systemd/systemd/pull/21692

[2] https://github.com/systemd/systemd/issues/17380#issuecomment-1008323004

[3] https://datatracker.ietf.org/doc/html/rfc4291#section-2.1