From: Paolo Abeni <pabeni@redhat.com>
To: Jiri Benc <jbenc@redhat.com>
Cc: netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Pravin Shelar <pshelar@nicira.com>, Thomas Graf <tgraf@suug.ch>,
Jesse Gross <jesse@kernel.org>
Subject: Re: [PATCH net-next] lwt: fix rx checksum setting for lwt devices tunneling over ipv6
Date: Thu, 11 Feb 2016 12:38:51 +0100 [thread overview]
Message-ID: <1455190731.4855.50.camel@redhat.com> (raw)
In-Reply-To: <20160211114124.17ae429a@griffin>
On Thu, 2016-02-11 at 11:41 +0100, Jiri Benc wrote:
> On Wed, 10 Feb 2016 16:47:21 +0100, Paolo Abeni wrote:
> > --- a/drivers/net/geneve.c
> > +++ b/drivers/net/geneve.c
> > @@ -1441,7 +1441,8 @@ struct net_device *geneve_dev_create_fb(struct net *net, const char *name,
> > return dev;
> >
> > err = geneve_configure(net, dev, &geneve_remote_unspec,
> > - 0, 0, 0, htons(dst_port), true, 0);
> > + 0, 0, 0, htons(dst_port), true,
> > + GENEVE_F_UDP_ZERO_CSUM6_RX);
> > if (err) {
> > free_netdev(dev);
> > return ERR_PTR(err);
> > diff --git a/net/openvswitch/vport-vxlan.c b/net/openvswitch/vport-vxlan.c
> > index 1605691..d933cb8 100644
> > --- a/net/openvswitch/vport-vxlan.c
> > +++ b/net/openvswitch/vport-vxlan.c
> > @@ -90,7 +90,7 @@ static struct vport *vxlan_tnl_create(const struct vport_parms *parms)
> > int err;
> > struct vxlan_config conf = {
> > .no_share = true,
> > - .flags = VXLAN_F_COLLECT_METADATA,
> > + .flags = VXLAN_F_COLLECT_METADATA | VXLAN_F_UDP_ZERO_CSUM6_RX,
>
> I'm afraid this looks wrong, we should not default to zero UDP checksum
> over IPv6. See RFC 2460, section 8.1:
>
> o Unlike IPv4, when UDP packets are originated by an IPv6 node,
> the UDP checksum is not optional. That is, whenever
> originating a UDP packet, an IPv6 node must compute a UDP
> checksum over the packet and the pseudo-header, and, if that
> computation yields a result of zero, it must be changed to hex
> FFFF for placement in the UDP header. IPv6 receivers must
> discard UDP packets containing a zero checksum, and should log
> the error.
>
> One may argue that with tunneling, the situation is different but
> that's the reason why we have the IPv6 checksum flag and why it has
> opposite meaning to the IPv4 one. We shouldn't default to non-RFC
> behavior by default.
Agreed. As far as I can understand RFC 6936, Section 5 do allows
specific tunneling protocol to accept zero UDP checksum on specific
ports.
We are already sending by default zero UDP checksum when tunneling over
vxlan/geneve light weight tunnel since the commit 35e2d1152b22
("tunnels: Allow IPv6 UDP checksums to be correctly controlled.").
Currently, geneve/vxlan lwt pairs tunneling over ipv6 are not able to
talk each-other with default setting since the sender will set zero UDP
checksum in the external header and the receiver will discard such
packets.
This commit is intended to address the above issue.
Such issue could be addressed also by defaulting all lwt geneve/vxlan
flows (comprising those tunneling over ipv4) to set the external UDP
checksum, but a single lwt tunnel device can be used to terminate flows
with different checksum settings.
Paolo
next prev parent reply other threads:[~2016-02-11 11:38 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-10 15:47 [PATCH net-next] lwt: fix rx checksum setting for lwt devices tunneling over ipv6 Paolo Abeni
2016-02-11 10:41 ` Jiri Benc
2016-02-11 11:12 ` David Miller
2016-02-11 11:38 ` Paolo Abeni [this message]
2016-02-11 12:16 ` Jiri Benc
2016-02-11 12:20 ` Jiri Benc
2016-02-16 18:22 ` Jesse Gross
2016-02-16 19:47 ` David Miller
2016-02-16 20:11 ` Jesse Gross
2016-02-16 20:40 ` David Miller
2016-02-16 20:45 ` David Miller
2016-02-17 17:14 ` Paolo Abeni
[not found] ` <CALx6S34k2Hz-kBeTZ9brLZDCp1tU9nUMZN6V9zhoqmEU3+TR_A@mail.gmail.com>
2016-02-16 20:53 ` David Miller
[not found] ` <CALx6S34AsmKy57msp85o0_Y8KKM_4iQN9Bx=nfsE3gs6RP9t2A@mail.gmail.com>
2016-02-16 21:37 ` David Miller
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=1455190731.4855.50.camel@redhat.com \
--to=pabeni@redhat.com \
--cc=davem@davemloft.net \
--cc=jbenc@redhat.com \
--cc=jesse@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pshelar@nicira.com \
--cc=tgraf@suug.ch \
/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).