Hacker News Re-Imagined

WireGuard does not work with LLv6 by design

I follow systemd-networkd development in order to utilise advanced functionality as it lands, as well as proposing or following other issues that provide desirable functionality.

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

  • 4 points
  • 7 days ago

  • @iam-TJ
  • Created a post

WireGuard does not work with LLv6 by design

@tssva 7 days

Replying to @iam-TJ 🎙

There is a mention of WireGuard tunnels being point to point. This is true in that there is an encrypted point to point tunnel between each peer; however, the network model implemented by WireGuard is a non-broadcast multiple access (NBMA) model. Similar to X.25 or framerelay. A network model similar to point to point can be implemented via WireGuard by assigning a single peer to a WireGuard interface and adjusting the allowed ips for that peer to include multicast addresses.

The NBMA model is just one of the obstacles one faces when trying to implement dynamic routing over WireGuard interfaces. Honestly it becomes complicated enough that setting up IPsec properly and securely is much less complicated and error prone.


@wmf 7 days

Replying to @iam-TJ 🎙

If you can, it's probably worth having a longer conversation with Jason beyond one-liners about what WireGuard's philosophy is and why it's not compatible with link-local addressing. He may be too busy though.

I've thought about using Noise to negotiate session keys and creating ESP SAs from them but I don't know if that would get you canceled.


About Us

site design / logo © 2022 Box Piper