On Tue, Feb 16, 2016 at 11:47 AM, David Miller <da...@davemloft.net> wrote: > From: Jesse Gross <je...@kernel.org> > Date: Tue, 16 Feb 2016 10:22:38 -0800 > >> On Thu, Feb 11, 2016 at 2:41 AM, Jiri Benc <jb...@redhat.com> wrote: >> There's a bigger problem here, not really related to lightweight tunnels or >> OVS. >> >> The VXLAN RFC says (referring to the UDP checksum and not specific to >> IPv4/v6): >> "It SHOULD be transmitted as zero. When a packet is received with a >> UDP checksum of zero, it MUST be accepted for decapsulation." >> >> We can debate whether this is correct or whether it conflicts with RFC >> 2460 but this is what essentially everyone is going to implement. With >> the default settings of the flags in IPv6, we are violating both >> statements. With the second one in particular, the result is that >> Linux will not be able to communicate with any non-Linux VXLAN >> endpoint over IPv6 with default settings. > > I do not see any such conflict here. > > It's a SHOULD, therefore a recommendation. Likely they thought this > would improve performance, and ironically it has the opposite effect. > > The text of the VXLAN RFC does not say that the checksum MUST be sent > as zero, and it also does not say that receiving a non-zero checksum > is violating the RFC. > > I therefore do not see the interoperability issue. Maybe some > deployed systems will run more slowly or hit a slot path (which is not > our problem), but they absolutely should not drop such frames.
"When a packet is received with a UDP checksum of zero, it MUST be accepted for decapsulation." This is a requirement and directly in conflict with having VXLAN_F_UDP_ZERO_CSUM6_RX set to false as the default. As far as the use of checksums, saying that it improves performance is only valid for a class of devices. It is not true as a blanket statement, such as for switching ASICs. In these cases, the performance drop in hitting a slow path is so big that it is equivalent to dropping frames and creates a de-facto interoperability issue.
