Re: Exception to "MUST NOT"
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exception to "MUST NOT"



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

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.