[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?