Can you point us to the text in RFC 3810 that says "an IPv6 Receiver Node
SHOULD drop..." and "...MAY NOT..."?
The paragraphs in RFC 3810 that contain the word "unicast" read:
o "source list" is an unordered list of zero or more unicast
addresses from which multicast reception is desired or not
desired, depending on the filter mode. An implementation MAY
impose a limit on the size of source lists. When an operation
causes the source list size limit to be exceeded, the service
interface SHOULD return an error.
The Source Address [i] fields are a vector of n unicast addresses,
where n is the value in the Number of Sources (N) field.
In MLDv2, General Queries are sent to the link-scope all-nodes
multicast address (FF02::1). Multicast Address Specific and
Multicast Address and Source Specific Queries are sent with an IP
destination address equal to the multicast address of interest.
*However*, a node MUST accept and process any Query whose IP
Destination Address field contains *any* of the addresses (unicast or
multicast) assigned to the interface on which the Query arrives. This
might be useful, e.g., for debugging purposes.
The Source Address [i] fields are a vector of n unicast addresses,
where n is the value in this record's Number of Sources (N) field.
Version 2 Multicast Listener Reports are sent with an IP destination
address of FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast
routers listen (see section 11 for IANA considerations related to
this special destination address). A node that operates in version 1
compatibility mode (see details in section 8) sends version 1 Reports
to the multicast address specified in the Multicast Address field of
the Report. In addition, a node MUST accept and process any version
1 Report whose IP Destination Address field contains *any* of the
IPv6 addresses (unicast or multicast) assigned to the interface on
which the Report arrives. This might be useful, e.g., for debugging
purposes.
What you are arguing is that a statement which is not made in the RFC is
normative in the way you interpret it, and making a statement that disagrees
with your preconception but disagrees with no statement actually made in the
RFC is a protocol error. As I read it, RFC 3810 doesn't normally expect it (for
obvious reasons) but doesn't preclude it. This memo commits the egregious sin
of making the statement and specifying the cases in which it is argued to be
appropriate.
On Aug 2, 2010, at 6:30 PM, Wes Beebee wrote:
> In case people haven’t had time to read the whole draft, the key standards
> track change to existing RFC’s is:
>
> “An IPv6 receiver node SHOULD NOT drop a received IPv6 multicast
> message containing a multicast destination address in the IPv6
> header, but with a unicast destination address in the link-layer
> header, withstanding all other validity considerations as
> specified in the relevant IPv6 standards specifications.”
>
> “An IPv6 sender node MAY choose to transmit an IPv6 multicast
> message as a link-layer unicast message.”
>
> - Wes
>
> On 7/31/10 1:54 AM, "Fred Baker" <f...@cisco.com> wrote:
>
>> This is to initiate a two week working group last call of
>> draft-gundavelli-v6ops-l2-unicast. Please read it now. If you find nits
>> (spelling errors, minor suggested wording changes, etc), comment to the
>> authors; if you find greater issues, such as disagreeing with a statement or
>> finding additional issues that need to be addressed, please post your
>> comments to the combined lists.
>>
>> We are looking specifically for comments on the importance of the document
>> as well as its content. If you have read the document and believe it to be
>> of operational utility, that is also an important comment to make.
>>
>>
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
http://www.ipinc.net/IPv4.GIF
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
