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

From: Greg Daley <[email-masked]>
Date: Wed, 04 Aug 2004 12:20:36 -0700

Hi Erik, 

Thanks for looking into this.

----- Original Message -----
From: Erik Nordmark <[email-masked]>
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-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

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

> (over?) zealous implementations.

FWIW I didn't see any such text either. 

> Your analysis may be useful in an appendix.

ok

  Erik