Re: shim6 and bit errors in data packet headers

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Erik,

I like the general trend, but I'd like to raise some ideas...

Erik Nordmark wrote:
[cut]
> If there is a bit error in B2 (turning it into B2') the packets wouldn't be
> delivered to the host B, but they might be delivered to a different 
> host, which would presumably(??), not have any context state for <A1, B2', CT>.
> If it does have such shim6 state, it would apply the ULID replacement from
> that context state and pass the packet to the ULP. The ULP checksum 
> would most likely fail in this case.

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

If UDP checks checksums after port occupancy, I guess port-unreachables
could be sent instead of silent discards (don't think this will happen).

> This doesn't seem any different than the case in base IPv6 and a bit error
> in the destination address field; we rely on the ULP checksum to discard 
> such
> packets.
>
> If there is a bit error in A1 or CT, the packet would be delivered to B,
> but most likely B would not have any context state which matches <A1', 
> B2, CT>
> or <A1, B2, CT'>. If there is matching context state, the argument above
> about the ULP checksum applies.
> When there is no matching context state at B, the question is what B
> does in such a case.
>
> This is a function of how we do state management in shim6. There has been
> little discussion about this. We could do soft state, where there is no
> explicit taredown/close message, or we could do something which tries to
> tare down the state at the both ends in a coordinated fashion.
>
> If we assume that we do soft state management, then a host like B needs to
> be prepared to receive shim6 packets where it has no context. This is
> because B might have discarded the shim6 state before A did, or B might
> have crashes and lost all state while A retained the shim6 state.
>
> This implies that in the bit error case above, since B can't tell the
> difference between a bit error and the case when it has lost/discarded
> the state, B needs to at least send an error message to A saying "I have
> no matching shim6 context".

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).

In most cases, any ICMPv6 errors or TCP resets will be sent to a port
which isn't expecting feedback of this sort...

It's worth finding out how important this is, though.
Most errors aren't single bit errors, and we're assuming that there's
a problem just in the context tag.

> 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.
>
> [Note that B can't just silently pass up such packets to the ULP, because
> if B doesn't do the locator->ULID replacement, the packets will (most 
> likely)
> be dropped by the ULP to to a checksum error. Thus there would *not* be 
> e.g.,
> a TCP reset which would tell the peer ULP to restart.]
>
> So in conclusion, if we don't have a checksum for the shim6 context tag, 
> then
> we are constrained on what the shim can do when receiving a packet for
> which it has no matching context.
>
> If we add a checksum (covering at least the source locator, destination
> locator, and context tag), then the receiving shim6 layer can silently 
> discard
> packets with bit errors, and we have the flexibility to do something
> different in order to recover from lost/discarded state at the
> receiver
> Comments?
>     Erik
>
>
> 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.

Greg