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

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

Hi all,

a quick follow-up; Mark Doll pointed me to this:

> NEW (section 6.2.6.2)
 > If the host determines from the received RAs that it has not
> moved to a new link (i.e. the link has not changed), the host must
> still send MLD Report messages for all solicited-nodes multicast
> addresses that it is listening to.  Retransmission of the MLD Report
> messages ensures that the host continues to receive packets sent to
> one of these solicited-nodes multicast addresses in case it has moved
> to a different side of an MLD snooping switch on the same link. 
> Furthermore, if the previous state of an address was "Optimistic",
> then the host MUST send an NS to confirm that the address is unique
> on the link.  This is required because optimistic Duplicate Address
> Detection may not have completed on the previous point of attachment,
> so the host may not have confirmed address uniqueness.  Similarly, if
> the previous state of an address was "Tentative", then the host MUST
> send an NS to confirm that the address is unique on the link.  If the
> previous state of an address was "Preferred", whether or not the host
> initiates optimistic Duplicate Address Detection depends on the
> configurable DNASameLinkDADFlag flag.  A host MUST forgo sending an
> NS to confirm uniqueness if the value of the DNASameLinkDAD flag is
> False.  If, however, the DNASameLinkDAD flag is True, the host MUST
> perform optimistic duplicate address detection on its unicast link
> local address and it MUST perform either duplicate address detection
> or optimistic duplicate address detection unicast on its global
> addresses to determine address uniqueness.

s/This is required because optimistic Duplicate Address Detection may 
not have completed on the previous point of attachment, so the host may 
not have confirmed address uniqueness./This is required because 
optimistic Duplicate Address Detection did not complete on the previous 
point of attachment, so the host has not yet confirmed address uniqueness./

After all, when the address is still in "Optimistic" state, then address 
uniqueness did not fully complete yet (although we may already have sent 
the NS and listened for responses for 0.999 seconds).

Regards,
- Christian

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


Christian Vogt wrote:
> Hey Brett.
> 
>>>> 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. [....]
> 
> Right, we need OptiDAD for the link-local address.  But I think
> section 6.2.6.1 ("Duplicate Address Detection") should be explicit on
> this. Specifically, how about...
> 
> OLD A DNA host MUST support optimistic Duplicate Address Detection
> [6] for autoconfiguring unicast link local addresses.  If a DNA host
> uses address autoconfiguration [7] for global unicast addresses, the
> DNA host MUST support optimistic Duplicate Address Detection for 
> autoconfiguring global unicast addresses.
> 
> NEW A DNA host MUST support *and it MUST use* optimistic Duplicate 
> Address Detection [6] for autoconfiguring unicast link local 
> addresses.  If a DNA host uses address autoconfiguration [7] for 
> global unicast addresses, the DNA host MUST support [and it MUST use]
>  optimistic Duplicate Address Detection for autoconfiguring global 
> unicast addresses.
> 
> The first modification (which I put within stars) is necessary given
>  that the DNA protocol wouldn't be of much use without it.
> 
> The second modification (which I put in square brackets) is not 
> necessary IMO and should be left up to the DNA host.  After all, you
> do not know for which purpose the global unicast address is meant.
> If it's a Mobile IPv6 care-of address, OptiDAD would surely be
> preferable.  If it's a less important address---e.g., a statelessly
> auto-configured address on the home link that comes in addition to a
> statefully configured home address---then OptiDAD may not be
> necessary (although there would be no good reason for using standard
> DAD instead either).
> 
> Basically, there are three options: - Leave it up to the DNA host. -
> Explicitly differentiate between global unicast addresses where 
> OptiDAD is required and unicast addresses where it is not. - Require
> OptiDAD for all unicast addresses.
> 
> Option 3 would interfere with stateful address configuration
> (DHCPv6). Option 2 would probably make the draft a whole lot more
> complicated, which is not so good either.  I'd go with option 1
> therefore.
> 
>> [....]    Are you talking about, say a global address that is using
>> DAD?  [....]
> 
> Yes, see above.
> 
>> [....]   I guess such an address should remain tentative and then
>> if link change is detected, DAD should be reinitiated. [....]
> 
> It should be something equivalent to the case of optimistic
> addresses. Something like...
> 
> o  Addresses in the "Tentative" state remain in the "Tentative" 
> 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 Duplicate Address
> Detection on the new link.
> 
>> [....]                                                      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. [....]
> 
> Hmm, but I would really require link-local addresses to be configured
>  through OptiDAD.  After all, this protocol is about *fast* DNA.  So,
> if a host claims to be DNA-compliant, it should behave that way.  ;)
> That includes using OptiDAD instead of standard DAD für link-local
> addresses.
> 
>>> 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?
> 
> Oh yes, certainly, you can send out the RS first.  The MLD Report 
> becomes important during address configuration, not during router 
> discovery.
> 
> And here is some proposed text.  From section 6.2.6.2:
> 
> OLD 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.
> 
> NEW 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 transmit an MLD Report message for the
> corresponding solicited-nodes multicast address and then initiate NS
> signaling for optimistic Duplicate Address Detection to confirm the
> uniqueness of the unicast link local addresses on the new link.
> 
> Furthermore, also from section 6.2.6.2:
> 
> OLD If the host determines from the received RAs that it has not
> moved to a new link (i.e. the link has not changed) and the previous
> state of an address was "Optimistic", then the host MUST send an NS
> to confirm that the address is unique on the link.  This is required
> because optimistic Duplicate Address Detection may not have completed
> on the previous point of attachment, so the host may not have
> confirmed address uniqueness.  If the previous state of an address
> was "Preferred", whether or not the host initiates optimistic
> Duplicate Address Detection depends on the configurable
> DNASameLinkDADFlag flag.  A host MUST forgo sending an NS to confirm
> uniqueness if the value of the DNASameLinkDAD flag is False.  If,
> however, the DNASameLinkDAD flag is True, the host MUST perform
> optimistic duplicate address detection on its unicast link local and
> unicast global addresses to determine address uniqueness.
> 
> NEW If the host determines from the received RAs that it has not
> moved to a new link (i.e. the link has not changed), the host must
> still send MLD Report messages for all solicited-nodes multicast
> addresses that it is listening to.  Retransmission of the MLD Report
> messages ensures that the host continues to receive packets sent to
> one of these solicited-nodes multicast addresses in case it has moved
> to a different side of an MLD snooping switch on the same link. 
> Furthermore, if the previous state of an address was "Optimistic",
> then the host MUST send an NS to confirm that the address is unique
> on the link.  This is required because optimistic Duplicate Address
> Detection may not have completed on the previous point of attachment,
> so the host may not have confirmed address uniqueness.  Similarly, if
> the previous state of an address was "Tentative", then the host MUST
> send an NS to confirm that the address is unique on the link.  If the
> previous state of an address was "Preferred", whether or not the host
> initiates optimistic Duplicate Address Detection depends on the
> configurable DNASameLinkDADFlag flag.  A host MUST forgo sending an
> NS to confirm uniqueness if the value of the DNASameLinkDAD flag is
> False.  If, however, the DNASameLinkDAD flag is True, the host MUST
> perform optimistic duplicate address detection on its unicast link
> local address and it MUST perform either duplicate address detection
> or optimistic duplicate address detection unicast on its global
> addresses to determine address uniqueness.
> 
> Note that I also added text to handle addresses in "Tentative" state,
>  which was not dealt with so far.  See our discussion on addresses in
>  "Tentative" state above.
> 
> Regards, - Christian