![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
> > > 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..] - Bill
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.