[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Wrap-up: TCP checksum calculation
> -----Original Message-----
> From: Erik Nordmark [mailto:erik.nordmark@sun.com]
> Sent: Tuesday, March 13, 2007 2:31 PM
> To: marcelo bagnulo braun
> Cc: shim6-wg; Henderson, Thomas R; Brian E Carpenter; Geoff
> Huston; Iljitsch van Beijnum
> Subject: Re: Wrap-up: TCP checksum calculation
>
> marcelo bagnulo braun wrote:
>
> > The problem is that shim6 payload packets that carry
> locators different
> > than ULIDs, will have the checksum calculated based on the
> ULIDs and not
> > on the actual addresses carried in the ipv6 header. This
> would imply
> > that any device in the middle (from NIC to middle boxes
> (firewalls and
> > TCP relays)) will fail the checksum verification (and drop
> the packet).
> > It is possible that TCP checksum verification is more common, since
> > there is no IP checksum in IPv6.
>
> I don't understand what the issue is.
>
> The shim6 packets have a protocol/nexthdr field which is
> shim6 and not
> TCP, UDP, etc.
>
> Thus an unmodified middlebox doesn't see a TCP packet - it
> seems a to it
> unknown IP protocol.
>
> Only if the middlebox is modified to know about shim6 would
> it be able
> to skip the shim6 header to find the TCP, UDP, etc header.
My assumption was that there might be middleboxes capable of skipping
unknown extension headers to find the TCP. The shim6 header has
NxtHdr/Length just like other extension headers. Maybe this assumption
is unrealistic for IPv6-- I don't know.
> And a middlebox which is modified to know about shim6 could be aware
> that the TCP/UDP etc checksums are different when there is a shim6
> payload message before the TCP/UDP header.
>
Yes, I support Marcelo's most recent text proposal.
Tom