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

[Christian Vogt <chvogt@tm.uka.de>]

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.

>    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 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).

Regards,
- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/