Hi, > IMHO, we WG might want to update this text after LW-IGMPv3/MLDv2 has been > publushed. Otherwise, all nodes that has applications need SSM MUST implement > "full" MLDv2 (RFC3569, RFC4607) anyway, instead of LW-MLDv2; MLDv2 is not only > for the wire format but also for state processing.
Are the following changes reasonable? > |5.7. Multicast Listener Discovery (MLD) for IPv6 - RFC 2710 > | > | > | Nodes that need to join multicast groups MUST support MLDv1 > | [RFC3590]. MLDv1 is needed by any node that is expected to receive > | and process multicast traffic. Note that Neighbor Discovery (as used > | on most link types -- see Section 5.2) depends on multicast and > | requires that nodes join Solicited Node multicast addresses. > | > | Nodes that need to join multicast groups SHOULD implement MLDv2 > | [RFC3810]. However, if the node has applications that only need > | support for Any-Source Multicast [RFC3569], the node MAY implement > | MLDv1 [RFC2710] instead. If the node has applications that need > | support for Source-Specific Multicast [RFC3569], [RFC4607], the node > | MUST support MLDv2 [RFC3810]. In all cases, nodes are strongly MUST support either MLDv2 [RFC3810] or LW-MLDv2 [LW-MLDv2]. In all cases, ... > | encouraged to implement MLDv2 rather than MLDv1, as the presence of a encouraged to implement MLDv2 or LW-MLDv2 rather than MLDv1, ... > | single MLDv1 participant on a link requires that all other nodes on > | the link operate in version 1 compatability mode. > | > | When MLDv1 is used, the rules in the Source Address Selection for the > | Multicast Listener Discovery (MLD) Protocol [RFC3590] MUST be > | followed. Regards, -- Hitoshi Asaeda p.s. The intended status of the LW-IGMPv3/LW-MLDv2 draft is BCP. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
