Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-optimistic-dad-01.txt

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 03 Aug 2004 00:23:10 +0900

>>>>> On Thu, 29 Jul 2004 17:53:30 +1000, 
>>>>> "Nick 'Sharkey' Moore" <[email-masked]> said:

>> Before going to the specific ones, I'd like to present the basic logic
>> I'd (personally) envision in this discussion.  (It's my personal
>> opinion.  I know opinions may vary on this.)
>> 
>> The most important thing is to not cause disruption for non-optimistic
>> nodes.  If there is any possibility of disruption, I basically want to
>> confirm consensus if it is acceptable for those who implemented
>> (and/or are operating) the "standard" behavior and is not particularly
>> interested in implementing/operating the optimistic behavior.  The
>> logic like "this only matters in corner cases so it should be
>> acceptable" from the side that wants to introduce the optimistic
>> behavior is not justified, IMO.

> Okay, we differ here:  I think the aims of Optimistic DAD are to
> configure the address without delay; to remain interoperable with
> unmodified hosts and routers; and to mitigate disruption
> in the case of a collision with any node.

In a general sense, this matches my understanding.  But see below
regarding the "interoperability".

>> I understand the motivation, but it is not convincing enough based on
>> my "basic logic".  Also, if the motivation to optimize roaming between
>> a mobile node and a router that has the ability to support the MN, do
>> we really need to realize that by overloading the existing protocol
>> mechanism, with taking a risk to cause disruption?  Can't we do that
>> with, e.g., a new ND option that only works for nodes that understand
>> it?

> ... and this gets back to my first point: one aim of Optimistic DAD
> is to provide an _interoperable_ solution, the kind of thing you
> can build into mobile nodes and use even if the router of the access
> network doesn't understand it.  

If the unsolicited NAs as a signal did not cause any bad effect on
existing implementation, I'd also call that "interoperable" solution.
But they actually do cause a bad effect of increasing the odds of
disruption.

On the other hand, the new ND option is really an "interoperable"
solution, since existing unmodified routers simply ignore the new
option (see, e.g., Section 6.1.1 of RFC2461) and this does not have
any bad effect on existing implementations.

So, IMO, we cannot justify introducing the signaling unsolicited NAs
by saying "the goal is to provide an interoperable solution".

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 3 Aug 2004 01:58:56 +1000

On 2004-08-03, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> disruption

... in a case so rare that users should be more concerned about
being struck by lightning and/or asteroids.

> any bad effect on existing implementations.

I guess there's "interoperable" and "interoperable".  OptiDAD is
interoperable with unmodified routers in that it actually works with
them.  This isn't the case for a new ND option.

I actually quite like the new ND option alternative, it has the
potential to get things done with less signalling overhead.  But the aim
of OptiDAD is to work with unmodified equipment, so that your OptiDAD
capable MN will work with every Starbucks AR.

Anyway, perhaps we can meet and discuss before the session.
I'm presenting in MobOpts right now, I don't know what you look
like so if you see me around (Monash t-shirt) say hello!
I'd also be interested in other opinions ... somehow we've
got to reach a rough consensus on this (we've already got 
running code ...)

-----Nick

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 03 Aug 2004 01:21:04 +0900

>>>>> On Tue, 3 Aug 2004 01:58:56 +1000, 

> got to reach a rough consensus on this (we've already got 

A quick check: what kind of "rough consensus" are you talking about?
At least I'm not convinced that the unsolicited NAs as a signal for
mobility-supporting routers is necessary.

					JINMEI, Tatuya

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 3 Aug 2004 03:18:27 +1000

> A quick check: what kind of "rough consensus" are you talking about?

Well, the problem is finding a balance between safety, speed and
complexity and interoperability.  it's a difficult tradeoff, and
I've got feedback in all possible directions!

It's a tradeoff, and I'd like to find a consensus position 
somewhere in the middle of the solution space.  This is why I
sometimes talk about what I _personally_ think vs. what
I _editorially_ think ...

> mobility-supporting routers is necessary.

That's fine: either am I.  I'm happy to remove this from the 
draft, as it is separate from OptiDAD really (Mobopts can argue
about it instead :-) )

(Sorry I haven't had a chance to fix the issues list page
yet, will do it ASAP now I've got the laptop working
with the WiFi ...)

-----Nick
-- 
Nick 'Sharkey' Moore  <[email-masked]>  <http://zoic.org/sharkey/>
"I also would like to have a cell phone that enabled me to jam the
cell phones of people around me." -- Dave Barry, interviewed on /.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 3 Aug 2004 03:20:45 +1000

On 2004-07-28, Erik Nordmark wrote:
> > > The first unsolicited NA (O=0) is allowed because there are cases
> > > (think predictive handovers) where the router may be buffering
> > > traffic for the MN,
> 
> So I think we can leave this part out of optimistic-dad for the time
> being and worry about in the DNA or in the specific case of predictive
> handover.

Yep, no worries.  I agree.  It's only really there to support
predictive handovers, if they want it they can specify it 
themselves :-)

-----Nick

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 03 Aug 2004 15:37:22 +0900

> Our time in the WG is limited, but I'll try and work out some way of
> gauging the WGs feelings about these issues.

To save time, here is a summary of my opinion on the substantial
request to optimistic DAD.

1. I'd like to see informed concent and clear consensus on the
   (relatively longer) possible disruption when a different node
   already uses the address as a proxy-ND node.

2. I'd like to remove unsolicited NAs at the beginning of optimistic
   DAD session.  (I guess we've agreed on this)

3. I'd like to remove the advantage given to the optimistic node in
   Section 4.3.  As I already pointed out, allowing the advantage can
   leave a hard-to-diagnose problem if the collision reason is the
   collision of hardware addresses (see Section 5.4.5 of
   draft-ietf-ipv6-rfc2462bis-03.txt).  And, practically speaking,
   removing the advantage is not really a severe disadvantage for the
   optimistic node, since the collision should be rare (again, as I
   pointed out, I'd use the low odds of collision this way, rather
   than justifying further easy optimization for optimistic nodes).

To rephrase my rationale, I'd like the optimistic behavior to be
conservative and prudent as much as possible.  I'm not particularly
interested in realizing the optimistic behavior to help mobile nodes,
but I understand the motivation to decrease the roaming delay.  I'd
thus accept the proposal if the behavior is very careful and prudent
not to cause any additional possibility of disruption, whether the
odds are small, miniscule, whatever.

In this sense, I'd like to begin with minimum optimistic behavior that
is crucial to achieve the goal.  Any further optimization that can
affect existing implementation should be removed right now; if the
result turns out to be insufficient through actual experiment, then we
can consider further optimization.

Finally, I admit some of the above points may be controversial, and
different people in the working group may have different opinions.  Of
course, I'll follow the wg consensus and I'm not going to stick to my
points if it's "just me".

					JINMEI, Tatuya

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 3 Aug 2004 17:08:12 +1000

> request to optimistic DAD.

Thanks Jinmei.  I think we're not that far apart in our
opinions after all :-)

> points if it's "just me".

Same here!  Such is the way of rough consensus :-)  If anyone
on the list has strong opinions on any of the issues, please
step forward and be counted :-)

Thanks for digesting the big issues down, I've added these
three points to the issues list, and I'm revising my 
presentation to focus on these things since I feel they're
the most urgent to discuss with the WG.

cheers,
-----Nick
-- 
Nick 'Sharkey' Moore  <[email-masked]>  <http://zoic.org/sharkey/>
"A thing should be as simple as it is and no simpler." -- Albert Einstein

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 3 Aug 2004 14:38:08 -0700 (PDT)

Overlall this is a good and important document which I'd like to
see standardized.

Here are some nits and clarifications, as well as some concerns about the
use of unsolicited advertisements.

Applicability question:
I think we understand the implications of having a host use an optimistic
address. But do we know what happens should a router use an optimistic
address (to start forming neighbour adjacencies using a routing protocol)
and then discovers that the address is a duplicate?
Should we limit the applicability to hosts, or explicitly say that
routing protocols should not use optimistic addresses?

Section 2.2 says:
   When the DAD timer completes without incident,
   the address becomes a Preferred address.

This isn't correct. Whether the address becomes preferred or deprecated
is a function of the preferred and deprecated lifetimes. If the preferred
lifetime is zero it will become deprecated after the DAD completes.
How about saying
   When the DAD timer completes without incident,
   the address becomes a Preferred or a Deprecated address based on its
   preferred lifetime.

As I pointed out elsewhere, I think we should drop section 2.4.
If some predictive scheme needs this it can be specified in the future.
This effects the text in section 4.
Note that I don't see a need to prohibit unsolicited NAs with O=0,
thus the text in section 3.1 regarding them is ok.
I just don't see them as useful hence we shouldn't recommend that they be
sent.

Section 2.5 says:
   When the ON wants to contact another neighbour, but it cannot because
   the neighbour is not in its NC, it should instead forward the packet
   to the router, relying on the router to forward the packet.  

This begs the question "instead of what". Also, the ON might have other
non-optimistic addresses it can use to send a NS.
I suggest rephrasing it as 
   When the ON wants to contact another neighbour, but it cannot because
   the neighbour is not in its NC and it has only optimistic address(es)
assigned
   to the interface, then it can not send a Neighbour Solicitation message.
   Instead it should send the packet
   to the router, relying on the router to forward the packet.  

Section 2.6 doesn't say anything useful for an implementor.
Do we want to say that optimistic nodes should retransmit the DAD probe 3
times? This wouldn't have much of a performance effect and it would improve
detection in the presence of packet loss. Given that optimstic support
might be common on nodes with wireless interfaces (which have higher packet
loss in many cases) this might be a reasonable improvement.

In section 3.1:
   * (modifies 7.2.2)  When a node has a unicast packet to send from an
        Optimistic Address to a neighbour, but does not know the
        neighbour's link-layer address, it MUST NOT perform Neighbour
        Discovery but instead SHOULD forward the packet to the router of
        that network.

Note that the procedure of sending a NS and getting a NA is called "address
resultion" in RFC 2461. Also, since the host might have other addresses it
can use for the NS.
I'd suggest:
   * (modifies 7.2.2)  When a node has a unicast packet to send from an
        Optimistic Address to a neighbour, does not know the
        neighbour's link-layer address, and only has optimistic addresses
        assigned to the interface, it MUST NOT perform Address 
        Resolution by sending a Neighbour Solicitation message,
        but instead SHOULD forward the packet to a default router on the link.

Section 3.1 says:
   * When the DAD timer expires on an Optimistic Address, the
        'Optimistic' flag MUST be cleared, and the address becomes a
        Preferred Address.
I suggest:
   * When the DAD timer expires on an Optimistic Address, the
        'Optimistic' flag MUST be cleared, and the address becomes a
        Preferred or Deprecated Address based on its preferred lifetime.

Section 3.1 says:
   * (modifies 5.4.5) An Optimistic Address that is determined to be a
        duplicate MUST be deconfigured immediately.  If the address is a
        link-local address formed from an interface identifier based on
        the hardware address (e.g. EUI-64), the interface SHOULD be
        disabled.  Otherwise, if the address was automatically
        configured, DAD SHOULD be restarted with a new address.
        (Appendix A suggests methods for generating a new address)
Since the text in RFC 2462bis is being revised, how about referring to
that document instead of duplicating a probably stale snapshot of the behavior
in this document.
We could simply say:
   * (modifies 5.4.5) An Optimistic Address that is determined to be a
        duplicate MUST be deconfigured immediately, the same way
        a tentative address is deconfigured when found to be a  duplicate.
        Further implications of an address being found a duplicate are
        specified in [RFC 2462].
        (Appendix A suggests methods for generating a new address)

Section 4 has:
                        , and a Neighbour
   Advertisement (with the Override flag cleared) for the address. This
   NA allows communication with neighbours to begin immediately.

I think this should be dropped if we agree that section 2.4 should be dropped.
The ON can communicate with neighbors by sending packets via a default router,
and neighbors can reach the ON my sending a NS and getting a NA with O=0.

Section 4.1:
   After the appropriate DAD delay, the address's Optimistic flag is
   cleared and another NA is sent, this time with O=1. This will ensure
   that all Neighbour Caches are up-to-date.

I don't see this solving any problem. If the NCEs have stale information
(for whatever reason) NUD will take care of that. And there is nothing
in the operation of optimistic DAD which will create stale information
when there is no duplicate.
Thus sending unsoliciated NAs doesn't seem to help when there is no duplicate.

Section 4.3:
   In contrast,
   if a node attempts to configure an Optimistic Node's Optimistic
   Address, the Optimistic Node will not deconfigure the address, and
   instead defend with a Neighbour Advertisement, causing the newcomer
   to reconfigure.  This gives the Optimistic Node a slight advantage
   over Standard nodes, however this is justified since the Optimistic
   node may have already established connections to Optimistic
   Addresses.

I didn't find the details of how this defense works; in fact it seems
inconsistent with the text that says when the address is found to be a
duplicate it must be deconfigured.
In any case, I think trying to defend the address to control who wins is 
complex; the risk is that multiple ONs would keep on responding with NAs at
each other to try to win. So simply having the first entity winning (i.e.
reception of a NS/NA when not in tentative or optimistic doesn't make the
address a duplicate, but reception of a NS/NA in those states forces
the address to be unconfigured) should be sufficient.

Section 4.4:
   and if two nodes configure simultaneously, they may each miss
   the other's NS.

I don't see how this can happen in standard DAD when there is no packet loss.
Thus I think standard DAD has problems when 
 - there is packet loss
 - when nodes has intermittent connectivity to the link (which could be viewed
   as a form of packet loss)
 - then the link is partitioned (and later heals) since the DAD process is only
   run when the addresses are configured and not continiously I suspect
optiDAD has the same limitations.

   Erik

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 5 Aug 2004 02:16:46 +1000

> Overlall this is a good and important document which I'd like to

Thanks.  I think it's getting there!

> routing protocols should not use optimistic addresses?

I've got to admit, the thought had never even crossed my mind.

Sending RAs from an Optimistic Address would definitely have
bad consequences in the case of a collision ... there's no 
Override bit or equivalent mechanism available.  Additionally,
a collision could potentially redirect a whole lot of traffic
to the collidee if the collider nominates it as a default
router!

I think we should limit the applicability to hosts, and if
NEMO WG needs a router equivalent let them develop it :-)
Comments anyone?

> lifetime is zero it will become deprecated after the DAD completes.

Yeah, I changed that text at the last minute and didn't really
think it through *hangs head in shame*.  It's in 3.2 as well.  
Oh, you mention that below too ...

>    the address becomes a Preferred or a Deprecated address based on its

OK.  Jinmei was unhappy with 'DAD Timer', too ... any suggestions
of how I can unambiguously explain what I mean?  I don't like
"when DAD completes", because I don't think it's clear enough
either ... 

> This effects the text in section 4.

OK.  

> I just don't see them as useful hence we shouldn't recommend that they be

Yep, they're only useful in a particular circumstance, and that
puts them fairly thoroughly beyond the scope of OptiDAD.  I'd
like to keep the rules about the O flag in 3.1, just to
keep anyone who does implement this honest.  Jinmei, would you
be happy with this?

>    to the router, relying on the router to forward the packet.  

OK, good.   Will do.

> loss in many cases) this might be a reasonable improvement.

Would seem okay to me ... should that be a SHOULD?

>         but instead SHOULD forward the packet to a default router on the link.

OK, that sounds fine.

>         Preferred or Deprecated Address based on its preferred lifetime.

Ditto.

>         (Appendix A suggests methods for generating a new address)

OK.  It seems like OptiDAD is actually getting _smaller_, which
to my way of thinking is a good thing!

> and neighbors can reach the ON my sending a NS and getting a NA with O=0.

Yeah, it was intended to be a quickstart mechanism for when
using predicitive handovers (circa Yokohama) and shouldn't 
be in here any more really.  My Fast Handovers work has gone
pretty thoroughly non-predictive in the meantime anyway :-)

> Thus sending unsoliciated NAs doesn't seem to help when there is no duplicate.

It was basically there because if there _is_ a stale entry hanging
about, nothing the node sent while Optimistic will remove it.
But there's no need for OptiDAD to specify it anyway, since it's 
allowed by RFC 2461 7.2.6 anyway. 

> duplicate it must be deconfigured.

The same way as a node would normally defend itself: with an NA
for that address (which, of course, I should have said explicitly)

> the address to be unconfigured) should be sufficient.

Yeah, this has proved rather unpopular.  Originally, it was to
address the concern that the ON may have invested in its new
address (sending Binding Updates, that kind of thing) and so
it would be better for the newcomer to change rather than the
established ON.  A standard node will discard a Tentative
address if it gets an NA for that address OR an NS for that
address from ::.  Thus, in a collision between two Tentative
nodes, both will discard the address.  

In the current OptiDAD rules, an Optimistic Address will only
be discarded if an NA is received for it.  If an NS
from :: is received, the ON will defend the address with an NA,
causing the newcomer to go away.  This reflects the 'semi
tentative' status of an Optimistic Address ...

On the other hand, this is such a vanishingly unlikely 
situation (~ N/2^62, where N is the number of nodes moving
into the network in DupAddrTransmits * RETRANS_TIMER)
that I'm happy to remove it simply because it's unnecessary!

(of course, the ON will not reconfigure an Optimistic Address if it
receives an NS from a unicast address for it ... but then, either
will a standard Node according to 2462.  Unlike a standard node,
the ON will respond to the NS with an NA O=0 rather than
silently ignoring it ...)

> I don't see how this can happen in standard DAD when there is no

Well, yeah, L2 should sort them out so they can hear each other :-)

>  - when nodes has intermittent connectivity to the link (which could
>	be viewed as a form of packet loss)

OptiDAD has all the limitations of Standard DAD ... it's just
a bit quicker.

If I was planning on reinventing this particular wheel I'd probably
look at a continuous process ... but I'm sure that has its own
problems, and its a quite well established wheel already :-)

-----Nick

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 4 Aug 2004 10:08:44 -0700 (PDT)

> NEMO WG needs a router equivalent let them develop it :-)

Works for me.

> "when DAD completes", because I don't think it's clear enough

Hm - this is the result of an implementation suggestion.
Conceptually the address is either preferred or deprecated, and
in addition it is marked as optimistic for some time
and all uses of the address should treat it as deprecated while
it is marked as optimistic.

Thus the implementation suggestion is to actually mark is as deprecated
while it is optimistic, and undo this when it is no longer optimistic.
Since this is about implementations, perhaps it can be lifed out to an appendix
where it can be explained in a bit more detail.

> Would seem okay to me ... should that be a SHOULD?

A SHOULD is fine with me, but the question is in what context it should apply.
For instance, we could RECOMMEND that everybody that implements optiDAD 
uses 3 probes, or we could RECOMMEND this for certain link types ("wireless"
even though it is not well-defined - presumably it includes free space lasers
etc :-)

> allowed by RFC 2461 7.2.6 anyway. 

But this isn't any different than in regular DAD, is it?
I mean if there is some stale information for an IP address in some neighbor
cache on the link, the sending of the DAD NS will not remove the stale info.
Instead NUD when the stale entry is used will take care of it.

> nodes, both will discard the address.  

But this only helps when both perform DAD at the same time.
If the optiDAD is the newcomer it will loose, just as in DAD.
For this optimization to have use there has to be lots of duplicates
so that there are lots of crossing DAD NSes that discovery duplicates.
I don't think we want such a level of duplicates that is needed for
this to make any difference.

> tentative' status of an Optimistic Address ...

I must have missed that in the text.

> that I'm happy to remove it simply because it's unnecessary!

ok

> problems, and its a quite well established wheel already :-)

Yes, a continues duplicate check (and giving up the address as a result)
would provide interesting opprtunities for DoS attacks.
Given the size of the interface ID, I don't think we need this for IPv6.

  Erik

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 5 Aug 2004 03:50:36 +1000

> even though it is not well-defined - presumably it includes free space lasers

Hmmm ... since we're dealing with probabilities here, it would
almost make sense to say "on a media with packet loss probability
P_loss, send it N times where P_loss ^ N >= P_acceptable".  But
then we're stuck trying to make a decision about P_acceptable,
and in any case P_loss is unlikely to be trivially estimable
(and unlikely to be truly independant ...)

(re: sending NA O=1 after completing DAD)
> But this isn't any different than in regular DAD, is it?

No, except that the ON is presumably in more of a hurry.
But I think it's a rare enough case that the NUD delay
is tolerable.

Thanks for your comments, I'm munging them into the issues list / 
slides right now.

-----Nick

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 05 Aug 2004 03:06:22 +0900

>>>>> On Thu, 5 Aug 2004 02:16:46 +1000, 

> keep anyone who does implement this honest.  Jinmei, would you

To make it sure, I'm going to talk about the following bullet of
Section 3.1:

   * (adds to 7.2.6)  The Optimistic node MAY send an unsolicited
        Neighbour Advertisement to All Nodes when it first configures an
        address. The Override flag on this advertisement MUST be cleared
        (O=0).

Hmm, I'd still like to remove this bullet, since I don't want to see
new implementations introduce the optimization just because it's a
"MAY", without considering the rationale and possible bad effects.

My goal is to minimize possible (perhaps unseen) disruption as much
as possible particularly when we can do so without requiring crucial
change on the OptiDAD behavior.  In this sense, I'd personally would
like to prohibit this feature explicitly, so that even existing
implementations that happen to have this feature will remove it.  But
I won't insist on this point strongly.

					JINMEI, Tatuya

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 5 Aug 2004 04:10:50 +1000

> "MAY", without considering the rationale and possible bad effects.

Just to be sure, which possible bad effects do you mean?

-----Nick

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 4 Aug 2004 11:15:36 -0700 (PDT)

> "MAY", without considering the rationale and possible bad effects.

Sorry, I missed that one.
I think the bullet should be reworded to not in any sense recommend sending
such things.
Saying that it isn't illegal for optimistic nodes to send unsolicited NAs
as long as the Override flag is clear should be ok, but the text above talks
about doing something when an address is configured which we should avoid.

How about
	An Optimistic node MUST NOT send any unsolicited Neighbor Advertisements
	when the address is in Optimistic state, unless the Override flag on
	the advertisement is zero.

  Erik

---

From: "James Kempf" <[email-masked]>
Date: Wed, 4 Aug 2004 11:25:37 -0700

> (and unlikely to be truly independant ...)

Link layers typically have a base level expected loss rate (For DSL it is
10^-9). Then there's losses due to equipment faults, they would be hard to
estimate by a node just coming on the link. P_acceptable could be estimated
just as retransmit timer values are, and a base line provided. The actual
value would then be configurable depending on link type.

But maybe this is too much detail...

            jak

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 05 Aug 2004 03:25:04 +0900

>>>>> On Thu, 5 Aug 2004 04:10:50 +1000, 

> Just to be sure, which possible bad effects do you mean?

Umm...I think I've explained this 100 times...basically, any operation
during the optimistic state which would not allow for pure-RFC2462
hosts can cause bad effects.  And I basically mean all such effects in
this kind of context.  In this particular case, sending an unsolicited
NAs can create an unnecessary neighbor cache on other nodes in the
link.  If one of such nodes start to send packets to the optimistic
address and the address is actually a duplicate (i.e., another node
has been using the address), then the packets won't be delivered to
the legitimate node for some period.

I guess the reason why we have needed to this type of conversation so
many times is fundamental difference on the basic standpoint.

You tend to introduce as much convenience for optimistic nodes as
possible when the odds of its bad effect are small.

I tend to avoid any bad effect as much as possible as long as the odds
are non 0, however small they are, particularly when the additional
convenience is a kind of option for the optimistic behavior.

(But note that I've already admitted the difference is a controversial
point.)

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 05 Aug 2004 03:39:32 +0900

>>>>> On Wed, 4 Aug 2004 10:08:44 -0700 (PDT), 
>>>>> Erik Nordmark <[email-masked]> said:

> Works for me.

For that matter, works for me, too.

> where it can be explained in a bit more detail.

I'm afraid we're talking about different things...regarding the point
that an address does not necessarily become preferred, I totally agree
with you (in fact, I pointed out the same thing in my own comments).

The very point here is just a wording issue about the term "DAD
timer".  I said I was unhappy with this simply because it sounds like
a technical term for which the reader would go find the definition
(but it is actually defined nowhere).

In this sense, your suggested text would simply be:

    When DAD completes without incident,
    the address becomes a Preferred or a Deprecated address based on its
    preferred lifetime.

>> "when DAD completes", because I don't think it's clear enough

For me, "when DAD completes" and "When the DAD timer completes" are
equally ambiguous, but I admit this is a matter of taste.

But note that even RFC2462 uses a phrase like "when DAD completes": it
says in Section 5.4 that

   An address on which the duplicate Address Detection Procedure is
   applied is said to be tentative until the procedure has completed
                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^
   successfully.

No one has never claimed that this is ambiguous, and rfc2462bis also
uses this phrase as was in RFC2462.

Moreover, even the optimistic DAD draft uses this (kind of) term.  To
name a few:

   Tentative Address - an address for which a node has not yet completed
                                                       ^^^^^^^^^^^^^^^^^
        DAD is regarded as Tentative: a single Neighbour Solicitation ...
        ^^^
   (Section 1.3)

   Optimistic Address - an address which is available for use despite
        DAD not being fully complete.
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   (Section 1.3)

   * (adds to 7.2.6)  The Optimistic node MAY send an unsolicited NA to
        All Nodes when it completes DAD. The Override flag on this
                  ^^^^^^^^^^^^^^^^^^^^^
        advertisement SHOULD be set (O=1).
   (Section 3.1)

If you still think we need to avoid the term "DAD completes" for
clarity, I'll try to suggest a better approach.

					JINMEI, Tatuya

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 5 Aug 2004 05:47:01 +1000

On 2004-08-05, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> Umm...I think I've explained this 100 times...

You've claimed it several times.  

> basically, any operation
> this kind of context.

Okay, but specifically ...

> In this particular case, sending an unsolicited

Okay, if that's the one you're worried about:

Let's imagine that node A is preparing to start talking to node B
when node C arrives and optimistically squats on the address of B.
If C's NA(O=0) arrives while A has an NC entry in a receptive state,
an incorrect entry will indeed be created.  However, B's NA(O=1)
will soon override this incorrect entry, and if it arrives _before_
C's NA(O=0) the incorrect entry will not be created.

> many times is fundamental difference on the basic standpoint.

I agree that there is a chance of collision, and I see where you're
coming from.  I think the probability of collision is negligible,
but since the unsol NAs are only useful in predictive handovers
case, I'm happy to drop them.

Erik suggested replacement text elsewhere in this thread: I'm
happy with that.  It doesn't encourage sending the NAs in
any way, but it does warn that if someone does decide to send
them they MUST have O=0.  That's fine by me -- the bit I
really wanted to keep was the MUST have O=0 warning!

Are you happy with Erik's text?

-----Nick

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 05 Aug 2004 07:29:56 +0900

>>>>> On Thu, 5 Aug 2004 05:47:01 +1000, 

> C's NA(O=0) the incorrect entry will not be created.

I 'm sure I've already fully understood the scenario.  You will not
have to repeat the points again, since I think the difference just
comes from the difference on fundamental views as I said in my
previous message.

> Are you happy with Erik's text?

Not really, I'm afraid...I'll try to make a response to Erik's message
regarding this point (but it seems to be too late for the wg meeting).

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 07 Aug 2004 04:46:26 +0900

>>>>> On Wed, 4 Aug 2004 11:15:36 -0700 (PDT), 

> about doing something when an address is configured which we should avoid.

My meta-level concern is that if we explicitly mentioned the
unsolicited NA the intent of the NA would be rather unclear.  In fact,
even rev01 of the optimistic-dad draft doesn't talk about the real
intent (i.e., a signal for mobility-supporting routers).  We only
understood the author's real intent through the discussion in the wg
last call.

After understanding the real intent, we seem to have agreed that we
should not override the semantics of unsolicited NA for such a
specialized purpose.  So, we now don't have a reason to send such an
NA for the original purpose.

Meanwhile, RFC2461 (and 2461bis) talks about a case where a node may
want to send unsolicited NAs (e.g., in Section 7.2.6): the case of
link-layer address change.  Of course, this does not match the
optimistic-DAD case either.

Now, why would we bother to mention such an NA at all, while we do not
have a reason to send it?  If the optimistic-DAD document does not
mention it at all, then new implementors would even never imagine to
send it, since there is no documented reason to do so.

Considering the fact there is (reportedly) an implementation that
sends such unsolicited NAs for the reason which is now almost
deprecated, I'd rather add an explicit note that discourages the
behavior.  Otherwise, new implementors may see the source code or the
behavior and try to do the same thing without considering the
background motivation, which is now actually obsolete.

One may perhaps worry about the case where a new implementation
happens to send an NA (for an optimistic address), either solicited or
unsolicited, setting the override flag ON.  And I guess your suggested
new text tries to avoid the behavior explicitly.

I personally think we don't have to worry about it, since Section 2.3
of draft-ietf-ipv6-optimistic-dad-01.txt prohibits the behavior:

   * clearing the 'Override' flag in Neighbour Advertisements for
        Optimistic addresses, which prevents neighbours from overriding
        their existing NC entries. The 'Override' flag is already
        defined [RFC2461] and used for Proxy Neighbour Advertisement.

We could still note the same thing if we really want to care about it,
but then we should simply concentrate on the override flag without
mentioning solicited/unsolicited, e.g.

	An Optimistic node MUST NOT send any Neighbor Advertisements
	when the address is in Optimistic state, unless the Override flag on
	the advertisement is zero.

*** conclusion ***

So my suggestion is:

1. remove the following bullet of Section 3.1:

And then (optionally)

2. add the following somewhere (perhaps not in Section 3, since it's
   not a modification to the existing specifications):

   * The Optimistic node MUST NOT send an unsolicited Neighbor
     Advertisement containing an Optimistic address in the target
     address field.

This is to prohibit new implementations that have seen existing one
using the obsolete behavior from doing the same thing without
considering the real reason for it.  I prefer 'MUST NOT', but this
might be too strong and I can live with 'SHOULD NOT'.

And then (optionally)

3. add the following somewhere (perhaps not in Section 3, since it's
   not a modification to the existing specifications):

   * The Optimistic node MUST NOT send any Neighbor Advertisement
     containing an Optimistic address in the target address field,
     unless the Override flag on the advertisement is zero.

if we really want to avoid an NA that happens to set the override flag
ON.

					JINMEI, Tatuya

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 10 Aug 2004 15:19:58 +1000

G'day Jinmei, it was nice to meet you in San Diego!

> NA for the original purpose.

I don't agree that this is 'overriding the semantics', well, not
any more than having unsolicited RAs and solicited RAs be the
same signal.  And I'm not at all convinced that people shouldn't
do it if they want to, just that it's beyond the scope of the
OptiDAD draft to specify that they should or should not.

But anyway, that's irrelevant because ...

> 	the advertisement is zero.

... I'm happy with that (eg: never explicitly mentioning the 
unsolicited NAs but explicitly requiring O=0 on all NAs from Optimistic
Address)

Thanks for your feedback:  I'll be bringing out -02 out in the next
week or so, and hopefully it'll be something everyone is happy
with :-)

-----Nick

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Aug 2004 02:50:48 -0700 (PDT)

ok

> might be too strong and I can live with 'SHOULD NOT'.

While we don't think sending unsolicited NAs is useful hence they would
consume resources if sent for no reason, this isn't a strong enough
reason to use "MUST NOT" (using "MUST NOT" for things that would cause
interoperability problems, or cause the network to melt would be
appropriate).
So I think this should be a "SHOULD NOT".

> if we really want to avoid an NA that happens to set the override flag

If we do a "SHOULD NOT" in 2 as I suggest, I think it would be useful
to have #3 in the document as well to make it clear that
the override flag must always be zero for optimistic addresses.

   Erik