Section 2,1 says: Hosts MUST NOT send Neighbour Solicitations with specified source addresses and TSLLAO to nodes for which there is no pre-existing neighbour cache entry, or state is INCOMPLETE, unless these nodes are known to support TSLLAOs.
This is because such Neighbour Solicitations violate IPv6 Neighbour Discovery specifications since they contain no SLLAO, and may cause confusion or harm to nodes which receive them. While this is correct given what RFC 2461 says, I think it is possible to relax this constraint and allow TSLLAO on multicast NS messages. The reason (if I recall correctly) that RFC 2461 has a MUST for including SLLAO on a multicast NS (except in the DAD case, and when the link-layer has addresses i.e. not point-to-point) is to avoid this case of infinite nesting when SLLAO is not required as illustrated by this sequence of events where SLLAO is not included in the multicast NS messages: 1. A multicasts a NS for B without SLLAO. 2. The ND code B receives it and responds with a NA. 3. When this is passed to the lower levels of IP on B, there is no neighbor cache entry for A (due to not SLLAO). Thus B needs to perform address resolution by sending a NS to A (before it is able to send the NA). B sends the NS without SLLA0. 4. The ND code on A receives the NS and responds with a NA. 5. When this is passed to the lower levels of IP on A, there is no neighbir cache entry for B. Thus A needs to perform address resolution by sending a NS to B (before it is able to send the NA). A sends the NS without SLLA0. Step 2 through 5 repeat forever, and no NA is ever sent. In the case when the first NA is unicast (as part of NUD) at worst the nesting terminates at step 5, because A already has a Neighbor Cache entry for B (which was used to unicast the NS in step 1). And in the case of DAD there is no nesting because any response to a DAD NS is multicast to all-nodes. So the requirement is that this not nest forever, but just as in the unicast NS case it should be ok if B needs to send a NS and receive a NA before it can actually send its NA. If we say that TSLLAO is ok on multicast NS messages we have two cases depending on whether B supports TSLLAO. Case 1: B supports TSLLAO There is no nesting since B will use the TSLLAO to send the NA. Case 2: B does not support TSLLAO. In this case B would perform step 2 and 3 above, except that it still MUST include the SLLAO per RFC 2461. Thus A can respond with a NA; there is no more nesting than in the unicast case. This assumes that a node which supports TSLLAO supports it both for transmit and for receive, which is a natural requirement. Erik -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
