VZ FIOS and Intel TCP IPv6 Checksum Offload problems
Niels Bakker
niels=nanog at bakker.net
Mon Aug 29 22:28:32 UTC 2022
* bruns at 2mbit.com (Brie) [Mon 29 Aug 2022, 19:38 CEST]:
>On 8/29/22 10:59 AM, Christopher Morrow wrote:
>>Uhm, this includes various versions of the intel pro 1000 card...
>>so that's a TON of gear, to include like lenovo laptops, for
>>instance. I'd wager that this is super common in the field.
>>The PDF in the download says;
>> "Products Affected: All 1gbe and 10gbe intel ethernet controllers...."
>
>So I keep seeing this being pushed as a problem with clients... but
>isn't it the ONT that is bugged out and appending the extra data
>after the checksum is already there (as Bill Herrin points out)?
>
>I know it's asking a lot to expect networking equipment vendors to
>fix their gear, but...
>
>Unless I'm totally not understanding the bug, which is entirely (and
>likely).
Here's my speculation on what was happening at Casa Sean.
The Ethernet frame has a length header. The IP frame has a length
header. Ideally, the IP frame fits completely into the Ethernet frame,
leaving room for the other required Ethernet bits but nothing more.
I vaguely recall there being some equipment that interpreted the
minimum MTU requirement in IPv6 as meaning that there was a minimum
packet size, not a minimum for the *maximum* packet size. Perhaps the
fiber NTU padded the Ethernet frame up to the minimum MTU, sending
along a bunch of junk bytes, without otherwise touching the IP packet.
The NIC would then perhaps forget that there were a bunch of junk
bytes attached to the end of the frame beyond where the IP packet
would end, and calculate the Ethernet checksum based on the IP packet
length header, discarding otherwise valid frames as a result.
I've had my own run-ins over the years with supposed checksum
offloading absolutely not happening on other brands, so implementation
errors appear to be relatively common.
-- Niels.
More information about the NANOG
mailing list