[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: draft-gundavelli-v6ops-l2-unicast WGLC
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-bounces@ietf.org [mailto:ipv6-bounces@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.