![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.