Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested.

From: Teco Boot <[email-masked]>
Date: Fri, 20 Apr 2007 22:05:00 +0200

I still think building strong DAD for EUI-64 or true random Interface ID
generation is a waste of time and should have extremely low priority.
Strong DAD for manual configured addresses or IPv4 link locals could be
useful. I'll be thankful for adding this information to the PS document.
Teco

> -----Original Message-----
> From: Templin, Fred L [mailto:[email-masked]]
> Sent: dinsdag 17 april 2007 17:35
> To: Emmanuel Baccelli; [email-masked]
> Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested.
> 
> > > On DAD, RFC4429 discusses probability of collisions. At
> > time of writing,
> > > there was a discussion on wireless interfaces and DAD, the
> > interface has no
> > > state change when moving and thus the DAD is not triggered. A 
> > > reason accepting a risk on collisions is that interface IDs should
> > be unique if
> > > burned in L2 addresses are used and collisions are
> > extremely rare if truly
> > > random interface IDs are generated. What is the reason for
> > a new mechanism?
> > > It could be DAD for manual configured addresses, but why
> > use these on a
> > > MANET interface? Or support for IPv4 Link Local addresses?
> >
> >
> > As far as I understand, aside from the address generation aspect, 
> > RFC
> > 4429 does not address multihop detection, and does not deal with the 
> > standalone (no connection to the infrastructure) case. So in this 
> > regard, new DAD mechanisms are needed, if the scenario needs DAD.
> 
> Because of partitions/merges/node movements, as far as I can tell the 
> only way RFC4429 can absolutely assure address uniqueness in MANETs is 
> if the optimistic nodes were to keep their addresses in the optimistic 
> state indefinitely (e.g., by setting 'DupAddrDetectTransmits' to some 
> value representing infinity). That would entail 1) having the 
> optimistic node proactively sending NS every RetransTimer msec, and 2) 
> sending initial packets through a default router and only taking 
> direct paths to neighbors after receiving a Redirect.
> This might not be optimal for all node types and networks.
> 
> RFC4429 does make the case that by the Birthday Paradox the odds of 
> collision when using random self-generated addresses like CGAs is 
> "vanishingly small", but unless a node remains "permanently 
> optimistic" an unrecoverable collision is possible.
> (Of course, the odds of collision for manually-configured or 
> administratively-assigned addresses is *much* higher.)
> 
> Fred
> [email-masked]
> 
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/autoconf

_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Apr 2007 13:16:36 -0700

> generation is a waste of time and should have extremely low priority.

Other communities (e.g., NETLMM) have pushed back hard when
I have raised this same point with them and have stipulated
a hard requirement for address uniqueness assurance even for
(pseudo)random interface IDs. Their argument is that there
can be no dropped calls in an operator's network due to an
address collision, no matter how unlikely the event of a
collision.

Fred

---

From: mase <[email-masked]>
Date: Sat, 21 Apr 2007 11:51:02 +0900

Dear Teco,

Thank you for your comments. I am thinking to add the following 
remarks in the end of
4.3.2.  Address Uniqueness Requirements of the draft. Does this 
account for your concern?

Thanks,
Kenichi

"The need for checking uniqueness of addresses that are to be 
assigned or already assigned and used may depend on the possibilty of 
address conflicts and the amount of the overhead for checking 
uniquenes of addresses. For example, if the former is extremely low 
and the latter is significant, checking uniqueness of addresses may 
not be used. If the former is not extremely low, checking uniquenss 
of addresses should be used.  "

---

From: [email-masked]
Date: Sat, 21 Apr 2007 09:23:22 +0200

Text is fine, thanks. Teco

Quoting mase <[email-masked]>:

> Dear Teco,
>
> Thank you for your comments. I am thinking to add the following remarks
> in the end of
> 4.3.2.  Address Uniqueness Requirements of the draft. Does this account
> for your concern?
>
> Thanks,
> Kenichi
>
> "The need for checking uniqueness of addresses that are to be assigned
> or already assigned and used may depend on the possibilty of address
> conflicts and the amount of the overhead for checking uniquenes of
> addresses. For example, if the former is extremely low and the latter
> is significant, checking uniqueness of addresses may not be used. If
> the former is not extremely low, checking uniquenss of addresses should
> be used.  "
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 21 Apr 2007 06:30:07 -0700

> assigned or already assigned and used may depend on the possibilty
> of address conflicts and the amount of the overhead for checking
> uniquenes of addresses. For example, if the former is extremely
> low and the latter is significant, checking uniqueness of addresses
> may not be used.

That would be inconsistent with the position taken by the
NETLMM wg, where the only technical reason given for not
allowing shared media (such as MANETs) as access links was
the possibility of collisions even for (pseudo)random
addresses that are highly likely to be unique.

Fred

---

From: mase <[email-masked]>
Date: Sun, 22 Apr 2007 12:10:02 +0900

Hi, Fred,

Thank you for your comments. My comments are in line.

>addresses that are highly likely to be unique.

Besed on your comments, I would propose to modify the text as follows:

"The need for checking uniqueness of addresses that are to be 
assigned or already assigned and used may depend on the possibilty of 
address conflicts, the amount of the overhead for checking uniquenes 
of addresses, and address uniqueness requirement from applications. 
For example, if the former is extremely low and the latter is 
significant, checking uniqueness of addresses may not be used. If the 
former is not extremely low, checking uniquenss of addresses should 
be used. If the application has a hard requirement for address 
uniqueness assurance, checking uniqueness of addresses should be 
always used no matter how unlikely the event of addres conflict."

I woudl appreciate your comments.
Thanks,
Kenichi

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 22 Apr 2007 22:06:06 -0700

Hello Mase,

Your text is O.K. with me.  However, I want to take issue
with the suggestion that we have to be restricted by the way
things are done in [netlmm].  It seems to me that working
group has, at best, very rough consensus, and maybe the
people who don't agree have just bailed out in despair.
I think that the underlying model of operation in [netlmm]
is so radically different than what is envisioned for at hoc
networks, that almost no comparison is possible.  So,
it would be a mistake to accept the same restrictions on
the design space that they have accepted.

Regards,
Charlie P.

ext mase wrote:
> conflicts, the amount of the overhead for checking uniquenes of 
> addresses, and address uniqueness requirement from applications. For 
> example, if the former is extremely low and the latter is significant, 
> checking uniqueness of addresses may not be used. If the former is not 
> extremely low, checking uniquenss of addresses should be used. If the 
> application has a hard requirement for address uniqueness assurance, 
> checking uniqueness of addresses should be always used no matter how 
> unlikely the event of addres conflict."
>

---

From: mase <[email-masked]>
Date: Mon, 23 Apr 2007 14:36:04 +0900

Hello Charlie,

Thank you for your comments and suggestions. I agree with you.
I tried to make the text so that it did not introduce any 
restrictions for MANET problem statement.
I would refine the text together with the co-authors.

Thanks,
Kenichi

At 14:06 07/04/23, Charles E. Perkins wrote:

>>of address conflicts, the amount of the overhead for checking 
>>uniquenes of addresses, and address uniqueness requirement from 
>>applications. For example, if the former is extremely low and the 
>>latter is significant, checking uniqueness of addresses may not be 
>>used. If the former is not extremely low, checking uniquenss of 
>>addresses should be used. If the application has a hard requirement 
>>for address uniqueness assurance, checking uniqueness of addresses 
>>should be always used no matter how unlikely the event of addres conflict."
>>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 Apr 2007 07:26:12 -0700

Charlie,

> things are done in [netlmm].

It is not the point at all that MANET/Autoconf should
be compared with NETLMM; rather, NETLMM is a network-
based service and MANET/Autoconf is an access technology
that could be used in a NETLMM domain. The point is that
it was said in the NETLMM wg that MANET/Autoconf would
not be supported as an access technology because of the
DAD uncertainties - even when self-generated addresses
like CGA are used. That is what I mean by an inconsistency
should this wg now go ahead and say "let's just forget
about DAD".

There is another angle to this discussion too which is
sure to cause a rathole but was brought up by Jinmei in
a different wg. What if not all nodes in the network use
the same (pseudo)random address generation scheme, i.e.,
what if some nodes use the scheme and others use other
mechanisms like DHCP or manual config? All birthday
paradox considerations go out the window when not all
nodes implement the same address generation scheme.

Fred