From: Steffen Klassert <steffen.klassert@secunet.com>
To: mtk81216 <lina.wang@mediatek.com>
Cc: "David S . Miller" <davem@davemloft.net>,
Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>,
Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
"Jakub Kicinski" <kuba@kernel.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Matthias Brugger <matthias.bgg@gmail.com>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mediatek@lists.infradead.org>
Subject: Re: [PATCH] xfrm:fragmented ipv4 tunnel packets in inner interface
Date: Tue, 15 Sep 2020 09:30:06 +0200 [thread overview]
Message-ID: <20200915073006.GR20687@gauss3.secunet.de> (raw)
In-Reply-To: <20200909062613.18604-1-lina.wang@mediatek.com>
On Wed, Sep 09, 2020 at 02:26:13PM +0800, mtk81216 wrote:
> In esp's tunnel mode,if inner interface is ipv4,outer is ipv4,one big
> packet which travels through tunnel will be fragmented with outer
> interface's mtu,peer server will remove tunnelled esp header and assemble
> them in big packet.After forwarding such packet to next endpoint,it will
> be dropped because of exceeding mtu or be returned ICMP(packet-too-big).
What is the exact case where packets are dropped? Given that the packet
was fragmented (and reassembled), I'd assume the DF bit was not set. So
every router along the path is allowed to fragment again if needed.
> When inner interface is ipv4,outer is ipv6,the flag of xfrm state in tunnel
> mode is af-unspec, thing is different.One big packet through tunnel will be
> fragmented with outer interface's mtu minus tunneled header, then two or
> more less fragmented packets will be tunneled and transmitted in outer
> interface,that is what xfrm6_output has done. If peer server receives such
> packets, it will forward successfully to next because length is valid.
>
> This patch has followed up xfrm6_output's logic,which includes two changes,
> one is choosing suitable mtu value which considering innner/outer
> interface's mtu and dst path, the other is if packet is too big, calling
> ip_fragment first,then tunnelling fragmented packets in outer interface and
> transmitting finally.
>
> Signed-off-by: mtk81216 <lina.wang@mediatek.com>
Please use your real name to sign off.
next parent reply other threads:[~2020-09-15 7:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200909062613.18604-1-lina.wang@mediatek.com>
2020-09-15 7:30 ` Steffen Klassert [this message]
[not found] ` <1600160722.5295.15.camel@mbjsdccf07>
[not found] ` <20200915093230.GS20687@gauss3.secunet.de>
[not found] ` <1600172260.2494.2.camel@mbjsdccf07>
[not found] ` <20200917074637.GV20687@gauss3.secunet.de>
[not found] ` <1600341549.32639.5.camel@mbjsdccf07>
[not found] ` <1604547381.23648.14.camel@mbjsdccf07>
2020-11-05 4:41 ` [PATCH] xfrm:fragmented ipv4 tunnel packets in inner interface Maciej Żenczykowski
2020-11-05 4:52 ` Lorenzo Colitti
2020-11-09 9:58 ` Steffen Klassert
2020-11-09 19:38 ` 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=20200915073006.GR20687@gauss3.secunet.de \
--to=steffen.klassert@secunet.com \
--cc=davem@davemloft.net \
--cc=herbert@gondor.apana.org.au \
--cc=kuba@kernel.org \
--cc=kuznet@ms2.inr.ac.ru \
--cc=lina.wang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=matthias.bgg@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=yoshfuji@linux-ipv6.org \
/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).