Fred,
About the Ethernet CRC, I would be happy if we left the IEEE standards
> alone to continue to
>
> do the CRC calculations as they have always done as long as there is a way
> to get the receiver
>
> to deliver packets that contain FEC errors to IP instead of dropping them
> unconditionally.
Thanks Andy, MD5 would not be used for security purposes – only as an integrity
check – but I am
planning to move away from it anyway based on the previous discussion. The
document will instead
define its own CRC128 algorithm.
Fred
From: Andrew G. Malis
Sent: Monday, November 13, 2023 3:31 PM
Tom, the IP parcel / advanced jumbo header checksum is on the same order of
complexity as the
IPv4 header checksum and covers a similar amount of header data – the checksum
does not run
over the entire length of the parcel/jumbo. Routers that accept IP parcels and
advanced jumbos
would need to v
Hi Roland,
The outcome of this discussion is that the only change I would ask for links
that support
IP parcels and advanced jumbos is for the far end of the link to deliver frames
with CRC
errors to higher layers (along with a "CRC error" flag, of course). The link
would still run
the CRC func
That is a useful link, Andy – thank you for that.
Fred
From: Andrew G. Malis
Sent: Tuesday, November 14, 2023 4:08 AM
To: Templin (US), Fred L
Cc: Tom Herbert ; int-area
Subject: Re: [Int-area] [EXTERNAL] Re: A new link service model for the
Internet (IP Parcels and Advanced Jumbos)
EXT ema
Tom, thinking more about this IPv6 does not verify header checksums at every
hop – only at the
final destination. So, how would it be if we simply made header checksum
verification a SHOULD
at intermediate hops but a MUST at the final destination?
Thanks - Fred
From: Int-area On Behalf Of Temp
On Tue, Nov 14, 2023 at 8:11 AM Templin (US), Fred L
wrote:
>
> Tom, thinking more about this IPv6 does not verify header checksums at every
> hop – only at the
>
> final destination. So, how would it be if we simply made header checksum
> verification a SHOULD
>
> at intermediate hops but a MUS
Tom, for IP parcels and advanced jumbos, the {TCP, UDP} checksums cover only
the pseudo-header
of the IP header followed by the fields of the {TCP, UDP} header itself; the
checksum does not extend
to cover the parcel/jumbo body. In this way, it is very much like the IPv4
header checksum and cove
On Tue, Nov 14, 2023 at 10:36 AM Templin (US), Fred L
wrote:
>
> Tom, for IP parcels and advanced jumbos, the {TCP, UDP} checksums cover only
> the pseudo-header
> of the IP header followed by the fields of the {TCP, UDP} header itself; the
> checksum does not extend
> to cover the parcel/jumbo
Tom, the checksum value gets written into the TCP or UDP header checksum field,
so if it did not
cover the TCP/UDP header fields in addition to the IP pseudo-header then there
would be nowhere
to place an integrity check for the transport layer port numbers.
It is a good point that checking inte
On Tue, Nov 14, 2023 at 11:51 AM Templin (US), Fred L
wrote:
>
> Tom, the checksum value gets written into the TCP or UDP header checksum
> field, so if it did not
> cover the TCP/UDP header fields in addition to the IP pseudo-header then
> there would be nowhere
> to place an integrity check fo
Tom, what it means is that for IP parcels and advanced jumbos the rule for
calculating the TCP and
UDP checksums is different. The rule is that the {TCP,UDP} checksum is
calculated over the headers
only while pretending that the payload following the headers is 0 octets.
Meanwhile, each segment
On Tue, Nov 14, 2023 at 12:17 PM Templin (US), Fred L
wrote:
>
> Tom, what it means is that for IP parcels and advanced jumbos the rule for
> calculating the TCP and
> UDP checksums is different.
Fred,
Repurposing the TCP and UDP checksum fields is going to get a lot of
pushback and is probably
Tom, RFC2675 was able to set different requirements for UDP checksums for
classic jumbograms;
using that precedent, why can't we set different requirements for IP parcels
and advanced jumbos?
I get what you are saying about tucking a checksum into an IP option/extension
header field. But,
the p
On Tue, Nov 14, 2023 at 1:33 PM Templin (US), Fred L
wrote:
>
> Tom, RFC2675 was able to set different requirements for UDP checksums for
> classic jumbograms;
> using that precedent, why can't we set different requirements for IP parcels
> and advanced jumbos?
Fred,
That only changed the requ
Tom, with IP parcels and advanced jumbos I do want to avoid coverage of the
whole transport
layer payload with the {TCP,UDP} checksum. IP parcels in particular can have
their contents
shifted around significantly in-flight so that the original packaging at the
source ends up at
the destination w
16 matches
Mail list logo
