Ok, I seem to be confused here.


Gerrit Renker wrote:

Thank you for the input. To sum up,
 * removing the per-protocol "ICMP payload too short" test and error counter
   increment as initially suggested does not seem right;
 * there are protocols such as IPComp which have a header length less than
   8 bytes(and for these the test in the ICMP handler may be too much);

How so.  Either 8 bytes will be there or not.  If the 8 bytes aren't there,
we won't event make to the error handlers as it stands right now.  As is, if
the ICMP packet doesn't contain the 8 bytes, it's too short according to ICMP spec.

 * there are protocols such as DCCP which need more than 8 bytes (at least 12)
   to interpret the ICMP message in a meaningful way;

If you need more then 8 bytes, that protocol needs to have a check for the extra
space.  8 byte are mandatory.

 * the requirement of having at least 8 bytes of transport-layer data available
   is stringent (afaik) only for ICMPv4, but not ICMPv6;

Splitting hairs here, but ICMPv6 is much more stringent.  It forces you send as
close to 1280 byte error messages as possible.

 * only TCP/SCTP seem to have a proper per-protocol "payload too short" test;

Hm..  In the standard case, these do seem to be redundant since 8 bytes are required
by ICMP spec.

 * for DCCP, the work is actually doubled since 
   - first the ICMP handler tests for minimally 8 bytes, 
   - then the DCCP error handler tests for required minimum of 12 bytes.

DCCP and any other protocol that requires more error data should check for it in
its own handler.  8 bytes should be guaranteed to such handler.

What am I missing?

Thanks
-vlad

Thus the patch at the begginning of this thread should be disregarded.
It might be worth to consider per-protocol handlers.

Gerrit