On Mar 29, 2013, at 10:52, Mark Smith <[email protected]> wrote:
> Yes. NUD is performed on the link-local addresses used as the source > addresses for the MLDv2 messages. RFC 4861 says: Neighbor Unreachability Detection detects the failure of a neighbor or the failure of the forward path to the neighbor. Doing so requires positive confirmation that packets sent to a neighbor are actually reaching that neighbor and being processed properly by its IP layer. Neighbor Unreachability Detection uses confirmation from two sources. When possible, upper-layer protocols provide a positive confirmation that a connection is making "forward progress", that is, previously sent data is known to have been delivered correctly (e.g., new acknowledgments were received recently). When positive confirmation is not forthcoming through such "hints", a node sends unicast Neighbor Solicitation messages that solicit Neighbor Advertisements as reachability confirmation from the next hop. To reduce unnecessary network traffic, probe messages are only sent to neighbors to which the node is actively sending packets. See also 7.3.1. Reachability Confirmation In some cases (e.g., UDP-based protocols and routers forwarding packets to hosts), such reachability information may not be readily available from upper-layer protocols. When no hints are available and a node is sending packets to a neighbor, the node actively probes the neighbor using unicast Neighbor Solicitation messages to verify that the forward path is still working. So your multicast emitters would be NS-pinging their destinations all the time? Probably not too onerous for your TV scenario (with REACHABLE_TIME at 30 s), and a good way to shutdown traffic to a hard-failed receiver before the MLDv2 timeouts kick in, but maybe not that great in a constrained network that only occasionally sends multicast packets. (Incidentally, 4861 also says: Neighbor Unreachability Detection is performed only for neighbors to which unicast packets are sent; it is not used when sending to multicast addresses. So this would then have to be adapted, because it's no longer an either/or with 6085.) Grüße, Carsten -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
