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

From: "Teco Boot / C2SC" <[email-masked]>
Date: Tue, 24 Apr 2007 08:25:53 +0200

For random addresses, it is not important if others use manual, dhcp or
whatever. 
For EUI64, some malware / misuse / bugs could be in place. If so, DAD could
be disabled also. So DAD doesn't realy help for these.
Manual addresses configured explicitly for spoofing cannot be protected by
DAD also. SeND would be an option here.
Teco

> -----Original Message-----
> From: Templin, Fred L [mailto:[email-masked]]
> Sent: maandag 23 april 2007 16:26
> To: Charles E. Perkins; ext mase
> Cc: [email-masked]
> Subject: RE: [Autoconf] Re: Updated Problem Statement. Review requested.
> 
> Charlie,
> 
> > 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 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
> [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: Emmanuel Baccelli <[email-masked]>
Date: Tue, 24 Apr 2007 12:46:42 +0200

Folks,

I think we are getting carried away. The problem statement must only 
give the gist of issues concerning acquireing IPv6 addresses for 
configuration of interfaces on MANET nodes.

In that respect, I would like to see the debate not go too much in the 
solution space. That is: depending on the scenario, and the address 
generation scheme that is used, DAD is more or less needed, granted. But 
this is not in contradiction with what is in the problem statement for now.

The only things we should be looking at in the Problem statement are 
issues that have to do with:

- providing automatic configuration of MANET-local prefixes (or 
addresses) to each MANET router, whether a MANET Border Router is 
reachable or not.

- if checking uniqueness within a given multi-hop scope is needed, 
providing automatic detection and resolution of duplicated prefixes (or 
addresses) within this scope.

- if one or more MANET Border Router is reachable, providing automatic 
configuration of global prefixes (or addresses) to each MANET router.

Emmanuel

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 24 Apr 2007 08:07:51 -0700

Teco,
 
> For random addresses, it is not important if others use 
> manual, dhcp or whatever.

Based, on my read, the birthday paradox calculations
presume a random assignment scheme being used by all
nodes. Therefore, if some nodes use the scheme and
others do not the calculations cannot accurately
estimate the probability of collision. Again, this
issue has been brought up in other working groups.

Fred

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 25 Apr 2007 10:59:45 +0200

sorry for jumping in, but I couldn't resist to comment:

> manual, dhcp or

If some nodes in the network don't use random IPv6 addresses, but
manually assign addresses, or if EUI64-based IPv6 addresses are not
unique due to bugs/misuse, the probability of address conflicts in the
network should be higher than with only random addresses. So this is an
argument to mandate DAD IMO.

Regarding the case that some nodes may disable DAD: 
- If DAD is mandated in the standard, nodes cannot disable it without
violating the standard. Or do you propose to defend against
implementations that don't follow the standard? 
- Furthermore, some in-service DAD solutions allow the other conflict
partner or some intermediate nodes to detect the address conflict, even
if one conflict partner has disabled DAD. 

> DAD also. SeND would be an option here.

Although DAD is not able prevent spoofing attacks, in-service DAD
solutions may be able to detect address spoofing attacks in MANETs.

Another benefit of DAD: it can even reduce the routing protocol overhead
in case of random address assignment. This is due to the following
trade-off: with increasing length of the random part of a node's
address, the probability of conflits decreases. This is good, but the
address compression efficiency and hence the routing protocol overhead
may increase at the same time, if some kind of address compression is
applied to addresses in routing protocol packets (such as the address
blocks in packetbb). The reason is that the common part of the address
(which is the redundant information utilized for the compression) gets
smaller with increasing length of the random part of the address. Since
the reduction of routing protocol overhead due to address compression
can be significant especially in case of IPv6 (up to 90%, see, e.g.,
Kilian Weniger, "PACMAN: Passive autoconfiguration for mobile ad hoc
networks", IEEE Journal on Selected Areas in Communications, vol. 23,
no. 3, Mar 2005  pp. 507-519) and the gain in terms of overhead
reduction can be much higher than the overhead introduced by some DAD
solutions, the use of DAD can even reduce the overall signaling
overhead. 

My two cents,

Kilian

> > [email-masked]

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: Teco Boot <[email-masked]>
Date: Wed, 25 Apr 2007 11:22:46 +0200

No misunderstanding, I never suggested disabling DAD and I never will. The
problem with MANET DAD is single-hop probing, so two nodes could meet with
duplicate addresses, where both did perform DAD but did not see each other
at that time.
Performing multi-hop DAD and repeating DAD for detecting duplicates when
MANETs merge may introduce high overhead. DAD is useful and needed where
duplicates are likely and have less usage where duplicates are extremely
rare. Proposed text in PS was OK for me. 
Teco 

> From: Kilian Weniger [mailto:[email-masked]]
> Sent: woensdag 25 april 2007 11:00
> To: Teco Boot / C2SC; Templin, Fred L; Charles E. Perkins; ext mase
> Cc: [email-masked]
> Subject: RE: [Autoconf] Updated Problem Statement. Review requested.
>

---

From: Shubhranshu <[email-masked]>
Date: Wed, 25 Apr 2007 20:04:28 +0530

----- Original Message ----- 
From: "Kilian Weniger" <[email-masked]>

> sorry for jumping in, but I couldn't resist to comment:

Your comments are appreciated. One important purpose of this mailing list is to 
discuss technical details of Ad-hoc network autoconfiguration, within the scope of the
WG charter.  

- Shubhranshu

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Apr 2007 08:13:02 -0700

Kilian,

Thanks for this; the in-service DAD proposals I think
bear close consideration but do they apply only to the
proactive routing protocols or also for reactive routing
protocols?

I won't tout this as a preferred in-service DAD solution,
but a "greedy" method would be to have MANET nodes treat
addresses they assign to MANET interfaces as "permanently
optimistic" (in the RFC4429 sense). That way, the optimistic
nodes would perpetually rerun DAD every RetransTimer msec
and detect and react appropriately to duplicates that may
have occurred during network partitions/merges. But again,
would this cover only the proactive routing protocols or
also the reactive ones?

Thanks - Fred

> Sent: Wednesday, April 25, 2007 2:00 AM

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 25 Apr 2007 09:45:30 -0700

Hello Teco,

I think we need to distinguish between "Pre-service"
requirements and "In-service" requirements (to use the language
of the draft). I reckon multi-hop DAD is typically required
for pre-service assignment, but not so for in-service DAD.

In order to have in-service DAD, someone has to figure
out how to avoid a flood of address checking every time
any node in the manet briefly goes out of service.

Regards,
Charlie P.

---

From: mase <[email-masked]>
Date: Thu, 26 Apr 2007 09:22:22 +0900

Hello Charlie,

My comments are in line.

>for pre-service assignment, but not so for in-service DAD.

Right, if multi-hop DAD means a kind of strong DAD.
In-service DAD should of course work as multi-hop DAD (should 
discover address conflict between nodes beyond one hop. Passive DAD 
is one of the solutions for in-service DAD.

>any node in the manet briefly goes out of service.

When a node comes back after out of service, it may acquire a new 
tentative address and perform pre-service DAD or it may decide to use 
the same address it used before out of service and directly enter the 
state with in-service DAD. We may use passive DAD to avoid a flood of 
address uniqueness checking. Of course this discussion is for the 
solution space and not in the scope of PS draft.

Regards,
Kenichi

>rare. Proposed text in PS was OK for me. Teco

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 26 Apr 2007 09:20:15 +0200

Hi Fred,

I think just as routes can be discovered proactively or on-demand, DAD
could also be done proactively or on-demand. Whether this is desirable
is another question. 

On-demand DAD would mean that DAD for an address is triggered, when a
node with this address gets involved in a unicast-based application
session with another node in the MANET. Of course, on-demand DAD may
introduce delay for the first data packets, similar to an on-demand
route discovery. Furthermore, nodes that are not involved in unicast
application sessions may have duplicate addresses, but that may be ok as
long as the nodes do not use the duplicate address.

We have done some analysis and simulations with Passive DAD for AODV,
where nodes detect conflicts passively by analyzing the routing protocol
msgs that are sent by AODV (see the paper I references below). It works
if expanding-ring-search is not used (at least not for the initial route
discovery).

Regards,

Kilian

> Sent: Mittwoch, 25. April 2007 17:13
> To: Kilian Weniger; Teco Boot / C2SC; Charles E. Perkins; ext mase
> Cc: [email-masked]