All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej Żenczykowski" <zenczykowski@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: Linux NetDev <netdev@vger.kernel.org>,
	Eric Dumazet <edumazet@google.com>,
	Willem de Bruijn <willemb@google.com>,
	Xin Long <lucien.xin@gmail.com>,
	Hannes Frederic Sowa <hannes@stressinduktion.org>
Subject: Re: [PATCH] Revert "ipv6: add mtu lock check in __ip6_rt_update_pmtu"
Date: Tue, 5 May 2020 16:19:45 -0700	[thread overview]
Message-ID: <CAHo-Oow8n8JXaoY-P9Bjb9gG0cHwkwf+E4m_eWX1Tf6k4+2jPg@mail.gmail.com> (raw)
In-Reply-To: <20200505.150951.1869532656064502918.davem@davemloft.net>

> It's local system policy, how do I react to packets.  If it doesn't
> violate the min/max limits for ipv6 packets it emits onto the internet
> I don't see this as something that can be seen as mandatory.

And if you *truly* do want to violate internet standards you can
indeed already achieve this behaviour by dropping incoming icmpv6
packet too big errors (and there's lots of reasons why that is a bad
idea...).

I'll repeat what I said previously: this is a userspace visible
regression in behaviour, of none or very questionable benefit.

It results in TCP over IPv6 simply not working to destinations to
which your locked mtu is higher then the real path mtu.  This is why
'locked mtu' on IPv4 turns of the Don't Fragment bit - to allow
fragmentation at intermediate routers.  There is no such thing in
IPv6.
There is no DF bit, and there is no router fragmentation - all ipv6
fragmentation is supposed to happen at the source host.
This is why hosts must either use 1280 min guaranteed mtu or be
responsive to pmtu errors.  Otherwise things simply don't work.

  reply	other threads:[~2020-05-05 23:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05 18:57 [PATCH] Revert "ipv6: add mtu lock check in __ip6_rt_update_pmtu" Maciej Żenczykowski
2020-05-05 21:23 ` David Miller
2020-05-05 21:56   ` Maciej Żenczykowski
2020-05-05 22:09     ` David Miller
2020-05-05 23:19       ` Maciej Żenczykowski [this message]
2020-05-05 23:26         ` Maciej Żenczykowski
2020-05-08  0:30 ` David Miller
2020-05-08  0:33   ` Maciej Żenczykowski

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=CAHo-Oow8n8JXaoY-P9Bjb9gG0cHwkwf+E4m_eWX1Tf6k4+2jPg@mail.gmail.com \
    --to=zenczykowski@gmail.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hannes@stressinduktion.org \
    --cc=lucien.xin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=willemb@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.