Let me see if I understand you correctly. You would receive the L2 Multicast because your CAM contains the address, but you would not receive a message sent to the system's L2 unicast address. Why? Most ethernet chips I'm aware of will happily store any message they receive that is directed to their configured unicast address...
On Aug 3, 2010, at 3:54 PM, Hemant Singh (shemant) wrote: > Fred, > > Snipped from RFC 3810, section 7 is the following text. > > [For each interface over which the router operates the MLD protocol, the > router must configure that interface to listen to all link-layer > multicast addresses that can be generated by IPv6 multicasts. For > example, an Ethernet-attached router must set its Ethernet address > reception filter to accept all Ethernet multicast addresses that start > with the hexadecimal value 3333 [RFC2464]; in the case of an Ethernet > interface that does not support the filtering of such a multicast > address range, it must be configured to accept ALL Ethernet multicast > addresses, in order to meet the requirements of MLD.] > > I can program such a L2 multicast filter in the CAM (Content Addressable > Memory) of Ethernet hardware with CAM. So if this router directly > receives a multicast message with multicast destination but unicast L2, > the sniffing on 3333.xxxx.xxxx fails to capture this packet and the > router just failed MLDv2 gleaning of this message. One may also note > that MLD is used by ND as specified in RFC 4862 and RFC 4861. > > So what text do we add to the Sri document to exclude MLDv2 protocol > from their proposal? > > Hemant > > -----Original Message----- > From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of > Fred Baker (fred) > Sent: Monday, August 02, 2010 2:09 PM > To: Wes Beebee (wbeebee) > Cc: IPv6 Operations; 6man Mailing List; Kurt Erik Lindqvist > Subject: Re: draft-gundavelli-v6ops-l2-unicast WGLC > > 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. http://www.ipinc.net/IPv4.GIF -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
