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

Re: error messages and silently discarding packets

Hi all,


El 16/03/2007, a las 15:38, Brian E Carpenter escribió:


...
The question is whether we should use ICMP error message or if we should define a shim6 error message within the shim6 protocol Iljitsch suggested we do define such an error message, while the current spec uses ICMP error messages, what should we do? 

In my opinion it depends whether the error messages are *necessary*
or whether they are only advisory.

If they are *necessary* for shim6 to function, that means they need
to arrive whatever ICMP filters are in place. So they would need to
be shim6 messages. If they aren't functionally necessary, ICMP
seems OK.
i have analyzed the different situations based on the criteria suggested by Brian
below i attach the criteria suggested by Brian and the analysis for the different cases.
my conclusion is that most of them are critical, so we should use a new shim6 error message for this, following Brian's criteria. What do others think? 



Second, about silently discarding packets:
there are quite a few situations that the shim6 protocol silently discard packets that it considers an error or are not supported. 

If the error messages are not functionally necessary, I suggest silent
discard as a SHOULD in all cases, with implementers allowed to implement 
error messages as a configurable debug option.
they are not functionally necesary, since the protocol should be working fine wihtout them
do you think we should add some recomendation for the implementers that the can add error messages for debugging purposes? 
Should we define a generic error message for debugging purposes?


analysis of the different cases below...


First, shim6 protocol sends a error message in the following situations:
- when a node receives a critical option that is not recognized. In order to do that, it sends an an ICMP parameter problem (type 4, code 1), with the Pointer referencing the first octet in the option Type field.
This one seems critical for shim6 to work properly, since the option is critical
- when the verification method in the locator list option is not supported, then the host MUST ignore the Locator List and the message in which it is contained, and the host SHOULD generates an ICMP parameter problem (type 4, code 0), with the Pointer referencing the octet in the Verification method that was found inconsistent.
This one seems critical for shim6 to work properly, since if the peer does nto support the verification method, the whole shim6 context is useless
- when a node receives a I1 packet and it doesn't support the shim6 protocol, it sends a ICMP error with "Unrecognized Next Header" type (type 4, code 1)
This one doesn't seem too critical for shim6 to work properly, since it will give up eventually
- If the Update message contains a Locator Preference option, then the Generation number in the preference option is compared with the peer generation number in the context. If they do not match, then the host generates an ICMP parameter problem (type 4, code 0) with the Pointer field referring to the first octet in the Generation number in the Locator Preference option. In addition, if the number of elements in the Locator Preference option does not match the number of locators in Ls(peer), then an ICMP parameter problem is sent with the Pointer referring to the first octet of the Length field in the Locator Preference option. In both cases of failures, no further processing is performed for the Locator Update message.
This one seems critical for shim6 to work properly, becuase, the locator lists may go out of sync
- If a node receives a packet that contains a shim message type which is unknown to the receiver, then an ICMPv6 Parameter Problem error is generated and sent back. The pointer field in the Parameter Problem is set to point at the first octet of the shim message type. The error is rate limited just like other ICMP errors [5].
This one may be critical for shim6 to work properly, depending on the message
So accroding to Brian's criteria, we shoudl define a shim6 error message.. what do others think?