Development discussion of WireGuard
 help / color / mirror / Atom feed
From: Nico Schottelius <nico.schottelius@ungleich.ch>
To: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Roman Mamedov <rm@romanrm.net>, zrm <zrm@trustiosity.com>,
	StarBrilliant <coder@poorlab.com>,
	Baptiste Jonglez <baptiste@bitsofnetworks.org>,
	Joe Holden <jwh@zorins.us>,
	wireguard@lists.zx2c4.com
Subject: Re: potentially disallowing IP fragmentation on wg packets, and handling routing loops better
Date: Sun, 06 Jun 2021 11:32:44 +0200	[thread overview]
Message-ID: <87v96ribib.fsf@ungleich.ch> (raw)
In-Reply-To: <CAHmME9rNnBiNvBstb7MPwK-7AmAN0sOfnhdR=eeLrowWcKxaaQ@mail.gmail.com>


Hello,

so given that fragmentation is disallowed the PMTU discovery always
needs to work and the wireguard MTU needs to be correctly adjusted.

Speaking of a DC situation, I think this might be tricky. Imagine the
following situation:

- endhost A has an MTU of 9k. PMTU 9k. wg 8920.
- the path changes, the PMTU reduces to 1.5k (this is something we see
 happening from time to time)
- How is the wg MTU adjusted in this situation?

And to clarify: with disallowing IP frag, you are obviously only
referring to the outter transport. Within the tunnels, IPv6 and IPv6
packets can still be fragmented, so application operation is not really
affected.

Interesting approach, I am not really sure if realisticly feasible,
especially when thinking about long range/low bandwidth media where
you'd basically say "wg cannot do IPv6 on these mediums". Satelite
systems should probably work fine, I am more concerned about mesh
networks, in which wg is quite popular already.

Cheers,

Nico

--
Sustainable and modern Infrastructures by ungleich.ch

  reply	other threads:[~2021-06-06 10:51 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 [this message]
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
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=87v96ribib.fsf@ungleich.ch \
    --to=nico.schottelius@ungleich.ch \
    --cc=Jason@zx2c4.com \
    --cc=baptiste@bitsofnetworks.org \
    --cc=coder@poorlab.com \
    --cc=jwh@zorins.us \
    --cc=rm@romanrm.net \
    --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).