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

From: Brian Haberman <[email-masked]>
Date: Fri, 09 Jul 2004 05:58:48 -0400

All,
      This note starts the IPv6 WG Last Call on:

      Title     : Optimistic Duplicate Address Detection for IPv6
      Author(s) : N. Moore
      Filename  : draft-ietf-ipv6-optimistic-dad-01.txt
      Pages     : 17
      Date      : 2004-6-29
	
as a Proposed Standard.  The Last Call will end on July 23, 2004.
Substantive comments should be directed to the [email-masked] mailing
list.  Editorial comments can be directed to the editor.

Regards,
Bob & Brian
IPv6 WG co-chairs

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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 23 Jul 2004 14:39:16 +0900

>>>>> On Fri, 09 Jul 2004 05:58:48 -0400, 
>>>>> Brian Haberman <[email-masked]> said:

	
> as a Proposed Standard.  The Last Call will end on July 23, 2004.
	
My substantial comments are basically based on the view that we only
accept this kind of approach if the impact on non-optimistic
implementations is limited very carefully and as small as possible.

SUBSTANTIAL COMMENTS

1. overall, this approach depends on reasonably small reachable time
  (per Section 4.2 of RFC2461).  If this value happens to be set to a
  large value (say, a few to 10 minutes?) via RA, a duplicate
  link-layer address of an optimistic node can mistakenly be stored
  for the unreasonaly large period.  While this is a general issue on
  the reasonable value of reachable time, I think this draft should
  explicitly note that since it is going to modify the existing
  protocol and affect implementations.  Perhaps we even need to define
  the upper limit of reachable that to allow the optimistic behavior.

2. the optimistic behavior can cause (temporary) disruption when the
  optimistic address collides with an address available via proxy ND
  (as described in section 4.2).  I think we need to make an explicit
  consensus on whether this is acceptable (rather than an implicit one
  like "no objections in the last call").  Perhaps the wg session in
  San Diego is a good chance for this.

3. I don't think the advantage for the optimistic node when two nodes
  simultaneously perform DAD is justified (Section 4.3).

     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.

  As we discussed in rfc2462bis, address duplication may in some cases
  indicate hardware address duplication.  Since continuing operation
  under hardware address duplication can cause additional confusing
  situation (even if one of the colliding node stops using the
  duplicate IP address), I think no exception can be justified.
  Additionally, we should have assumed actual duplication for an
  optimistic address is very unlikely to happen.  If so, giving
  advantage under a nitch duplicate condition does not seem to provide
  much actual benefit.

  So, I'd request to simply remove the special privilege.

4. the optimistic behavior basically assumes routers send RAs with
  SLLAO (e.g., the first sentence of section 2).  But I'm not really
  sure what the node should do if this assumption does not hold
  (the last paragraph of Section 4.4 talks about this a little bit,
  but it's still unclear and I'm not sure if this applies to the
  entire behavior or it is just limited to the particular section).

5. I'm still not really comfortable with unsolicited NAs at the
  beginning of the optimistic DAD procedure.  This can increase the
  possibility of disruption at the non-optimistic side.  Since the
  typical usage of the optimistic behavior assumes RAs with an SLLAO,
  we don't really need such NAs for optimistic nodes to operate.  I'd
  rather prohibit these NAs.

SEMI SUBSTANTIAL COMMENTS

6. In section 2.2, the draft says:

   [RFC2462] introduces the concept of Tentative (in 5.4) and Deprecated
   (in 5.5.4) Addresses.  Addresses which are neither are said to be
   Preferred.  Tentative addresses may not be used for communication,
   and Deprecated addresses should not be used for new communications.
   These status flags may also be used by other standards documents, for
   example Default Address Selection [RFC3484] uses these flags.

But at least RFC2462 does not define the notion of "Tentative" or
"Deprecated" as "flags".  (and RFC3484 does not contain a word
"flag").

7. In section 2.2

   Protocols which do not understand this state should
   treat it equivalently to 'Deprecated', to indicate that the address
   is available for use but should not be used if another suitable
   address is available.

I don't really understand what "protocols which do not understand this
state" actually means.  BTW, can an application (using the standard
socket API) perform the bind(2) system call for an optimistic address?

8. In section 2.2, the draft says:

   When the DAD timer completes without incident,
   the address becomes a Preferred address.

As far as I know, no RFCs define the notion of "DAD timer".  Please be
more accurate on this.  (The same comment should apply to some other
parts of the draft).

Additionally, even after the DAD procedure (successfully), the address
does not necessarily become a preferred one; the preferred lifetime
can be 0 from the beginning.  (The same comment should apply to
Section 3.2)

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

"SHOULD" means there can be an exception, but in this case I don't see
a possibility of exception: what can the node do if it does not
perform ND or forward the packet to the router?  Perhaps we can simply
say "MUST" instead of "SHOULD" here.

10. In section 3.2

   * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for
        its address from the unspecified address with a Neighbour
        Advertisement to the All Nodes address.  If the solicitation is
        for an Optimistic Address, the reply MUST have the Override flag
        cleared (O=0).

Does the first sentence apply to all nodes including "Standard" ones,
or is it limited to optimistic nodes?  (I'd object to this
modification in the first place, BTW - see comment 5).

11. In section 3.2

   * (modifies 5.4.3) A node MUST reply to a Neighbour Solicitation for
        an Optimstic Address from a unicast address, but the reply MUST
        have the Override flag cleared (O=0).

Just a note: this may be a controversial change (see comment 2 above).

12. In section 3.2

   * (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)

Just a note: we are going to clarify this case in rfc2462bis.  Not
sure if it requires a change to the optimistic DAD draft though.

13. In section 4

   The ON will immediately send out a Neighbour Solicitation to
   determine if its new address is already in use, and a Neighbour
   Advertisement (with the Override flag cleared) for the address. This
   NA allows communication with neighbours to begin immediately.

What does "immediately" mean?  Are you saying a random delay before
the first NS (in some situation) should be removed?  The same comment
should apply to NA, while I object to sending such NAs in the first
place (see comment 5 above).

14. In section 4.1

   The Optimistic Node already has the link-layer address of the router
   (from the RA), and the router either already knows the link-layer
   address of the ON from the unsolicited NA, or can determine it
   through standard NUD.

I don't understand how the router can determine the link-layer address
through NUD...do you mean "ND" here?

EDITORIAL COMMENTS

15. this draft uses the term "Neighbour", but for this particular term,
  I guess we should stick to the US standard "Neighbor", because the
  base documents such as RFC2461 use the latter, and people may search
  for related documents with (e.g.) "grep -i neighbor rfc*.txt".

  (In this sense, I don't care about "behaviour":-)

16. the draft uses the term "suffix" to form an address with a prefix,
  but I think it should rather be "interface identifier" based on the
  formal definition used in other IPv6 related documents.

17. there appears to be a mixture on the notation between "an SLLAO" and
  "a SLLAO".  Those should be consistent.  Also, if "an" is the
  intended one, I guess phrase "a NC" (which occurs several times in
  the draft) should actually be "an NC".

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

---

From: Greg Daley <[email-masked]>
Date: Fri, 23 Jul 2004 17:00:22 +1000

Hi Jinmei,

I'm not going to talk about the document itself.

JINMEI Tatuya / ???? wrote:
[cut]
>   (In this sense, I don't care about "behaviour":-)

based on my local archive:

grep  -i neighbour rfc*txt | wc -l
     297
grep  -i neighbor rfc*txt | wc -l
    7695

it seems the RFC editors aren't checking this:

grep  -c neighbour rfc*txt | sort -tc -n +1 | grep -v '^rfc[0-9]*.txt:0' 
|tail -10
rfc2722.txt:1
rfc2811.txt:1
rfc2813.txt:1
rfc2815.txt:1
rfc3208.txt:4
rfc3519.txt:1
rfc3549.txt:1
rfc3719.txt:3
rfc3765.txt:9
rfc3787.txt:1

Is it really important to have the text generated by one
English speaking author (in this case an Australian)
homologated to another dialect?

Greg

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Fri, 23 Jul 2004 16:13:12 +0900

>>>>> On Fri, 23 Jul 2004 17:00:22 +1000, 
>>>>> Greg Daley <[email-masked]> said:

>> (In this sense, I don't care about "behaviour":-)

(snip)

> homologated to another dialect?

I don't think it that important (rather, I think it's a very minor
issue), so I can personally live with either approach.  In particular,
if the author uses his own convention on purpose, I'll respect the
decision.  My point is that it is more reader-friendly to provide
consistency on wording usage as much as possible among documents in a
same single technical category (in this case ND).

					JINMEI, Tatuya

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Fri, 23 Jul 2004 18:02:01 +1000

> implementations is limited very carefully and as small as possible.

Thanks for your extensive comments, Jinmei.  I'll try and
add them to the issues list and carefully consider each of
them by Monday.

It's my intention to use my agenda slot at IPv6 WG to discuss
as many of these points as practical.  But we should try
to hash out the options on the mailing list beforehand.

-----Nick

---

From: Doo Timbir <[email-masked]>
Date: Fri, 23 Jul 2004 16:14:04 +0100 (BST)

Dear Greg,

I feel the most important thing here is for us to
comprehend what is written 'whether in American
English or contemporary Queen's English'.

A grasp of the 'gist'behind the written word should be
much more emphasised on!

Thank you all!

Cheers!
Doo Timbir

--- Greg Daley <[email-masked]> wrote: >
Hi Jinmei,
> Administrative Requests:
> https://www1.ietf.org/mailman/listinfo/ipv6
>

________________________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Mon, 26 Jul 2004 09:51:16 +1000

G'day Jinmei,

	thanks for your comments.  I'm working my way through the
list, here's some initial thoughts.

> implementations is limited very carefully and as small as possible.

I'd agree with this: that's the intention of the draft and I
won't be happy with it if it doesn't.

-----

>   the upper limit of reachable that to allow the optimistic behavior.

Okay, there are two cases:  An Optimistic node tries to configure
an address by sending an NS from :: and it either collides or it doesn't.
If it doesn't, there isn't a problem ... lingering NC state is a 
fact of normal DAD too.

The NS from :: will not create NC state in any of the neighbours,
but other traffic sent before the collision is detected (other
NSs, RSs, NA O=0s) may create an entry if there wasn't one already.
Correspondence with neighbours may moves these entries to REACHABLE.

However, when the collision is detected, the collidee will respond
with an NA O=1 to all nodes, which will override the NC entries
and reset them to STALE.

(please let me know if I'm missing the point entirely)

-----

>   San Diego is a good chance for this.

I agree: this should be discussed.

Personally, I don't think it's a big issue.  The collision will still be
detected and repaired, and the Optimistic Node _will not_ override
an NC entry, even a proxy ND NC entry.  I probably need to amend
the wording of the text: it isn't clear that section 4.2 paras 
4 and 5 are linked and that the slow, NUD case only occurs
"If a neighbour is just preparing to begin communication with the
address" AND "the defending NA has the Override flag cleared".

Editorially, it needs to be discussed and I agree an explicit
consensus would be good.  I'll add it to the issues list, and
bring it up at San Diego.

-----

> [...]

(I'm still thinking about this one ... I'll put it on the issues list)

-----

>   sure what the node should do if this assumption does not hold

There's nothing much they can do: they can't reliably get a reply
from the router with an NS or RS.  Their only option is to wait
until they have a Preferred Address to NS or RS from: eg: wait
out the DAD timer like a normal, RFC2462-abiding node.

>   entire behavior or it is just limited to the particular section).

Okay, I'll try and expand the text there.  Suggestions welcome.

-----

>   rather prohibit these NAs.

The unsolicited NAs will only disrupt things in a couple of tiny
corner cases (eg: #2 above).

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, but it needs some signal from the MN to inform
it of its arrival (the NS doesnt' have enough information).
The NA O=0 will be enough to get this started.  It's a MAY because
its only useful in this particular case.  Does that make sense?

The second unsolicited NA (O=1) is allowed to let the MN trump
any stale NC entries which have been preventing it from communicating,
_after_ DAD has completed.  It's allowed under unmodified DAD in any
case, so I'm happy to remove it.

-----

> "Deprecated" as "flags".  (and RFC3484 does not contain a word

Ugh.  On the one hand, implementing OptiDAD for Linux has been a 
great experience in that it's provided a reality check that OptiDAD
will actually do the right thing.  On the other hand, it's loaded
a set of entirely alien terminology into my brain.  I'll fix the
terminology to refer to 'states' as per the the RFCs.

| These address states may also be used by other standards documents,
| for example Default Address Selection [RFC3484] treats Tentative,
| Deprecated and Preferred addresses differently.

Would that be okay?

-----

> state" actually means.

Okay, so I'm introducing a new state, Optimistic.  Current protocols,
eg RFC3484 mentioned above, will tell you what to do for Tentative
addresses, what to do for Deprecated addresses, what to do for
Preferred addresses.  What I'm saying is that if you've never heard
of the state 'Optimistic', you should treat it equivalently to
'Deprecated'.  I think this should work okay.

> BTW, can an application (using the standard

I hope so!  Can you bind(2) a deprecated address?  I've been assuming
you can, but it seems that not everyone agrees:
	http://www.atm.tut.fi/list-archive/ipng/msg05111.html

It's my intention to allow bind() on Optimistic addresses.  If 
that doesn't fit with the "treat equivalent to Deprecated" idea,
we'll need to think of something cleverer :-)

-----

> more accurate on this.  (The same comment should apply to some other

But you know what I mean, right?  I couldn't find a name for it
anywhere.  Does it have a name? 

If you can point out other places where I've used non-defined 
terminology that'd be handy: it's a bad habit of mine (as per
my 'flag' gaffe above ...)

> can be 0 from the beginning.  (The same comment should apply to

A good point which I hadn't considered at all :-)  I'll have
to have a think about this.

-----

> say "MUST" instead of "SHOULD" here.

It could drop it on the floor, or buffer it awaiting DAD completion:
neither seem like a useful behaviour to me, but I'd rather leave it
up to the implementor whether to implement the router-redirect feature.

-----

> modification in the first place, BTW - see comment 5).

You mean #3?  Still thinking about it!

> Just a note: this may be a controversial change (see comment 2 above).

This one is essential to establish communication while Optimistic.
Imagine I'm sending from an Optimistic Address.  I can send a packet
out via my my router, but it still won't know my LLAddr.  When the
reply comes back, the router must NS for me, so it can pass on
the reply.  If I don't NA in response, the reply will never get to me!

(oh, and I see I made a typo there ... )

-----

> sure if it requires a change to the optimistic DAD draft though.

Yeah, that'd be great.  If the 2462bis text makes this redundant,
I'll remove it.  The original OptiDAD draft included quite a few
things which have been made redundant by 2461bis and 2462bis!

-----

> place (see comment 5 above).

Good point.  Any changes to these delays are beyond the scope of
OptiDAD ... there are other drafts addressing them.

-----

> through NUD...do you mean "ND" here?

Yes, ND.  Oops.  Now I'm confusing even myself.

-----

>   for related documents with (e.g.) "grep -i neighbor rfc*.txt".

You've got a point there.  I'm an Aussie, and out of long habit I
"egrep -i neighbou?r *.txt", but I'm happy to translate
to US English if that's desired.  Not everyone has egrep handy, I
realize :-)

>   (In this sense, I don't care about "behaviour":-)

How about "Alumini?um"?  Do I have to say it funny as well :-) :-) :-)

-----

>   formal definition used in other IPv6 related documents.

Yeah, but it's not always an interface identifier ... 3041 and SEND
and all that.  I think 'suffix' is clearer.

-----

>   the draft) should actually be "an NC".

Argh!  Like apostrophes, that's invisible to me.  I'll grep through and 
standardize them.

-----

Thanks again for your comments, I hope we can iterate this a couple
of times before the session and get some mutual consensus (even if we
still disagree, at least we'll know exactly what we disagree about!)

-----Nick
-- 
Nick Moore, Resarch Fellow        | <[email-masked]>
Monash University CTIE	          | <http://www.ctie.monash.edu.au/ipv6/>
Australian Telecommunications CRC | <http://www.telecommunications.crc.org.au/>

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 27 Jul 2004 10:11:02 +1000

G'day Jinmei,

	the other email covers your other points, these are the two
I left out last time.

>      node may have already established connections to Optimistic

Remember, this is for the case where two nodes are configuring the
same address at the same time.  Given the odds of an address collision
are already vanishingly small, the odds of a simultaneous collision
of this sort are microscopic.

>   duplicate IP address), I think no exception can be justified.

If there's an actual LL address duplication, we've got bigger
problems than worrying about the exact balance of probabilities
in DAD.

>   So, I'd request to simply remove the special privilege.

The reason it's there is to tip the balance in favour of the current
user of an address rather than the newcomer.  The behaviour fits in
with the idea that OptiDAD is promoting the address to non-Tentative ...
non-Tentative addresses are defended rather than surrendered.

-----

> modification in the first place, BTW - see comment 5).

OptiDAD draft does not prescribe ANY changes to behaviour for 
Standard Nodes.  It is designed to interoperate with any nodes
following the rules of 2461/2462, although it doesn't offer any
benefit unless the RS includes a SLLAO.

Which reminds me: any idea what the timetable for 2461bis/2462bis is
looking like?  I guess OptiDAD should be updated one they are finalized.

-----Nick

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 27 Jul 2004 17:50:43 +0900

(I'm trying to make quick comments since I'll be offline for the next
10-12 hours.  I'd apologize in advance for any possible typos or
unclear wording, etc).

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.

Next, if a proposed change for the optimistic behavior is
controversial, then the default policy should be conservative, as long
as it is crucial to make the optimistic behavior work.  Again, just
because it is convenient for optimistic nodes and the change *seems"
to introduce a mess only in some corner cases cannot be a convincing
reason.

>>>>> On Mon, 26 Jul 2004 09:51:16 +1000, 
>>>>> "Nick 'Sharkey' Moore" <[email-masked]> said:

>> (per Section 4.2 of RFC2461). [...]

> with an NA O=1 to all nodes, which will override the NC entries

This is not really correct because duplicate can also be detected when
two (colliding) nodes simultaneously perform DAD.  In this case, there
will be no NA with O=1.

This case requires further discussion, BTW; whether we allow the
advantage in the simultaneous case.  If we don't, this will become a
real issue; if not, we won't have to worry about this case.

Also, we could perhaps say the resulting disruption may not be so
harmful, since no nodes will use the duplicate address in this case.

> an NC entry, even a proxy ND NC entry.

Different people may have different views on this, and that's why I
want to see an explicit consensus.  (See also the "basic logic" above).

(For that matter, I personally can live with the delay in this case
though).

> out the DAD timer like a normal, RFC2462-abiding node.

Okay.  I'll be happy if this point is clearer in the document.

> corner cases (eg: #2 above).

First, I don't think the logic of "this only matters in corner cases"
is not justified (see the "basic logic" above).

> its only useful in this particular case.  Does that make sense?

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?

> case, so I'm happy to remove it.

As I said in the comment, I don't care about the second NA (O=1).
It's up to you whether and how you include it in the optimistic DAD
document.

> Would that be okay?

Yes, except for one thing: RFC3484 does not mention tentative.  (In
fact, a "tentative address" should never been assigned in an interface
in theory, so it cannot be a target in RFC3484 in the first place).

Also, you might want to reconsider whether "Optimistic" should be
defined as a "flag", too.  (e.g., section 4.1 has this phrase: "...the
address's Optimistic flag is cleared...").

> 'Deprecated'.  I think this should work okay.

Okay, then referring to RFC3484 as an example might help here (note,
again, that RFC3484 does not talk about tentative addresses though).

> we'll need to think of something cleverer :-)

We decided in rfc2462bis to allow applications binding a
deprecated address (see the second paragraph of rfc2462bis-03 Section
5.5.4).

I'm not sure if it requires a change in the optimistic DAD draft
though.

> But you know what I mean, right?

Yes, but I think it is generally not a good practice to introduce an
unofficial technical term (or a phrase that looks like a technical
term) without providing a clear definition.  Assuming the correct
guess at the reader's side is naive, IMO.

> I couldn't find a name for it

No, but I don't see why we cannot simply say like "When DAD completes
without incident" in this case.  I believe similar wording can also
apply to other occurrences of "DAD timer".

> up to the implementor whether to implement the router-redirect feature.

I see.  Then I'd explicitly say it's an implementation's choice, but I
can also live with the current wording.

> You mean #3?  Still thinking about it!

Oops, yes, I meant #3.  Sorry about the typo.

> the reply.  If I don't NA in response, the reply will never get to me!

Yeah, I understand that, perhaps I was not clear enough...my point is
that this case may cause longer disruption with proxy ND, so we first
need to have a clear consensus on whether we can accept that (that's
why I said "controversial" referring to comment 2).

> things which have been made redundant by 2461bis and 2462bis!

As I commented on a previous version of the Optimistic DAD draft,
rfc2462bis doesn't talk about regenerating address on duplication.

But rfc2462bis-03 clarifies what "disabling interface" means and when
the node should disable the interface.  So, perhaps we can just refer
to Section 5.4.5 of RFC2462 instead of the description about disabling
interface:

  * (modifies 5.4.5) An Optimistic Address that is determined to be a
  duplicate MUST be deconfigured immediately, and the node takes the
  action described in Section 5.4.5 of RFC2462.

If rfc2462bis becomes an RFC before optimistic DAD, then we'll simply
be able to update the reference to the new RFC.

Meanwhile, requiring to restart DAD with a new address with a SHOULD
seems to me too strong in the context of the goal for optimistic DAD.
I'd prefer to mention the possibility (referring to the appendix)
without using any RFC2119 keyword.

> OptiDAD ... there are other drafts addressing them.

And then we should note that optimistic DAD will create another
possibility of the "first packet" which may require a random delay.

> to US English if that's desired.  Not everyone has egrep handy, I

Note: while I'd like to see consistent spelling for this particular
term, I personally do not care much about the dialect issue, as I said
in my response to Greg.  I'm just providing a suggestion, and it's up
to you whether to introduce the change.

> How about "Alumini?um"?  Do I have to say it funny as well :-) :-) :-)

Based on the rationale of the comment, I don't care:-)

> and all that.  I think 'suffix' is clearer.

But as far as I can see, at least RFC3041 uses the term "interface
identifier", not "suffix".

					JINMEI, Tatuya

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 29 Jul 2004 01:09:15 +0900

>>>>> On Tue, 27 Jul 2004 10:11:02 +1000, 

> of this sort are microscopic.

Sorry, but I don't buy this argument.  First, we all know the odds of
collision are very small for addresses with "almost-unique" IFIDs
(like EUI-64).  But if we can really rely on the low probability so
much, why have we had a discussion on even omitting DAD and rejected
the idea multiple times.  In my understanding, DAD is the mechanism to
minimize the risk of leaving collision as much as possible even if the
base odds are very small.  OptiDAD is trying to introduce compromise
against the base of DAD, considering the tradeoff between the
convenience of mobile/nomadic nodes and increasing the risk of
collision.  We need to be very careful and should basically be
conservative for further optimization (including the advantage we are
talking about in this thread) unless it's crucial for the compromised
operation.

(As I already said) Since the odds of collision are too small, it
should not matter much even if we do not allow the advantage for the
optimistic node.  IMO, the fact that the odds are small should be used
this way (i.e., the reason for not introducing further optimization
that does not have crucial motivation), rather than as the reason for
allowing further optimization.

Besides, I would not call the odds of a simultaneous collision
"microscopic" comparing to the odds of a non-simultaneous collision.
Assuming we have a collision, the simultaneous case can happen when
the colliding nodes start booting at the same time (after a sudden
power-cut, etc).  So, the odds of a simultaneous collision are just as
equally small as the odds of a non-simultaneous one, IMO.  (In any
event, this does not affect my main point, though).

> problems than worrying about the exact balance of probabilities

Sorry, I don't understand this...my point was that if we allow the
advantage for one of the colliding nodes under the situation where the
hardware addresses collide, the result can be more weird and harder to
diagnose (as documented in rfc2462bis, "some things can work and other
things not).  So we should rather just disable the use of the address
as originally specified in the autoconf document.

> non-Tentative addresses are defended rather than surrendered.

Again, sorry, I don't buy this argument.  I think I've already stated
my point on this above, so I won't repeat that here.

> benefit unless the RS includes a SLLAO.

Okay, then it would be nice if the text is clearer on this.

> looking like?  I guess OptiDAD should be updated one they are finalized.

I believe 2462bis is ready to be submitted to the IESG.  I cannot
predict further timetable on it, just like other standardized document
(i.e., I cannot predict when the IESG completes the review of the
document, etc).

I'm not really sure about 2461bis, but in my understanding it's almost
ready for a wg last call.

					JINMEI, Tatuya

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 28 Jul 2004 06:46:46 -0700 (PDT)

> with, e.g., a new ND option that only works for nodes that understand

Agreed.
Depending on how the buffering at the router fits in with other signalling
(DNA etc) it might make sense to add some new "identity token" option (which
could contain the previous CoA of the MN) in the router solicitiation message
as a way to hint to the router that the MN has arrived on the new link.
(Of course, such a token wouldn't be a secure indication that the node has
arrived unless SEND technology or something equally strong is applied).

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.

   Erik

---

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

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

Bear in mind that the RFC2462 DAD process is not 'perfect' either,
as packet loss can cause collisions to go undetected.  I don't 
believe Optimistic DAD significantly increases the risk of disruption
in the case of a collision, and because it allows DupAddrDetectTransmits
to be increased without significant penalty, it actually _reduces_
the probability of an undetected collision.

> as it is crucial to make the optimistic behavior work.

Sure, I'm happy to strip out the unsolicited NAs and leave that sort
of thing to another draft or WG to consider, if that's the consensus of
the group.

> two (colliding) nodes simultaneously perform DAD.  In this case, there

I honestly think that the probability of simultaneous collisions is
so miniscule as to be not worth considering.  As per [SOTO],
"a mobile phone user should be more worried about being killed by
lightning than to have an interface identifier repeated."
And that's the maths considering collisions with a network with
several thousand nodes, not for simultaneous collisions.

> with, e.g., a new ND option that only works for nodes that understand

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

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

-----Nick

[SOTO] draft-soto-mobileip-random-iids-00, now expired: see
http://www.watersprings.org/pub/id/draft-soto-mobileip-random-iids-00.txt