Hi Erik, Thanks for looking into this.
----- Original Message ----- From: Erik Nordmark <[EMAIL PROTECTED]> Date: Wednesday, August 4, 2004 9:45 am Subject: Multicast NS and draft-daley-ipv6-tsllao-00.txt > 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 > includingSLLAO 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. I can't see any explicit reason based on RFC 2461 to not count the NS as a 'valid solicitation', althought it explicitly violates section 4.3 in ND. If a node doesn't include the option, it may be dropped by (over?) zealous implementations. Then again, it could get dropped or lost anyway, and we're talking about a performance enhancement which is required only for the Tentative/Optimistic period. I'll try to carve some text (as time permits) to relax this. Your analysis may be useful in an appendix. Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
