Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Roman Mamedov <rm@romanrm.net>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: WireGuard mailing list <wireguard@lists.zx2c4.com>,
	zrm <zrm@trustiosity.com>, StarBrilliant <coder@poorlab.com>,
	Baptiste Jonglez <baptiste@bitsofnetworks.org>,
	Joe Holden <jwh@zorins.us>
Subject: Re: potentially disallowing IP fragmentation on wg packets, and handling routing loops better
Date: Mon, 7 Jun 2021 00:03:18 +0500	[thread overview]
Message-ID: <20210607000318.4d36b9cb@natsu> (raw)
In-Reply-To: <CAHmME9rNnBiNvBstb7MPwK-7AmAN0sOfnhdR=eeLrowWcKxaaQ@mail.gmail.com>

On Sun, 6 Jun 2021 11:13:36 +0200
"Jason A. Donenfeld" <Jason@zx2c4.com> wrote:

> Specifically the change would be to not allow IP fragmentation of the
> encrypted UDP packets. This way, in the case of a loop, eventually the
> packet size exceeds MTU, and it gets dropped: dumb and effective.
> Depending on how this discussion goes, a compromise would be to not
> allow fragmentation, but only for forwarded and kernel-generated
> packets, not not for locally generated userspace packets. That's more
> complex and I don't like it as much as just disallowing IP
> fragmentation all together.
> 
> Pros:
> - It solves the routing loop problem very simply.

Doesn't TTL already solve this?

> - Maybe people are running
> wireguard-over-gre-over-vxlan-over-l2tp-over-pppoe-over-god-knows-what-else,
> and this reduces the MTU to below 1280, yet they still want to put
> IPv6 through wireguard, and are willing to accept the performance
> implications.

Not only that. Sometimes transparent bridging of 1500 MTU LANs is required.

VXLAN does not allow tunnel endpoints to produce fragmented VXLAN packets.

With WG we can fragment them one level lower, *and* gain a higher efficiency
compared to hypothetical VXLAN's fragmentation, due to less header overhead on
2nd and further packets in a chain.

It would be unfortunate if this will become no longer possible.

It appears to me that people who might need to transparently join multiple
Ethernet LANs due to legacy network topologies they have to work with, weird
requirements, various legacy software etc, would outnumber those who even run
WG over WG at all, let alone getting themselves into a routing loop that way.

-- 
With respect,
Roman

  parent reply	other threads:[~2021-06-06 19:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-06  9:13 Jason A. Donenfeld
2021-06-06  9:32 ` Nico Schottelius
2021-06-06 10:39 ` Vasili Pupkin
2021-06-06 11:14 ` Peter Linder
2021-06-07 11:58   ` Derek Fawcus
2021-06-06 19:03 ` Roman Mamedov [this message]
2021-06-06 22:33   ` Joe Holden
2021-06-07  9:34 ` Jason A. Donenfeld
2021-06-07 11:13   ` Roman Mamedov
2021-06-07 11:27     ` Jason A. Donenfeld
2021-06-07 11:46       ` Roman Mamedov
2021-06-07 11:55         ` Peter Linder
2021-06-07 18:50         ` Roman Mamedov
2021-06-07 11:18   ` Nico Schottelius
2021-06-09 23:26   ` Vasili Pupkin

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20210607000318.4d36b9cb@natsu \
    --to=rm@romanrm.net \
    --cc=Jason@zx2c4.com \
    --cc=baptiste@bitsofnetworks.org \
    --cc=coder@poorlab.com \
    --cc=jwh@zorins.us \
    --cc=wireguard@lists.zx2c4.com \
    --cc=zrm@trustiosity.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).