Subject: [Autoconf] Which IPv6 addresses?

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 21:01:48 +0100

Currently the DT draft discourages LLs.

Yet it doesn't mention any of the following: global addresses, multicast 
groups/addresses, anycast addresses, unspecified addresses, ULAs, 
documentation addresses, loopback address, 6to4 prefix (2002::), default 
route prefix (::), CGAs, HBAs, Teredo.  There may be more.  There's talk 
at IETF of "IPv6 short addresses" too.

Some of the above may be yet inappropriate, but none?

Draft only mentions to use a /128 prefix.

So - I wonder - what addresses does AUTOCONF plan to use in the 
practical addressing model?

Or do you plan to request a new IPv6 address type (see after my sig)?

Do we only agree on "no LL, yes /128 unique prefixes"?

Alex

RFC4291:
> 2.4.  Address Type Identification
> 
>    The type of an IPv6 address is identified by the high-order bits of
>    the address, as follows:
> 
>       Address type         Binary prefix        IPv6 notation   Section
>       ------------         -------------        -------------   -------
>       Unspecified          00...0  (128 bits)   ::/128          2.5.2
>       Loopback             00...1  (128 bits)   ::1/128         2.5.3
>       Multicast            11111111             FF00::/8        2.7
>       Link-Local unicast   1111111010           FE80::/10       2.5.6
>       Global Unicast       (everything else)

---

From: Henning Rogge <[email-masked]>
Date: Mon, 26 Oct 2009 21:12:45 +0100

Am Montag 26 Oktober 2009 21:01:48 schrieb Alexandru Petrescu:
> Yet it doesn't mention any of the following:

> global addresses,
do work well
> multicast groups/addresses,
do work well for mesh wide multicast (see SMF). More work for global multicast 
(as always).

> anycast addresses,
do work well

> unspecified addresses,
I don't think they are routed anywhere

> ULAs,
Should work like global ones, unless you get an address conflict

> loopback address,
Do not matter for manet routing as a destination.

> 6to4 prefix (2002::),
should work, because they can be handled like any global IP for routing

> default route prefix (::), 
Do not matter for manet routing as a destination.

> documentation addresses,
> CGAs, HBAs, Teredo.  There may be more.  There's talk

> Some of the above may be yet inappropriate, but none?
I see no special problems with any of them

LLs are special because they assume a closed broadcast domain for DAD running 
well. Manets do not have a closed broadcast domain.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 21:19:49 +0100

> well. Manets do not have a closed broadcast domain.

But Henning, DAD is required for _all_ addresses on a link, not only the 
LLs.

Why do you only LL stuff discouraging?

Alex

---

From: Henning Rogge <[email-masked]>
Date: Mon, 26 Oct 2009 21:27:46 +0100

> But Henning, DAD is required for _all_ addresses on a link, not only the
DAD is nice to have... but I don't see it required for anything except 
autogenerated addresses.

DAD is not even helpful for global IPs... because the range of DAD is 
(according to my knowledge) only 1 hop.
 
> Why do you only LL stuff discouraging?
Okay, let me say it again.

LL assume that your broadcast domain is closed. This way the IP stack can be 
sure that DAD will create a unique LL-IP for the interface.

Unfortunately most mesh networks are not behaving this way. So the semantic of 
LL-generation with DAD is not working correctly.

Henning

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 22:09:36 +0100

Henning Rogge a écrit :
> LL assume that your broadcast domain is closed.

Sorry, I do am open to talk, but what does it mean "broadcast domain 
closed" for IPv6?  Is it the link on which these IPv6 LLs are present? 
IS it  that that link is of definite size somehow?

> This way the IP stack can be 

Yes, considering everybody on the link will hear the unsolicited NAs 
(part of the DAD procedure).

And no, if you consider that that link does not hold anybody together at 
some point, and that people come in and move out of the link when DAD is 
running.

So my node's LL's DAD starts, nobody replies NA to the three successive 
unsolicited NSs, and my node believes its LL is unique.  And sudenly 
afterwards some other node comes in using my IPv6 LL.  So we find both 
using the same LL.

Is this the problem you talk about?  Should we describe this example 
problem in detail (DAD, 3 unsolicited NAs, new member) such that draft's 
reader understand what's meant by this?

If yes, then this problem may be important, because a router trying to 
deliver packets to my node will deliver them to somebody else too, or 
only to somebody else.

> LL-generation with DAD is not working correctly.

Ok - can we describe how it does not work correctly?

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 26 Oct 2009 22:22:36 +0100

>-----Oorspronkelijk bericht-----
>Van: [email-masked] [mailto:[email-masked]] Namens
>Henning Rogge
>Verzonden: maandag 26 oktober 2009 21:28
>Aan: Alexandru Petrescu
>CC: [email-masked]
>Onderwerp: Re: [Autoconf] Which IPv6 addresses?
>

We are her in IETF and we have Standard Track RFCs. They specify otherwise.

Can we all please read the RFCs?

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Oct 2009 22:39:49 +0100

Teco Boot a écrit :
> 
>> -----Oorspronkelijk bericht----- Van: [email-masked]
>> [mailto:[email-masked]] Namens Henning Rogge Verzonden:
>> maandag 26 oktober 2009 21:28 Aan: Alexandru Petrescu CC:
>> [email-masked] Onderwerp: Re: [Autoconf] Which IPv6 addresses?
>> 
>>> But Henning, DAD is required for _all_ addresses on a link, not
>>> only
>> the
>>> LLs.
>> DAD is nice to have... but I don't see it required for anything
>> except autogenerated addresses.
> 

YEs, I agree, I sit all day long and read them.

Moreover, I can not imagine myself doing "ifconfig del fe80:..." on all
the interfaces on all the computers I use simply because this draft says:

> o  no two such interfaces in the network should be configured with 
> the same subnet prefix.

or:

> in general link-local addresses are of limited utility on links with
> undetermined connectivity

I prefer to think that my links have determined connectivity, as offered 
by the link-layer.

And to understand that I go read IEEE documents too.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 07:33:04 +0100

> IS it  that that link is of definite size somehow?
A closed broadcast domain is where you don't have a neighbor on a certain 
interface which broadcast (on the interface it can hear you) can reach someone 
who does not hear your broadcast. It's the same as a transitive/symmetric 'A 
can hear B's broadcast' condition.

> deliver packets to my node will deliver them to somebody else too, or
The problem is that is not enough for MANET interfaces.

Imagine a chain of three nodes A,B,C. All communication ranges are symmetric, 
B can hear A and C, but A cannot hear C (because of too much distance between 
the nodes).

Even with DAD A and C might choose the same linklocal IP address. If they do 
so B is unable to address A and C in a unique way, because of the address 
conflict.

> > Unfortunately most mesh networks are not behaving this way. So the
> > semantic of LL-generation with DAD is not working correctly.
>
In a MANET you need to make sure that LL IPs are unique in each possible 
broadcast domain. In a MANET without movement you can do this by make sure 
that each LL IP is 2-hop unique. In a MANET with movement you must either 
reconfigure your LL on the fly or use mesh-unique LL IPs.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-263,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 10:55:32 +0100

> can hear B's broadcast' condition.

I think it makes sense as I read it.

However, it has no relationship whatsoever with any IEEE document, not 
even with the AUTOCONF document "manetarch" which describes the ABC 
problem too.

That document doesn't use the term "closed broadcast domain".  You seem 
to be very used to it.

We may have a terminology problem here.

People need same terminology in order to understand each other.

> so B is unable to address A and C in a unique way, because of the address 

Can you describe the DAD messages which generate that problem?  With a 
flow chart?  That would be a good candidate to a good problem statement.

> reconfigure your LL on the fly or use mesh-unique LL IPs.

Again, it is very difficult to talk "broadcast" when IPv6 talks all-node 
multicast, and when the manetarch document doesn't talk "broadcast 
domains" either.

These things (broadcast, multicast, all-node, IPv4, IPv6) are very well 
understood in IEEE documents and in IETF documents.

However, we have a hard time understanding each other if we don't use 
the same terminology.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 11:41:27 +0100

Am Tue October 27 2009 10:55:32 schrieb Alexandru Petrescu:
> > interface which broadcast (on the interface it can hear you) can reach
> > someone who does not hear your broadcast. It's the same as a
> > transitive/symmetric 'A can hear B's broadcast' condition.
>
It's an easy way to describe the difference between an ethernet switch (closed 
broadcast domain) and a WLAN MANET (not closed).

> People need same terminology in order to understand each other.
So do you recognize what I mean with "closed/not closed" broadcast ?

> > Imagine a chain of three nodes A,B,C. All communication ranges are
> > symmetric, B can hear A and C, but A cannot hear C (because of too much
> > distance between the nodes).
> >
> > Even with DAD A and C might choose the same linklocal IP address. If they
> > do so B is unable to address A and C in a unique way, because of the
> > address conflict.
>
No... I don't know DAD in this detail. The only thing I was told about DAD 
that it checks only for conflicts at 1-hop (1 layer-2 link away) distance.

And that is (see above) not enough for well behaving LL IPs.

> multicast, and when the manetarch document doesn't talk "broadcast
A broadcast can typically only reach your direct neighbors in the network.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 12:03:15 +0100

> broadcast domain) and a WLAN MANET (not closed).

Well an ethernet switch is not such a closed broadcast domain because I 
can add cables and other switches to it and run link-layer spanning-tree 
protocols (802.1q) on them and they are open.

The same in WLAN.  I can add WLAN repeaters.

> So do you recognize what I mean with "closed/not closed" broadcast ?

Seems as a new definition we may discuss to nail down and put in a 
terminology document.

I do however have hard time talking "broadcast" in the context of IPv6.

We could be talking "broadcast" in terms of a specific link-layer, which 
we should name.

> that it checks only for conflicts at 1-hop (1 layer-2 link away) distance.

Well... yes, DAD acts on a single-hop subnet (it's within the link-local 
scope) - the HopLimit of the base header of the DAD packets are not 
decremented.

And that is good, because link-local addresses are valid only on a 
link-local scope.

If you want to invent a new two-hop scope?  With two-hop-local 
addresses?  And a new duplicate address detection procedure working on 
two-hop scopes?  If so, I don't know what to say, but please don't 
discard LLs, they are fine on their scope.

One should mention the problems of using two times LLs on a link-local 
scope, before engaging on two-hop scopes.  And thus make me understand 
why the two-hop scope is necessary.

For example - why a two-hop scope and why not a three-hop scope?

> And that is (see above) not enough for well behaving LL IPs.

Would using two times a single-hop LL fit your two-hop need?

For example, a router with two interfaces, attached thus to two 
link-local "1-hop" scopes, using a LL on each of its interface.  Would 
this be able to run a routing protocol?  I believe so, OSPF does so.

I am not sure why you need a two-hop scope and addresses valid on 
two-hop scopes.

> A broadcast can typically only reach your direct neighbors in the network.

Well, hmm, IPv6 doesn't use the term "broadcast" but "all-node 
multicast".  There is even a finer grained distinction, like "all-hosts" 
  or "all-routers" or "all-ntp servers".  These have different scopes: 
node, interface, host, link, site, global, etc.  The working on this 
relies on the good working of IP multicast such as MLD and of link-layer 
multicast (IEEE MAC reused on many IEEE protocols).

So in this, I would avoid the use of the term "broadcast" when talking IPv6.

IPv4, and old Ethernet MAC implementations, do use the term "broadcast". 
  For example, there is an IPv4 "broadcast" address 255.255.255.255 
(there's no such equivalent all-1s in IPv6) and an Ethernet "broadcast" 
address "ff:ff:ff:ff:ff:ff".  This latter is not used by IPv6 under any 
form, but it uses "33:33::1" which is called a link-layer multicast 
address.  That's why I suggest to not use the term "broadcast" when 
talking IPv6.

If I were you I would dig for all the IPv6-over-foo RFCs to see whether 
they use the term "broadcast" or not.  I believe there is even an effort 
to write a document listing all link layers on which IPv6 runs, and how.

Also, when you say neighbors, I believe them to be discovered by ND, 
which you don't seem to.

IT is good to get in sync about terminology.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 17:10:40 +0100

Am Dienstag 27 Oktober 2009 12:03:15 schrieb Alexandru Petrescu:
> > It's an easy way to describe the difference between an ethernet switch
> > (closed broadcast domain) and a WLAN MANET (not closed).
> 
Which doesn't change that a group of connected ethernet switches is still a 
closed domain (it's still transitive/symmetric connectivity).

All connected interfaces are in 1-hop (IP-)range of each other on switches. No 
amount of cable and other switches will change this.
 
> The same in WLAN.  I can add WLAN repeaters.
No. please read my former mails again, especially the example.

On the other side you could try to find a configuration of ethernet switches 
where a IPv4 broadcast will not be transitive or symmetric. I'm curious about 
it.
 
> I do however have hard time talking "broadcast" in the context of IPv6.
"Broadcast" is a common term for MANETs... You will find it in most of the 
older RFCs. For packetBB there has been an updated specification what kind of 
'send to all neighbors' IPs a MANET protocol should use. You will find it in 
RFC 5498 (IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols).

> And that is good, because link-local addresses are valid only on a
Exactly...
 
> I am not sure why you need a two-hop scope and addresses valid on
Think about the A-B-C WLAN scenario again.

each of them has one interface

if A and C choose the same LL-IP DAD would not detect it, because A and C are 
not in one-hop distance.

But suddenly B would not be able to use A's and C's LL-IP to address them, 
because they are both on the same interface of B.

Do you see it ?

Henning

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 27 Oct 2009 09:48:00 -0700

Hello Alex,

Alexandru Petrescu wrote:
>
>> It's an easy way to describe the difference between an ethernet 
>> switch (closed broadcast domain) and a WLAN MANET (not closed).
>
> Well an ethernet switch is not such a closed broadcast domain because 
> I can add cables and other switches to it and run link-layer 
> spanning-tree protocols (802.1q) on them and they are open.
>

This is nonsense.  It is wrong in this context to compare the rate
of change of topology in a switched Ethernet system against that
rate in a wireless system.

But at least it gives us a good clue into your justification for
DAD and NUD signaling overheads.

> We could be talking "broadcast" in terms of a specific link-layer, 
> which we should name.

You should look at the earlier document on this point
from Emmanuel and myself.

> >
>> No... I don't know DAD in this detail. The only thing I was told 
>> about DAD that it checks only for conflicts at 1-hop (1 layer-2 link 
>> away) distance.
>
> Well... yes, DAD acts on a single-hop subnet (it's within the 
> link-local scope) - the HopLimit of the base header of the DAD packets 
> are not decremented.
>

You're getting warm here.

> discard LLs, they are fine on their scope.

A scope which, in wireless networks we're interested in, basically 
doesn't exist on
any timescale useful for protocol signaling.

> For example - why a two-hop scope and why not a three-hop scope?

Precisely.  Why not a ten-hop scope?

We did that.

> Would using two times a single-hop LL fit your two-hop need?

That would be a great deal sillier than just working around the
problem.

As has been done many times in the past.

Which is why the practitioners wanted to have a
working group to standardize a solution.

Which you keep ignoring.

> I am not sure why you need a two-hop scope and addresses valid on 

Because the range of packet capture does not extend across the
entire MANET.

> multicast".  There is even a finer grained distinction, like 
> "all-hosts"  or "all-routers" or "all-ntp servers".  These have 
> different scopes: node, interface, host, link, site, global, etc.  The 
> working on this relies on the good working of IP multicast such as MLD 
> and of link-layer multicast (IEEE MAC reused on many IEEE protocols).
>

We can avoid the use of that term.
But it's O.K. for people who understand
each other to use terminology that they
understand.  It's only when others want
to nitpick about it that we have to be
more careful.

>
> IPv4, and old Ethernet MAC implementations, do use the term 
> "broadcast".  For example, there is an IPv4 "broadcast" address 
> 255.255.255.255 (there's no such equivalent all-1s in IPv6) and an 
> Ethernet "broadcast" address "ff:ff:ff:ff:ff:ff".  This latter is not 
> used by IPv6 under any form, but it uses "33:33::1" which is called a 
> link-layer multicast address.  That's why I suggest to not use the 
> term "broadcast" when talking IPv6.
>
> If I were you I would dig for all the IPv6-over-foo RFCs to see 
> whether they use the term "broadcast" or not.  I believe there is even 
> an effort to write a document listing all link layers on which IPv6 
> runs, and how.
>
Neighbors can deliver packets to each other directly, regardless
of whether or not that capability is discovered by ND.

This is also discussed at length in the Baccelli/Perkins draft that
you have read in the past.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 17:52:48 +0100

> amount of cable and other switches will change this.

Yes, ok.

The same with wifi.  They have a range of 50meters.  You could extend 
that with more wifi cards/APs but no amount of cards/APs will open it, 
it's a "closed domain".

Just because WiFi is deployed often outside and the switches often in a 
cabinet doesn't make any one of them more close than the other.

> No. please read my former mails again, especially the example.

You mean I can not add a WLAN repeater?  I have already done that - why 
do you want me to not do it?

Other people added WLAN PHY range extender antennas, up to 2km - do you 
want them to not do it too?

> where a IPv4 broadcast will not be transitive or symmetric. I'm curious about 

Hmm... probably playing a bit with the myriad of the 802.1q config 
parameters?  Why should I try?

> "Broadcast" is a common term for MANETs...

MANET speakers should change the terminology when talking IPv6 and 
broadcast.

 > You will find it in most of the
> older RFCs.

Hmm... I hope this is not important.  Please mention one such MANET RFC 
talking IPv6 and broadcast and I will remark to it in the appropriate WG.

> For packetBB there has been an updated specification what kind of 

Right, and that RFC says "multicast" for IPv6, not "broadcast" for IPv6. 
  I think it doesn't say "broadcast" even for IPv4, but also "multicast".

Your use of "broadcast" just because MANET speakers used it historically 
makes one think that one could use the term "broadcast" freely, like for 
example if I want to say "broadcast TV" which is wireless, and which 
pertains to IPv6 too (IPv6-over-DVB).

I think we should be using the "broadcast" term in a non-ambiguous way 
as much as possible, such that to better understand each other.

> if A and C choose the same LL-IP DAD would not detect it, because A and C are 

DAD running on which machine?  You seem to think DAD on B won't detect A 
and C have the same address, which may be truly true.

Also, DAD on A won't detect C having same address, and vice-versa, 
because they're too far apart.  Ok.

Nodes far apart cant talk to each other regardless of the addresses 
being duplicated.

> because they are both on the same interface of B.

Sorry, I don't  see it.  Who runs DAD?

Normally every machine runs DAD.  If A and B are close enough to hear 
each other and both run DAD then the duplicate between A and B is 
detected.  Same for B and C.

So, if A's address is not duplicated at B, and B's address is not 
duplicated at C - then A and C use distinctive addresses.  Which seems a 
rather happy situation to be in.

Don't you think so?

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 19:08:57 +0100

Am Dienstag 27 Oktober 2009 17:52:48 schrieb Alexandru Petrescu:
> > All connected interfaces are in 1-hop (IP-)range of each other on
> > switches. No amount of cable and other switches will change this.
> 
> Yes, ok.
Good, finally some aggreement.
 
> that with more wifi cards/APs but no amount of cards/APs will open it,
Your are missing that a group of WLAN nodes on the same channel has not 
necessarily symmetric or transitive connections.

Ethernet cards connected to a switch (or a group of connected switches) do.

> want them to not do it too?
Sorry, you are again evading the important point.

With WLAN you CAN (often) have situations where the layer-2 connectivity is 
neither transitive nor symmetric. With ethernet it is always transitive and 
symmetric for all interfaces connected to a switch (or a group of connected 
switches).

> > if A and C choose the same LL-IP DAD would not detect it, because A and C
> > are not in one-hop distance.
> 
> DAD running on which machine? 
all of them.

> You seem to think DAD on B won't detect A
 
> Nodes far apart cant talk to each other regardless of the addresses
Yes, but if A and C (which cannot talk to each other) have the same LL-IP, 
then B cannot talk to them either, because both A and C have the same IP !
 
> > But suddenly B would not be able to use A's and C's LL-IP to address
> > them, because they are both on the same interface of B.
> >
> > Do you see it ?
> 
all of them
 
> rather happy situation to be in.
No.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 19:20:36 +0100

Henning Rogge a écrit :
[...]
> then B cannot talk to them either, because both A and C have the same IP !

Ah!, I start to see what you mean.

However, what is the problem when A sends a packet and both B and C 
receive it?  I can only vaguely see something, but not sure.

Know too that this kind of wrong link-layer configuration (A far from C 
and B in between) can be done with longer than specified Ethernet cables 
too.  I.e. it's not specific to MANET.  People can artifically create 
problems by ignoring how their link-layers work.

The "hidden terminal problem" which seems to be behind this story too, 
has already been addressed and solved during 802.11b design, long ago, 
at link-layer: DCF.

Alex
PS: and yes, I know, you want to do AUTOCONF and I will not stop you
     from doing so.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 19:25:02 +0100

> problems by ignoring how their link-layers work.
In ethernet it would be "ignoring the linklayer parameters" or maybe a bad 
switch.

In IEEE 802.11 based MANETs it's a typical situation !
 
> has already been addressed and solved during 802.11b design, long ago,
IEEE 802.11 DCF does only work with access points. MANETs run in adhoc-mode.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 19:28:31 +0100

> IEEE 802.11 DCF does only work with access points. MANETs run in
Sorry, PCF needs an access point...

But DCF does only help against collisions, which is not the problem here.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 19:36:30 +0100

> In ethernet it would be "ignoring the linklayer parameters" or maybe a bad 

It would be longer-than-specified cables.

> In IEEE 802.11 based MANETs it's a typical situation !

Well - I have never seen this situation.  I do take a lot of time 
planning WiFi networks, I did it several times.  I follow the manuals.

There is this 50m rule which should not be tresspassed, as there is a 
length limit on the Ethernet cable.  There is also the channel planning.

As for building larger wifi networks, please put repeaters or real 
routers in between.

As for them moving too non-deterministically - is the same thing that 
may come back at you with somehing new you may design.

> IEEE 802.11 DCF does only work with access points. MANETs run in adhoc-mode.

So put an access point there, if so is the need.  An AP does not 
necessarily mean you need 220V power - it could run on battery and 
without any cables, it could be mobile.  Moreover, it could be the 
hostap software on linux PDA or smaller - what's wrong with that?

Have you somehow decided that MANET is _only_ adhoc mode (and not AP 
mode)?  Why so?

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 19:40:54 +0100

Am Dienstag 27 Oktober 2009 19:36:30 schrieb Alexandru Petrescu:
> > In ethernet it would be "ignoring the linklayer parameters" or maybe a
> > bad switch.
> 
Either way it would be something stupid done on layer 8.
 
> may come back at you with somehing new you may design.
Sorry, you miss the point in MANETs. Many of them are not preplanned by a 
single entity, many of them have mobile nodes and many of them have no fixed 
infrastructure.

> Have you somehow decided that MANET is _only_ adhoc mode (and not AP
It's the NORMAL use case for MANETs.

I know a lot of MANETs. I have read a lot of papers on them. NONE of them 
suggested running a IEEE 802.11 based MANET in access point mode. NONE.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 19:48:44 +0100

Henning Rogge a écrit :
> I know a lot of MANETs. I have read a lot of papers on them.

Good.

> NONE of them 

Why did they avoid the AP mode?  What's wrong with it in MANETs?  APs 
can be as small and mobile as any other non-AP nodes.

The 802.11b association procedure is the same when doing AP mode or 
adhoc mode - the messages are the same.  The WEP and WPA security is 
also available in both modes.  What's wrong with ap mode?

?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 19:55:04 +0100

Alexandru Petrescu a écrit :
>> Sorry, you miss the point in MANETs. Many of them are not preplanned 
>> by a single entity, many of them have mobile nodes and many of them 
>> have no fixed infrastructure.
>>
>> NONE of them suggested running a IEEE 802.11 based MANET in access 
>> point mode. NONE.
> 
> adhoc mode - the messages are the same.

I meant the essential messages ^

(ap mode has usually messages than adhoc mode, sometimes yes, no,
  depending on implementaiton)

I am still wondering why MANETs dont want to use wifi ap mode? (even 
without connecting to the infrastructure, and without 220V available, no 
cables - just one PDA doing hostap).  What's so wrong about it?

Alex

   The WEP and WPA security is

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Oct 2009 20:33:39 +0100

Am Dienstag 27 Oktober 2009 19:48:44 schrieb Alexandru Petrescu:
> also available in both modes.
WPA2 is not implemented for most adhoc capable cards.

> What's wrong with ap mode?
AP mode does not work well for MANET, because they are designed for a 
centralized controll point in the network. A MANET in AP mode would be forced 
that EVERY node is an AP and all nodes have to be clients of all their 
neighbors to be able to build a MANET. This configuration is not supported by 
most WLAN stacks

And you loose the advantages of AP mode as soon as you have multiple APs with 
overlapping ranges (hidden station APs). Neither PCF nor DCF make sense in 
this configuration, because there is no single controller which can decide 
that airtime is now "reserved" for it's area of interest.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 27 Oct 2009 21:22:34 +0100

Henning Rogge a écrit :
>>> NONE of them suggested running a IEEE 802.11 based MANET in 
>>> access point mode. NONE.
>> Why did they avoid the AP mode?  What's wrong with it in MANETs? 
>> APs can be as small and mobile as any other non-AP nodes.
>> 
>>  adhoc mode - the messages are the same.  The WEP and WPA security 
>> is also available in both modes.
> 

Ok for "most" and except WPA-NONE which is. (it is secure too).  But I 
think you prefer adhoc mode anyways, which is good for WPA-NONE.

>  centralized controll point in the network.

The link-layer AP wifi is centralized, yes, but the IP on top of it
  not so - DAD running on AP and on Client is fully equipotential
(distributed): AP and Client send same NS/NA messages.

For AUTOCONF: I believe the ABC problem does not apply as a problem and 
can't lead to an AUTOCONF solution solving it.

> A MANET in AP mode would be forced that EVERY node is an AP and all
> nodes have to be clients of all their neighbors to be able to build a
> MANET. This configuration is not supported by most WLAN stacks

Ok, I agree on that.

Let me write my point this way:

If two nodes are too far apart - don't put a single IP subnet between 
them with a fooled node in the middle.  Better have two subnets one for 
AB and one for BC.  No need to use /128 prefixes, no need to avoid LLs.

If an AP can help here and there then use it, following the wifi manuals.

I will write again separately about ABC problem.

> And you loose the advantages of AP mode as soon as you have multiple 
> APs with overlapping ranges (hidden station APs).

YEs - make sure to not overlap the AP ranges.  It's a wifi guidance 
ensuring connectivity ok.

> Neither PCF nor DCF make sense in this configuration, because there
> is no single controller which can decide that airtime is now
> "reserved" for it's area of interest.

Right.

I believe though this is a matter of good planning of the use of the 
link layer, without which the link-layer breaks.

And yes, I know, MANET is unplanned network.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 08:31:22 +0100

>has already been addressed and solved during 802.11b design, long ago,

I wish this was true!

Maybe DCF partly solves problems for unicast.
For multicast, there is not much out there
that helps the hidden terminal problem.

Regards, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 28 Oct 2009 08:36:11 +0100

>Henning Rogge wrote:

DCF: distributed coordination function
This is the mode used in all modes, including IBSS.
IBSS is often called adhoc mode.

Regards, Reco