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