[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Comments on draft-pentland-dna-protocol3-00.txt
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
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
Brett Pentland wrote:
> 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.