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

From: Christian Vogt <[email-masked]>
Date: Sun, 06 Nov 2005 14:29:52 +0100

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/

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Sun, 06 Nov 2005 06:11:40 -0800

Hi Brett,

Hopefully this has not already been brought up in one of those mails on 
the mailing list. I tried to quickly look through the issues in other 
mails and the eye didn't catch this one.

We were discussing this on the design team mailing list sometime ago, 
but I don't remember what was the conclusion. Anyway, the case when the 
router is not advertising any prefixes, e.g. the case when stateful
autoconfiguration is applied, is not clearly stated in the specification 
how to proceed (i.e. obviously no landmark prefix can be picked, CPL 
list can't be constructed). Or is it enough just to state the following?

6.2.6.3  DNA and Statefully Configured Addresses

...
    signaling.  If, however, a non-DNA RA is received, the host SHOULD
    use the DHCPv6 CONFIRM message as described in RFC 3315 [8] rather
    than wait for additional RAs to perform CPL, since this will reduce
    the amount of time required for the host to confirm whether or not it
    has moved to a new link.

/Tero

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Mon, 07 Nov 2005 09:53:35 -0800

Brett,

I found this while digging into the DT mail archive. Erik educated me 
once with the following:

"Even if DHCP is used for address autoconfiguration, there is normally 
significant benefit of telling the hosts the on-link prefixes.

If the routers don't advertise any on-link prefixes, then the hosts will 
have to send all packets to a router (even when the destination is on 
the local link). RFC 2461 does have a redirect message which the routers 
can use in this case to tell a host "the destination is on link - at 
this L2 address". But for a normal broadcast medium, having the hosts 
know the on-link prefixes and using NS/NA to find the L2 addresses is 
more efficient."

However, it's still valid to have a network where the router advertises 
no prefix in the router advertisement but as pointed out above it is not 
an optimal way of configuring the network.

/Tero

---

From: Brett Pentland <[email-masked]>
Date: Tue, 08 Nov 2005 05:40:57 +1100

Hi Tero,

I'm not sure about that one.  If the host has been previously assigned
an address using DHCP, then it could easily extract a prefix from that
to use as a landmark.  The problem would be how the routers found out
about the prefixes.  I guess they have to know about them but I'm not
sure how DNA would be supposed to access them.  Would it be reasonable
to take them straight from the routing table?  I don't know if that's
a good idea.  Other than that, we could have an applicability statement
that just makes such configuations out-of-scope but that's not a very
satisfying answer.

Any thoughts?
Brett.

Tero Kauppinen (JO/LMF) wrote:
>> Hopefully this has not already been brought up in one of those mails 
>> on the mailing list. I tried to quickly look through the issues in 
>> other mails and the eye didn't catch this one.
>>
>> but I don't remember what was the conclusion. Anyway, the case when 
>> the router is not advertising any prefixes, e.g. the case when stateful
>> autoconfiguration is applied, is not clearly stated in the 
>> specification how to proceed (i.e. obviously no landmark prefix can be 
>> picked, CPL list can't be constructed). Or is it enough just to state 
>> the following?
>>

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Mon, 07 Nov 2005 19:09:04 -0800

Brett Pentland wrote:
> a good idea.  

Maybe reasonable from programming point of view but I'm not sure from 
specification point of view.

Routers could listen to DHCP messages but I'm sure if that would be a 
good idea either.

> Other than that, we could have an applicability statement

True. We should consider that as the last option.

> Any thoughts?

Not that many at this moment.

/Tero

>> If the routers don't advertise any on-link prefixes, then the hosts 
>> will have to send all packets to a router (even when the destination 
>> is on the local link). RFC 2461 does have a redirect message which the 
>> routers can use in this case to tell a host "the destination is on 
>> link - at this L2 address". But for a normal broadcast medium, having 
>> the hosts know the on-link prefixes and using NS/NA to find the L2 
>> addresses is more efficient."
>>
>> However, it's still valid to have a network where the router 
>> advertises no prefix in the router advertisement but as pointed out 
>> above it is not an optimal way of configuring the network.
>>
>> /Tero
>>
>>> specification how to proceed (i.e. obviously no landmark prefix can 
>>> be picked, CPL list can't be constructed). Or is it enough just to 
>>> state the following?
>>>

---

From: Brett Pentland <[email-masked]>
Date: Tue, 08 Nov 2005 18:34:53 +1100

Hi Christian,

Sorry, somehow I missed replying to this one earlier.

>       Optimistic Duplicate Address Detection on the new link.

Sounds good.

> 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.
> to receive further multicast messages (which could be a disaster for

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.

---

From: "Tero Kauppinen (JO/LMF)" <[email-masked]>
Date: Wed, 09 Nov 2005 06:23:52 -0800

> Routers could listen to DHCP messages but I'm sure if that would be a 

While browsing through the DHCPv6 specification in a hope of learning 
more, I realized that the DHCP advertisement message can also be sent 
directly to the client and thus the router "can't" listen to these 
messages. Not that it was a good idea in the first place anyway.

I'm not even sure if this issue is worth putting effort on, because I 
think it's once again one of those corner cases where the network has 
not been configured in an optimal way (Erik's mail) but still an 
optimization mechanism (DNA) would be applied.

/Tero

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 10 Nov 2005 07:09:15 +1100

> and then if link change is detected, DAD should be reinitiated.

OptiDAD-06 3.1:
|
| * Optimistic DAD SHOULD only be used when the implementation is aware
| that the address is based on a most likely unique interface
| identifier (such as in [RFC2464]), generated randomly [RFC3041]
| or by a well-distributed hash function [RFC3972] or assigned by
| DHCPv6 [RFC3315].  Optimistic DAD SHOULD NOT be used for
| manually entered addresses.

So there may indeed be Tentative and Optimistic addresses on the same
host at the same time ...

-----Nick

---

From: Christian Vogt <[email-masked]>
Date: Thu, 10 Nov 2005 08:48:51 +0100

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

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

Brett Pentland wrote:
>> 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
>>>  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.
>> 
>> 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.)
> 
> 
> 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.
>> 
>> 
>> 
>> 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.
>> 
>> 
>> 
>>> 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).
> 
> 
> 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.

---

From: Christian Vogt <[email-masked]>
Date: Thu, 10 Nov 2005 09:31:54 +0100

Hi all,

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

> NEW (section 6.2.6.2)
> 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 wrote:
>>>> state is unnecessary for nodes that support optimistic
>>> 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.)
>> 
>> 
>> 
> 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 
> NEW A DNA host MUST support *and it MUST use* optimistic Duplicate 
> 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...
> 
> 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. [....]
> 
>  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.
> 
>>>  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).
>> 
>> 
>> 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?
> 
> 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.
> 
> 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.
> 
> Regards, - Christian