RE: Wrap-up: TCP checksum calculation

["Alvaro Vives" <alvaro.vives@consulintel.es>]

Hi Marcelo,

> 
> this has been an interesting discussion
> 
> Let me see if i can propose a way forward.
> 
> 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.
> 
> Proposed approach:
> 
> First: Add a new section titled "Middle-boxes considerations" with the
> following text.
> 
> It is recommended that firewalls and other middleboxes do not drop TCP,
> UDP and ICMP packets with apparently incorrect checksums based on that
> fact alone unless they implement (monitoring of) the full shim6
> protocol and are able to determine the checksum that must be present in
> a packet with addresses rewritten by shim6."

Wouldn't it be useful to also recommend to the middleboxes sending a packet
back, for example a (new?) ICMP one, to allow the sending host to be aware
of what is happening?

Something like what is done with PMTU discovery. In our case we could have
more than one middlebox. It will also facilitate the network operator work.

> Second: allow the possibility that shim6 nodes can use the locators for
> calculating the TCP/UDP checksum, in case they detect that there is a
> middle box that does not support the shim6 protocol and drops the
> packets that contain the checksum calculated using the ULIDs (which are
> not used a addresses in the IPv6 header). In order to do that, we need
> to use a bit in the shim6 payload header to signal whether the ULIDs or
> the locators are used for the pseudoheader. The bad news is that there
> are no more spare bits in the shim6 payload header. I think this was
> not the best choice, since we haven't finished the spec and we already
> are out of bits.
> My suggestion is that we reduce the context tag to 40 bits and the we
> reserve 8 bits for flags and other information. In the current spec we
> would define two bits. The P flag that is already defined and the L
> flag, which would be set if the Locators are used to calculate the
> tcp/UDP checksum.
> 
> Third: Define a mechanism for detecting the presence of these middle
> boxes. I think that this could be achieved by adding a TCP or UDP
> header in the  I1/R1 exchange, but making sure that the tcp/udp
> checksum is calculated with other than the addresses contained in the
> ipv6 header. One simple option would be to use TCP header and leave the
> checksum filed to 0. If packets are dropped, then the peer should retry
> using a checksum calculated based on the addresses carried in the ipv6
> header. If this works, then it should use the locators for the
> peusoheader and set the L bit in the shim6 payload header.
> 
> Makes sense?


IMHO as we are using SHIM6, in some cases this middlebox behaviour would be
no problem because the SHIM6 REAP will detect that the locator pair have to
change, or am I missing something?

Regards,
Alvaro

> 
> Regards, marcelo
> 
> 
> 





**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.