Re: [DNA] Comments on draft-pentland-dna-protocol3-00.txt

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

Hi Christian,

Sorry, somehow I missed replying to this one earlier.

Christian Vogt wrote:
> Hi DT members,
> 
> I read draft-pentland-dna-protocol3-00.txt.  I think the document is
> very solid!  It provides a good view on the problem of efficient
> movement detection and gives you a clear understanding of how the
> protocol works.
> 
> Nevertheless, a couple of comments from my side are below.
> 
> Section 6.2.6.2:
> 
> 
>>   o  Addresses in the "Optimistic" state remain in the "Optimistic"
>>      state, but the host defers sending out an NS to initiate Duplicate
>>      Address Detection.
> 
> 
> Note that OptiDAD may have already been in progress when the node moved,
> so the process may have already been "inititated".  Also, OptiDAD allows
> you to send more than one NS for increased robustness, whereas the text
> above suggests that there is always a single NS.
> 
> Maybe, the text should read something like:
> 
>    o  Addresses in the "Optimistic" state remain in the "Optimistic"
>       state, but the host defers sending out a pending NS if this has
>       not yet been sent already.  If the host later concludes that a
>       change in IP attachment occurred, it will have to re-initiate
>       Optimistic Duplicate Address Detection on the new link.

Sounds good.

> 
> 
>>   o  No addresses should be in the "Tentative" state, since this state
>>      is unnecessary for nodes that support optimistic Duplicate Address
>>      Detection.
> 
> 
> I don't think this is true.  The draft only says (in section 6.2.6.1)
> that the host must *support* OptiDAD, not that it must use it.  E.g.,
> the host may use OptiDAD for the link-local address and a Mobile IPv6
> care-of address, but not for other addresses.  (I'm not saying there
> would be a good reason for doing this.  I'm just saying this may happen
> according to the requirements set forth in section 6.2.6.1.)

In order to get a fast response, we need oDAD at least for the
link-local address.  Are you talking about, say a global address
that is using DAD?  I guess such an address should remain tentative
and then if link change is detected, DAD should be reinitiated.
If it's the link-local address itself that is doing full DAD, the host
has to either wait until DAD completes, or use the unspecified
address for a source address, and wait for a delayed multicast RA.
> 
> 
>>   In order to perform the DNA transaction, the DNA host SHOULD select
>>   one of the unicast link local addresses that was in the "Preferred"
>>   state prior to switching to "Optimistic" and utilize that as the
>>   source address on the DNA RS.  If the host had no "Preferred" unicast
>>   link local address but did have an address in the "Optimistic" state,
>>   it MUST utilize such an address as the source address.  If the host
>>   currently has no unicast link local addresses, it MUST construct one
>>   and put it into the "Optimistic" state and note this address as
>>   having been in the "Optimistic" state previously, but defer sending
>>   the NS to confirm.  Note that the presence of a duplicate unicast
>>   link local address on the link will not interfere with the ability of
>>   the link to route a unicast DNA RA from the router back to the host
>>   nor will it result in corruption of the router's neighbor cache,
>>   because the TSLLA option is included in the RS and is utilized by the
>>   router on the RA frame without changing the neighbor cache.
> 
> 
> This paragraph misses that an MLD Report must be sent for the
> corresponding solicited-nodes multicast address prior to sending the NS.
> 
> RFC2462bis introduces a delay for this MLD Report in oder to
> de-synchronize mulitple hosts configuring simultaneously.  But since the
> DNA Protocol 3 is tailored to mobile nodes, and mobility already serves
> to sufficiently de-synchronize operations IMO, you should be fine in
> sending the MLD Report immediately.
> 
> 
>>   When the host receives unicast or multicast RAs from the router, if
>>   the host determines from the received RAs that it has moved to a new
>>   link, the host MUST immediately move all unicast global addresses to
>>   the "Deprecated" state and configure new addresses using the subnet
>>   prefixes obtained from the RA.  For all unicast link local addresses,
>>   the host MUST initiate NS signaling for optimistic Duplicate Address
>>   Detection to confirm the uniqueness of the unicast link local
>>   addresses on the new link.
> 
> 
> Same here:  The host should register its solicited-nodes addresses
> before it starts sending NS for OptiDAD.
> 
> 
>>   If the host determines from the received RAs that it has not moved to
>>   a new link (i.e. the link has not changed) ....
> 
> 
> It's important to re-send MLD Reports for all solicited-nodes addresses
> even if the host did not change IP attachment, because the host may have
> moved to a different side of a snooping switch.  Failure to send MLD
> Reports upon an L2 move that was not an L3 move could cause the host not
> to receive further multicast messages (which could be a disaster for
> things like DAD).

It's definitely important to send the MLD reports and we need some
text for that.  I don't think they necessarily have to go out first.
I thought that when we had this discussion before Paris, we decided that
it was ok to send the RS first.  It will have a TSLLAO in it and so
no NS/NA is needed for the router to send back a unicast RA.  Does that
sound right?

Brett.