Subject: Multicast NS and draft-daley-ipv6-tsllao-00.txt

From: Erik Nordmark <[email-masked]>
Date: Wed, 4 Aug 2004 09:45:45 -0700 (PDT)

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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------