[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: shim6 and bit errors in data packet headers

Greg Daley wrote:

In some circumstances, there may be a port unreachable response before
the checksum is even consulted (UDP-Lite).

If that's the case it sounds like a bug in UDP-Lite. UDP-lite can verify the checksum (which only covers part of the payload unlike UDP), before it generates the ICMP error.


I believe that there's a chance of additional responding port
unreachables or resets for flows which match but do not have upper layer
sessions for the flow (since it is tied to different IP addresses).

There is a small probability, but not qualitatively different than for IPv6 itself. For this to happen the bit error would have to be such that the resulting packet is ok according to the TCP/UDP/ICMP checksum.

When this low probability even happens in IPv4 or IPv6 today, the result is quite unpredictable. Could cause undetected data corruption in the application payload.

I don't think the indirection via the shim (which would change the locators to ULIDs for the incorrectly matched context) changes much in terms of the probability.


But B probably shouldn't do any more than this, since it doesn't know whether
the cause was a bit error or it having lost/discarded the shim6 state. 


Loss of shim state is possible if a signaling packet gets lost or
reordered.  We don't necessarily want to tell the source that there's
a problem if the next packet is a signaling packet retry.

But we also get loss of state when B has rebooted, and lost all state.
In this case B would be unable to deliver any higher-level error (TCP reset, UDP port unreachable) until it either has reacquired the shim state, or convinced A to send using the ULIDs as locators (so no receive side address field replacement is necessary).

   Erik