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

Re: shim6 and bit errors in data packet headers

On 4-mei-2005, at 1:33, Erik Nordmark wrote:

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.

I'm not a big fan of this. Just look at the way TCP sessions shut down. There are still many TCP sessions that end in weird ways because both ends have different assumptions.

Also, it seems strange to do work because you want to end the communication.

On the other hand, we don't want to keep shim6 state around forever, and we also don't want to refresh the state continuously when there ins't any communication.

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

Right.

Or a DoS.

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.

Is there any other action that you would like to see taken that can't be without a checksum?

BTW if we're just worried about single bit errors you don't need a 16 bit checksum for this. Even a parity bit will find single flipped bits without fail. A very short CRC may be a good alternative.