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

Re: Exception to "MUST NOT"



On Fri, 28 Sep 2001 09:36:37 +0900, Jiwoong Lee said:

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

Jiwoong:

I assume that what you're asking is whether for exceptions (1) and (2),
if the intent is that an ICMPv6 error MAY, SHOULD, or MUST be generated?

If so, then you are correct - the spec should probably read:

(e.2) a packet destined to an IPv6 multicast address (there are
two exceptions to this rule, where a n ICMPv6 error message <FOO> be
generated): (1) the Packet Too Big......

Unfortunately, I don't know if <FOO> should be MAY, SHOULD, or MUST.
Checking for the (mostly-similar) IPv4 case might help.  Unfortunately,
reading RFC1112, section 7.2, it says:

   quietly discarded.  An ICMP error message (Destination Unreachable,
   Time Exceeded, Parameter Problem, Source Quench, or Redirect) is
   never generated in response to a datagram destined to an IP host
   group.

So obviously, there was a decision in the working group that it should
work differently in IPv6 (or a decision that RFC1112 was buggy).  So
we can't easily extrapolate from RFC1112.

Any packet warriors with more experience than I want to clarify this?
I think I was napping when RFC2463 got written, so I don't remember why
it ended up like this... ;)
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

Attachment: pgpE21l7pBSET.pgp
Description: PGP signature


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.