Somecases. However, ICMPv6 example case, described in the first
mail
of
this thread, has not been found but already described in the
spec;
which
is not a bug at all.
could you give the RFC or draft name, and quote the text you are
worried
about?
Yes. Please have a look on section 2.4 of RFC 2463 (ICMPv6)
...
(e) An ICMPv6 error message MUST NOT be sent as a result of
receiving:
...
(e.2) a packet destined to an IPv6 multicast address (there
are
two exceptions to this rule: (1) the Packet Too Big
Message - Section 3.2 - to allow Path MTU discovery
to
work for IPv6 multicast, and (2) the Parameter
Problem
Message, Code 2 - Section 3.4 - reporting an
unrecognized
IPv6 option that has the Option Type highest-order
two
bits set to 10), or
(e.3) a packet sent as a link-layer multicast, (the
exception
from e.2 applies to this case too), or
(e.4) a packet sent as a link-layer broadcast, (the
exception
from e.2 applies to this case too), or
The MUST NOT here is based on hard-learned experience with broadcast
storms with ipv4 on ethernets.
[I'm actually concerned about the two exceptions here; it seems unwise
to *ever* send an ICMP error in response to a non-unicast packet, lest
everyone else in the multicast group do the same thing and melt the
network..]
You may or may not like the specific result, but the specification here
is very clear: "you MUST NOT do X unless you are in condition Y, in
which case another rule applies." There is nothing in the process that
prevents writing a specification that way.
-- Christian Huitema