Thanks, this is all helpful.
But let me rephrase the question in hope to get a bit more quantifiable answer:
- can some share user experience (broken apps) when traffic with zero UDP 
checksum is dropped?

The available options when translating*/tunneling IPv4 UDP packet with 
zero-checksum into IPv6:
1) drop IPv4 packets with zero UDP checksum, RFC 6145, section 4.5, point 1
2) recalculate UDP checksum in IPv6 packet from scratch RFC 6145, section 4.5, 
point 2   (calculating UDP checksum from scratch is different that updating is 
according to RFC 1624 - this would be the case if IPv4 packet would have 
non-zero checksum)
3) perform translation or encapsulation into IPv6 and leave zero-checksum (UDP) 
 in IPv6 . This is in violation of RFC 2460, but RFCs 6935 and 6936 alleviate 
the restriction from RFC 2460 .

Anyone can share experience in terms of broken apps in cases 1 and 3?

*options above apply to tunnels but I see no reason why would they not apply to 
translations as well (v4->v6)
Thanks.
  

-----Original Message-----
From: EXT Tom Herbert [mailto:[email protected]] 
Sent: Thursday, March 10, 2016 3:45 PM
To: Fred Baker (fred)
Cc: Poscic, Kristian (Nokia - US); [email protected]; [email protected]; 
[email protected]; [email protected]
Subject: Re: [Int-area] UDP zero-checksum in IPv4

On Thu, Mar 10, 2016 at 1:46 PM, Fred Baker (fred) <[email protected]> wrote:
>
>> On Mar 10, 2016, at 9:29 AM, Poscic, Kristian (Nokia - US) 
>> <[email protected]> wrote:
>>
>> Hi,
>>
>> Does anyone have any info on the percentage of UDP packets with 
>> zero-checksum for IPv4 packets in today’s networks (enterprise, internet, 
>> any network).
>> Seems like there is not a whole lot of info about this on the WEB. Anyone 
>> has any firsthand/realworld experience with this? Thanks.
>>
>> Kris
>
> A good place to start might be https://tools.ietf.org/html/rfc6936
> 6936 Applicability Statement for the Use of IPv6 UDP Datagrams with Zero
>      Checksums. G. Fairhurst, M. Westerlund. April 2013. (Format:
>      TXT=99557 bytes) (Status: PROPOSED STANDARD) (DOI: 
> 10.17487/RFC6936)
>
> The big consideration there is a middleware device (usually a router, but 
> potentially something else) that is receiving packets at line rate one a set 
> of interfaces and funneling them to another interface on which it is 
> obligated to send them tunneled in UDP packets, or a corollary device at the 
> other end of the tunnel. It would be theoretically possible to add hardware 
> that could parse to the correct point and calculate the checksum while the 
> data being received was stored into memory. However, practically, that is far 
> more likely to be done as a second step, to packets it is applicable to. The 
> configuration of a tunnel that creates or verifies a UDP checksum on a 
> tunneled datagram, in such a case, is essentially a DOS vector.
>
Note that this problem is mostly specific to switches that lack HW to 
efficiently perform checksum. On the host side, we have long standing support 
in NIC HW to to perform checksum offload (whether UDP sends zero checksum in 
IPv6, checksums are always used in TCP so we need a host solution regardless!). 
Due to the capabilities of currently deployed NICs, we get much better 
performance with the UDP checksum enabled for tunnels when sourcing or 
terminating tunnels on the same host that sends or receive an encapsulated TCP 
packet-- in fact the default was recently changed in Linux to enable checksum 
for UDP tunnels (it can still be disabled by per tunnel configuration).

Tom

> Any discussion of "percentages of traffic for which X is true in the 
> Internet" are necessarily vague and hand-wavy. The Internet is the proverbial 
> elephant, and those that would statistically describe it are the proverbial 
> philosophers. How one describes it has a lot to do with what part of it one 
> touches.
>
> _______________________________________________
> Int-area mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/int-area
>
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to