Subject: [Autoconf] Question regarding use of LLs

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 13 Nov 2009 16:33:13 +0100

Hi all,

	During the last meeting, it was said several times that even if the
uniqueness of link-local was not an issue, LLs have other problems that
make it reasonable to discourage their use in MANETs. Can anybody please
be so kind of summarising those for me? this is not that obvious to me.

	Thanks in advance.

	Carlos

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 13 Nov 2009 13:40:26 -0800

Hello Carlos,

Where is the link on which the link-local is local?
Do you want it to be the whole MANET?  For any
two nodes X and Y, not within range, how does
X decide if Y is on-link?  Do you require multi-hop
signaling for on-link operations?  If so, how do you
justify forwarding a link-local address?  They're
not supposed to be forwarded, are they?

I'm not saying these questions are impossible to
answer.  I think they are hard to answer, and that
the answers serve only to fragment a solution space
that could otherwise usefully be applicable to a much
wider class of ad hoc networks.  Furthermore, your
answer might be quite unlikely to resemble another
person's answer.  Furthermore, certain popular
classes of answers implicitly suppose an unscalable
volume of signaling.

I really really think there should be a design team
to do link-local.

Regards,
Charlie P.

Carlos Jesús Bernardos Cano wrote:
> ------------------------------------------------------------------------
>
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf
>

---

From: "Teco Boot" <[email-masked]>
Date: Sun, 15 Nov 2009 19:35:14 +0900

I posted LL text for the draft, with explanation of the LL problem.
http://www.ietf.org/mail-archive/web/autoconf/current/msg01828.html

Here another copy:
   Routers cannot forward any packets with link-local source or
   destination addresses to other links (as per [RFC4291]). In general,
   routers do not forward such packets. This would limit connectivity
   between MANET nodes. For this reason, link-local addresses shall be 
   used only for protocols that require one-hop limited delivery of packets.

This is the only argument on not using LLs that withstands any criticism.
Even Alex can agree on this text. Alex?

Teco.

>-----Oorspronkelijk bericht-----
>Van: [email-masked] [mailto:[email-masked]] Namens
>Charles E. Perkins
>Verzonden: zaterdag 14 november 2009 6:40
>Aan: [email-masked]
>CC: [email-masked]
>Onderwerp: Re: [Autoconf] Question regarding use of LLs
>
>
>Hello Carlos,
>
>that could otherwise usefully be applicable to a much>wider class of ad hoc
networks.  Furthermore, your

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 16 Nov 2009 08:23:57 +0100

Hi Charlie,

> Where is the link on which the link-local is local?

The link is defined by the topological area within a packet with an IPv4
TTL or IPv6 Hop Limit of 1 can be delivered. The area is given by the
radio-range coverage of the wireless technology used.

> Do you want it to be the whole MANET?  For any

No, I don't.

> signaling for on-link operations?  If so, how do you

No, I don't. A link is single-hop.

> not supposed to be forwarded, are they?

No, link-locals are not forwarded. I think I've already said this, I
don't want to change the semantics of link-locals, I just want to be
able to keep using them in MANETs.

> answer.  I think they are hard to answer, and that

well, for me the answers are pretty straightforward :-D

> person's answer.  Furthermore, certain popular

This I agree.

> classes of answers implicitly suppose an unscalable

Well, this is solution space and I tend to disagree.

Thanks,

Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 10:13:59 +0100

> Even Alex can agree on this text. Alex?

Teco - I agree with your suggested text above about LLs.  It does make 
sense - it reflects the only restriction of LLs - they're valid on a 
single link.  I support inserting it in the draft.

If you're interested in improving it...

When you say that this would limit connectivity between MANET nodes you 
practically assume that a MANET is _not_ a single link, but several 
links.  We may need to define what a link is.

Up to now we have two supposed definitions of links, which are 
contradictory: the 4861 link and the ABC-problem link.

If the MANET is made of several 4861-links then your statement above is 
fully true, I fully agree with you.  If you put that in the text, like 
"would limit connectivity between MANET nodes (assuming a MANET is made 
of several 4861-links)".

If OTOH the MANET is made of a single 4861-link then the connectivity 
between MANET nodes is not restricted by the use of LLs.

(for example the 6lowpan "route-over" scenarios consider the network is
  a single link).

Finally, if the MANET is made of 1..n ABC-links then I am not sure the 
the application of LLs restricts the communication between MANET nodes, 
because the ABC-links are not understood.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 10:32:49 +0100

> single link.  I support inserting it in the draft.

Following my own post - what do other people think about this Teco LL
suggested text?

Alex

---

From: Henning Rogge <[email-masked]>
Date: Mon, 16 Nov 2009 10:44:25 +0100

> contradictory: the 4861 link and the ABC-problem link.
The "ABC-problem" link is the normal case in a MANET. Without this kind of 
configuration, you don't have a MANET.

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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 16 Nov 2009 10:49:24 +0100

Hi,

> "would limit connectivity between MANET nodes (assuming a MANET is made 

I share this view.

Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 11:02:10 +0100

> configuration, you don't have a MANET.

Well, given that importantce, one would need to define it rather precisely.

I understand somehow the ABC problem as it has been presented until now, 
with respect to the hidden terminal problem, and the C. Perkins 
Hiroshima presentation.

However, it is not clear what it means with respect to the IPv6 concepts 
such as the link-local scope, link-local addresses.

Are there two 4861 links between A, B and C?  Each with its own 
4861-link semantics and link-local scopes?

Alex

---

From: Henning Rogge <[email-masked]>
Date: Mon, 16 Nov 2009 11:07:07 +0100

On Mon November 16 2009 11:02:10 Alexandru Petrescu wrote:
> > The "ABC-problem" link is the normal case in a MANET. Without this kind
> > of configuration, you don't have a MANET.
> 
As I understand "4861 links" no... 4861 would assume that the two links 
between A-B and B-C are not connected directly.

The typical case in a MANET (especially if every node has only one interface) 
is that there are LOTS of nodes (in this case B) that can reach two nodes (in 
this case A and C) on the same interface which cannot hear each other.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 11:13:30 +0100

> between A-B and B-C are not connected directly.

Yes, I believe 4861 would assume B is a router between the two links.

> this case A and C) on the same interface which cannot hear each other.

Could we define the ABC links in terms of 4861 links or not?

If not, I am afraid we can not use the term "link" in MANET at all.

On another hand, people have run "MANET" with links and link-local 
addresses in the past too.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Mon, 16 Nov 2009 13:23:28 +0100

> Yes, I believe 4861 would assume B is a router between the two links.
In a wireless network it's just a matter of radio range and connectivity, 
which might change through external influences and movement.
 
> > The typical case in a MANET (especially if every node has only one
> > interface) is that there are LOTS of nodes (in this case B) that can
> > reach two nodes (in this case A and C) on the same interface which cannot
> > hear each other.
> 
In wireless networks links between nodes don't have disjoined groups of 
interfaces. The 'is connected to' condition is not always transitive in 
wireless networks.
 
> If not, I am afraid we can not use the term "link" in MANET at all.
I disagree.

Link is a connection between two devices on layer 2. It's the right  term for 
the connection between two wireless devices too.

> addresses in the past too.
MOST times it will work. Just by trying to get a "linklocal unique" IP, you 
will get "mesh unique" IPs. Or maybe the same IPs are two far away to trouble 
you.

But you have no guarantee for this and DAD as described in IPv6 cannot detect 
some of the problems.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 16 Nov 2009 13:07:53 -0000

> the connection between two wireless devices too.

It's also used in "link state" as in link state protocol, as in the
middle two letters of OLSR. At that level it's as much a mathematical
concept as anything else, but it directly corresponds to the layer 2
link referred to above.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 14:52:57 +0100

> which might change through external influences and movement.

Cables also might change through external influence such as people 
disconnecting cables.  Nothing new in wireless.

> interfaces.

Are they point-to-point links?  We do have an understanding of 
point-to-point links, their link-local scope and their link-local 
addresses, such as the IPv6 PPP RFC.

> The 'is connected to' condition is not always transitive in 
> wireless networks.

When is it _not_ transitive?

Please give hands-on experience and deterministic behaviour otherwise we 
can't deal with it.

>> If not, I am afraid we can not use the term "link" in MANET at all.

Ok, we're in disagreement about the use of term "link".

It is very difficult to write a spec without agreement on terminology.

IPv6 link-local addresses are discouraged on 4861-links?  Or on 
ABC-problem links?

> the connection between two wireless devices too.

That sounds to me as a point-to-point link, and maybe as a NBMA link 
(Non-Broadcast Multiple Access).  (although I do question the meaning of 
NBMA - is "non-broadcast" multicast?)

Is an AUTOCONF "link" a point-to-point link and/or a NBMA link, and not 
an ABC-problem link?

> But you have no guarantee for this and DAD as described in IPv6 cannot detect 

HEnning, if my links are properly set up between devices then the IPv6 
LLs will work all the times, not just some times.

The difference is in understanding "link".

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 14:59:17 +0100

Dearlove, Christopher (UK) a écrit :
>> Link is a connection between two devices on layer 2. It's the right
>>  term for the connection between two wireless devices too.
> 

YEs, but OSPF IPv6 spec is clear about the difference between "link 
state" and "link-local", for example when it says this:
"   o  Link-local scope.  LSA is only flooded on the local link and no
       further.  Used for the new link-LSA.  See Section 4.4.3.8 for
       details."

Note "LSA" and "local link" - they're clearly different.

Whereas here we mix and match "link" and "link" according our various 
non-consensual tastes depending on a day's mood.

I think we should define what we understand by "link" in AUTOCONF:
-is it NBMA?  Is it point-to-point?
-does it support link-layer multicast?
-is it transitive?  Non-transitive?
-does it have ABC problem?  Does it _not_ have ABC problems?
-is an AUTOCONF network made by several distinctive links or by a single
  link which has the ABC problem?

Can't be all at once.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 16 Nov 2009 14:33:08 -0000

> -does it have ABC problem?  Does it _not_ have ABC problems?

Let's stop having this raised again and again. In the real world,
with real radios in real deployments, A and B may be able to
hear each other, and B and C may be able to hear each other,
but A and C may not. This is what non-transitive means (it's
mathematican speak for that). End of story, it comes from
physics. We need to solve this problem. You can do it at
layer 2, and try to make layer 3 look like an Ethernet.
If so, the IEEE is that way ---> It's a perfectly good
approach (involving solving most of the same problems, but
specialised to particular systems) but it's not what we are
doing in the IETF, which is doing it at layer 3. If you want
to know why, the IETF answer is in RFC 2501. (The short version
is layer 1/2 independence and heterogeneity.) But it's not
negotiable, that's what we are doing in the MANET and Autoconf
WGs. The rest of everything we do follows from that.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 16:14:09 +0100

I disagree.

RFC2501 was written when people were not running IPv6 in their MANETs.
The today's widely used WiFi was not available at all in 1999.

I also disagree fully with the tight connection between the AUTOCONF
work and MANET WG work.

Alex

Dearlove, Christopher (UK) a écrit :
>> -is it transitive?  Non-transitive? -does it have ABC problem?
>> Does it _not_ have ABC problems?
> 
> with real radios in real deployments, A and B may be able to hear
> each other, and B and C may be able to hear each other, but A and C
> may not. This is what non-transitive means (it's mathematican speak
> for that). End of story, it comes from physics. We need to solve this
> problem. You can do it at layer 2, and try to make layer 3 look like
> an Ethernet. If so, the IEEE is that way ---> It's a perfectly good 
> specialised to particular systems) but it's not what we are doing in
> the IETF, which is doing it at layer 3. If you want to know why, the
> IETF answer is in RFC 2501. (The short version is layer 1/2
> independence and heterogeneity.) But it's not negotiable, that's what
> we are doing in the MANET and Autoconf WGs. The rest of everything we
> do follows from that.
>

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 16 Nov 2009 16:22:13 +0100

> WGs. The rest of everything we do follows from that.

I fully agree with this description. Non-transitivity (or "ABC" as
sometimes called in this email thread) is a very basic scenario that
will appear in most MANETs (with at least three routers, which are not
all contained within a single hop). Of course you could pretend a
MANET to be an Ethernet on L2 (as in IEEE 802.11s). But this is not
what we are doing in the IETF. So we have to deal with that case.

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 16:27:28 +0100

Ulrich Herberg a écrit :
>> for that). End of story, it comes from physics. We need to solve
>> this problem. You can do it at layer 2, and try to make layer 3
>> look like an Ethernet. If so, the IEEE is that way ---> It's a
>> perfectly good approach (involving solving most of the same
>> problems, but specialised to particular systems) but it's not what
>> we are doing in the IETF, which is doing it at layer 3. If you want
>>  to know why, the IETF answer is in RFC 2501. (The short version is
>> layer 1/2 independence and heterogeneity.) But it's not negotiable,
>> that's what we are doing in the MANET and Autoconf WGs. The rest of
>> everything we do follows from that.
> 
> 
> will appear in most MANETs (with at least three routers, which are
> not all contained within a single hop).

Could we solve that problem by putting two real links instead of a
faulty one?  Why not?

> Of course you could pretend a MANET to be an Ethernet on L2 (as in
> IEEE 802.11s).

Yes, as in 802.11s,  and as in Direct WiFi as a poster often lurker said
recently, and as 6lowpan router-over scenario too, and like 802.15.5 too.

> But this is not what we are doing in the IETF. So we have to deal
> with that case.

Actually, here in AUTOCONF of IETF you completely circumvent talking
about links.  A goal which I sometimes agree with (as I said to Charles
- I find that to be ideal), but which I disagree with when one has to do
things in practice.

I wonder what communication medium will a node use to send a packet to
another node - is that a link?

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 16 Nov 2009 15:35:33 -0000

It's not open to disagreement. Physics is physics, and the
IETF WGs are working on layer 3 solutions. The differences
between IPv4 and IPv6 are more detailed issues, that I
carefully didn't discuss, and don't affect those two points.

The idea that the Autoconf WG shouldn't be linked to the
MANET WG is also just not going to fly. Of course that
linkage may not be the only linkage, but the whole point
of the IETF is to create protocols that all work together.

On the specific RFC 2501 point, again the IPv4/IPv6 issues
aren't the point, and so what if it predates Wi-Fi? (though
I'd have to check that claim). We are not just about 802.11
(another non-negotiable point) and the whole point of RFC
2501 is not to be locked to specific L1/L2 technologies
- including ones that hadn't been invented then or even now.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 16 November 2009 15:14
To: Dearlove, Christopher (UK)
Cc: Henning Rogge; [email-masked]
Subject: Re: [Autoconf] Question regarding use of LLs

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

I disagree.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 16 Nov 2009 15:43:15 -0000

> Could we solve that problem by putting two real links instead of a

Here's the reality.

Deploy users/devices. There are a mixture of good links, bad
links, and no links between radios. We try to use the good
links, try to use the bad links only where we have to, and
where there aren't links we use other routes. Sometimes we
have the luxury of moving or otherwise changing our users
so that there are more useful good links, but often we don't.
(Bit of a problem if where we'd like a relay is where the
fire is, or in open ground in a combat situation, or even just
on land that belongs to someone else.) But we always have some
missing links, except in the highly degenerate case where
everyone is all together, and we don't need a MANET. And
missing links means non-transitivity. That's the problem that
isn't open to being argued away.

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 16 Nov 2009 16:44:17 +0100

On Mon, Nov 16, 2009 at 4:27 PM, Alexandru Petrescu
<[email-masked]> wrote:
> [...]
>> sometimes called in this email thread) is a very basic scenario that will
>> appear in most MANETs (with at least three routers, which are

I am not sure I understand that question... We are dealing with L3, so
we cannot easily solve that problem on L2 (such as bridges).

> recently, and as 6lowpan router-over scenario too, and like 802.15.5 too.

That may all be possible. But in AUTOCONF (and MANET) WG of IETF, we
deal with multi-hop connectivity on L3 and do not assume any
particular L2. As for 6lowpan, I have some doubts about their
router-over scenario, but this is not an issue in this mailing list.

> another node - is that a link?

see above ("we deal with multi-hop connectivity on L3 and do not
assume any particular L2")

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 16:46:14 +0100

Dearlove, Christopher (UK) a écrit :
> It's not open to disagreement.

Don't hope for consensus then.

Alex

> Physics is physics, and the

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 16:52:54 +0100

Ulrich Herberg a écrit :
>>> I fully agree with this description. Non-transitivity (or "ABC"
>>> as sometimes called in this email thread) is a very basic
>>> scenario that will appear in most MANETs (with at least three
>>> routers, which are not all contained within a single hop).
> I am not sure I understand that question... We are dealing with L3,
> so we cannot easily solve that problem on L2 (such as bridges).

Ok, no bridges; can we have B to be a router which IP forwards between
two pure 4861-links?  In this way, instead of calling it one ABC-problem
link we call it two no-problem 4861-links.

>>> Of course you could pretend a MANET to be an Ethernet on L2 (as
>>> in IEEE 802.11s).
>> 
>> Yes, as in 802.11s,  and as in Direct WiFi as a poster often lurker
>> said recently, and as 6lowpan router-over scenario too, and like
>> 802.15.5 too.
> 

Right, 6lowpan route-over could be clarified too.

>> Actually, here in AUTOCONF of IETF you completely circumvent
>> talking about links.  A goal which I sometimes agree with (as I
>> said to Charles - I find that to be ideal), but which I disagree
>> with when one has to do things in practice.
>> 
>> I wonder what communication medium will a node use to send a packet
>> to another node - is that a link?
> 

But IPv6 does assume and define a link.  Why don't you want to?

rfc4861 doesn't assume a particular L2 either, but does go in detail and
defines a link.  Most of rfc4861 happens on such a link, it's natural to
need to define it.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 17:24:30 +0100

Dearlove, Christopher (UK) a écrit :
> It's not open to disagreement. Physics is physics, and the IETF WGs 
> are working on layer 3 solutions. The differences between IPv4 and 
> IPv6 are more detailed issues, that I carefully didn't discuss, and 
> don't affect those two points.
> 
> The idea that the Autoconf WG shouldn't be linked to the MANET WG is 
> also just not going to fly. Of course that linkage may not be the 
> only linkage, but the whole point of the IETF is to create protocols 
> that all work together.

Right, an AUTOCONF protocol will not work if it requires /128
(exclusively!) prefixes configured on interfaces.

> On the specific RFC 2501 point, again the IPv4/IPv6 issues aren't the
>  point,

RFC2501 was issued at a time when IPv4 link-local addresses didn't exist
either.

> and so what if it predates Wi-Fi?

If it predates WiFi it means it doesn't know about the WiFi problems and
WiFi experience.

Moreover, rfc2501 MANETs don't talk ABC (hidden terminal) problem, nor
transitivity nor asymmetry problems.

> (though I'd have to check that claim).

Sure, to be more precise, I think cards tagged "WiFi" appeared on the
market in 2000.

I think the first widely available 802.11b document was published in 2000.

Even if we consider 1999 to be close enough to 2000, it's hard to
imagine there was such widespread experience with wifi as it is now, and
that rfc2501 benefitted from wide review from wifi users.

> We are not just about 802.11 (another non-negotiable point) and the
> whole point of RFC 2501 is not to be locked to specific L1/L2 
> technologies - including ones that hadn't been invented then or even 
> now.

I agree with this goal, in general.

In particular, we should say which links.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Mon, 16 Nov 2009 17:32:45 +0100

> Don't hope for consensus then.
We will not even have a discussion about it.

The attributes of wireless communication links (especially the non-
transitivity of connectivity) is a property of physics. Unless you plan to 
rewrite physics there is not much you can do about it I think.

IPv6 assumes that if you have someone in linklocal range (unicast or 
multicast), you have all of his linklocal neighbors (on the same interface) 
yourself in linklocal range too. Wireless networks don't work this way, get 
over it.

The only thing we can do is
a) try to ignore it, cross fingers and hope we will never run in a linklocal 
collision at two-hop range
b) warn the users that the IPv6 specifications might lead to strange things in 
wireless networks
c) work on protocolls and algorithms to create linklocal IPs that are a little 
bit tighter than necessary, so we can guarantee that they will always be 
linklocal in our mesh networks.

There are sollutions for part c), so I don't worry about it. But they are not 
"just use RFC 4861 and be done with it".

Henning Rogge

---

From: sratliff <[email-masked]>
Date: Mon, 16 Nov 2009 11:35:25 -0500

> (exclusively!) prefixes configured on interfaces.

Once again, this is utter nonsense. I refer you to section 6.2 of the draft,
second bullet : 
"A subnet prefix configured on this interface should be of length /128."

It says should. Not "must". I fail to understand why you continue to argue
that this "exclusively" requires /128 prefixes. It is obviously, patently
FALSE. 

Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 17:49:15 +0100

sratliff a écrit :
> 
> 
> On 11/16/09 11:24 AM, "Alexandru Petrescu"
>>> It's not open to disagreement. Physics is physics, and the IETF
>>> WGs are working on layer 3 solutions. The differences between
>>> IPv4 and IPv6 are more detailed issues, that I carefully didn't
>>> discuss, and don't affect those two points.
>>> 
>>> The idea that the Autoconf WG shouldn't be linked to the MANET WG
>>> is also just not going to fly. Of course that linkage may not be
>>> the only linkage, but the whole point of the IETF is to create
>>> protocols that all work together.
> Once again, this is utter nonsense. I refer you to section 6.2 of the
> draft, second bullet : "A subnet prefix configured on this interface
> should be of length /128."
> 
> It says should. Not "must". I fail to understand why you continue to
> argue that this "exclusively" requires /128 prefixes. It is
> obviously, patently FALSE

How does one interpret that "should /128" when all interfaces are
configured with the "fe80::/10" prefix out-of-the-box?

What does "should prefix length /128" mean with respect to SLAAC: does
it mean we have little chance of ever running SLAAC on an AUTOCONF node
(SLAAC uses Interface Identifiers of length /64, thus prefix lengths /64)?

Moreover - why do you transform the necessity of host-based routes (/128
as prefix length in the routing table, which is ok) into an unnecessary
"should" /128 prefix assigned on an interface?  Where does this
necessity come from?

Alex

> 
> Stan
> 
> 
>>> On the specific RFC 2501 point, again the IPv4/IPv6 issues aren't
>>> the point,
>> RFC2501 was issued at a time when IPv4 link-local addresses didn't
>> exist either.
>> 
>> If it predates WiFi it means it doesn't know about the WiFi
>> problems and WiFi experience.
>> 
>> Moreover, rfc2501 MANETs don't talk ABC (hidden terminal) problem,
>> nor transitivity nor asymmetry problems.
>> 
>> Sure, to be more precise, I think cards tagged "WiFi" appeared on
>> the market in 2000.
>> 
>> imagine there was such widespread experience with wifi as it is
>> now, and that rfc2501 benefitted from wide review from wifi users.
>> 
>>> We are not just about 802.11 (another non-negotiable point) and
>>> the whole point of RFC 2501 is not to be locked to specific L1/L2
>>>  technologies - including ones that hadn't been invented then or
>>> even now.
>> _______________________________________________ Autoconf mailing
>> list [email-masked]

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 16 Nov 2009 16:59:42 -0000

There already is not just broad, but overwhelming consensus
for the following points that are the only ones I was making:

- MANETs have physical link properties that are non-transitive
  (or however you want to word it).
- The IETF is working on L3 MANET protocols.
- The Autoconf and MANET WGs work is directly related.

Note that broad consensus is not the same as unanimity, but
it's actually pretty close in this case.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 16 November 2009 15:46
To: Dearlove, Christopher (UK)
Cc: Alexandru Petrescu; Henning Rogge; [email-masked]
Subject: Re: [Autoconf] Question regarding use of LLs

                    *** WARNING ***

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 18:03:20 +0100

Henning Rogge a écrit :
> transitivity of connectivity) is a property of physics. Unless you
> plan to rewrite physics there is not much you can do about it I
> think.

I don't plan to rewrite physics laws more than you plan to re-write IPv6
and Internet.

>  multicast), you have all of his linklocal neighbors (on the same
> interface) yourself in linklocal range too. Wireless networks don't
> work this way, get over it.

Well I know some wireless links which work that way: 802.11b, 802.16
(when they are properly set up).

> The only thing we can do is a) try to ignore it, cross fingers and
> hope we will never run in a linklocal collision at two-hop range

Well - if the two-hop range is two 4861-links then the link-local
addressed packets do not get forwarded, so no collision risk.

> b) warn the users that the IPv6 specifications might lead to strange
> things in wireless networks

I think your warning will fall on my definitely deaf AUTOCONF ears.

> c) work on protocolls and algorithms to create linklocal IPs that are
> a little bit tighter than necessary, so we can guarantee that they
> will always be linklocal in our mesh networks.

This sounds like new contributions to the IPv6 Addressing Architecture
RFC, which could easily be qualified as re-writing the Internet rules.

> There are sollutions for part c), so I don't worry about it. But they
> are not "just use RFC 4861 and be done with it".

Right, I don't mean to say that.

The current task is to desribe a practical addressing model.  "/128" is
not practical, discouraging LLs is not practical either.  You have all
upside down in this document: the main recommendations go against any
practical aspects, which are then left as exceptions, corner cases,
non-wireless, etc.

I want link-local addresses to be first-class citizens in AUTOCONF, not
some corner case.

I want the "prefix /128 on interface" suggestion to be an exception.
Maybe, I say maybe, the "/128" prefixlen in the routing table for
host-based routes to be a MAY.

I want the AUTOCONF document to define "link".  And to name the links on
which it run as example.  And to list the protocols which require the
use link-local addresses.

That for my wishlist :-)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 18:05:19 +0100

> it's actually pretty close in this case.

Well feel free to exclude me from your consensus.

I will be happy go working in another WG.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 16 Nov 2009 17:06:12 -0000

> RFC2501 was issued at a time when IPv4 link-local addresses didn't
exist
> either.

So what? I wasn't quoting 2501 with regard to LL addresses, but
with regard to doing things at L3.

> If it predates WiFi it means it doesn't know about the WiFi problems
and

So what? We're not working on 802.11, we're working on L3 routing.

> transitivity nor asymmetry problems.

It doesn't spell it out in nit-picking detail, but the transmitivity
issue is implicit (and pretty close to explicit using the word "random"
in Section 3. Not that that matters, it's not why I referenced 2501.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 16 Nov 2009 17:09:33 -0000

> (when they are properly set up).

Nonsense.

And that should be (a resolution I will try to keep) my final word
on the subject.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 18:10:42 +0100

Dearlove, Christopher (UK) a écrit :
> So what? I wasn't quoting 2501 with regard to LL addresses, but with
> regard to doing things at L3.

Working at L3?  Ok, so says the entire IETF, not just one particular
RFC.  I wonder why you cite RFC2501 in particular as suggestion to work 
on L3.

> So what? We're not working on 802.11, we're working on L3 routing.

I think putting the "/128" in the prefixlen field of a routing table
entry is a good L3 part to recommend. (and not the current /128 prefix
per interface).

> issue is implicit (and pretty close to explicit using the word
> "random" in Section 3. Not that that matters, it's not why I
> referenced 2501.

One can use that use of the word "random" to motivate about anything one
would like to.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 18:15:09 +0100

Dearlove, Christopher (UK) a écrit :
>>> IPv6 assumes that if you have someone in linklocal range (unicast
>>> or multicast), you have all of his linklocal neighbors (on the
>>> same interface) yourself in linklocal range too. Wireless
>>> networks don't work this way, get over it.
> 
>> Well I know some wireless links which work that way: 802.11b,
>> 802.16 (when they are properly set up).
> 
> Nonsense.

Is this nonsense qualifier also relying on the rfc2501 use of the word
random?

Or do you have some actual facts about how IPv6 does _not_ work on
802.11b?  Because I state the opposite: IPv6 works on 802.11b,
link-local addresses _are_ used and shorter than 128 prefixes are the
common case of prefix assigned on an interface.

This is not a game of words, it's how it is in my view.

Alex

> 
> And that should be (a resolution I will try to keep) my final word on
> the subject.
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 16 Nov 2009 18:23:18 +0100

> common case of prefix assigned on an interface.

Alex,

Without knowing anything about your deployments, what you say above  
makes me absolutely certain that IEEE 802.11b, in the mode you have  
been deploying it, is NOT a multihop ad hoc network nor a MANET.

Thomas

>> ******************************************************************** This 
>>  email and any attachments are confidential to the intended

---

From: Henning Rogge <[email-masked]>
Date: Mon, 16 Nov 2009 18:24:31 +0100

> I don't plan to rewrite physics laws more than you plan to re-write IPv6
Yes you do, but you don't notice (yes I know you would give me/us the same 
answer).
 
> (when they are properly set up).
No they don't... especially not in Adhoc mode.

You don't setup LINKS in 802.11, you set up a node and get connectivity with 
everyone else in range. Unless you want to limit 802.11 to directional 
point-2-point connections, there is no way to avoid the not-transitive 
connection thing.
 
> addressed packets do not get forwarded, so no collision risk.
The problem is not forwarding. In the ABC case everything seems to be fine for 
A and C, even if they have choosen the same linklocal-IP. Noone in linklocal-
range of them has the same IP.

But B communicates with BOTH OF THEM on the same interface, so he has two 
linklocal-range neighbors who have chosen the same linklocal-IP for their 
interface. So B cannot use the IP to communicate with A and C.

> I think your warning will fall on my definitely deaf AUTOCONF ears.
So what ? If you come back complaining that one of your 1000 IPv6-Autoconf 
networks did behave badly we can say "we warned you". ;)
 
> RFC, which could easily be qualified as re-writing the Internet rules.
If the whole internet will become a mesh network with only wireless links we 
might do so.

The IPv6 ND will work most of the times, because the random part of the 
linklocal IP is HUGE. So you will have to wait a long time before you get a 
collision. But you might get one. Especially in a MOBILE adhoc network.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 20:28:28 +0100

Thomas Heide Clausen a écrit :
>>>>> IPv6 assumes that if you have someone in linklocal range 
>>>>> (unicast or multicast), you have all of his linklocal 
>>>>> neighbors (on the same interface) yourself in linklocal range
>>>>>  too. Wireless networks don't work this way, get over it.
>> Is this nonsense qualifier also relying on the rfc2501 use of the 
>> word random?
>> 
>> link-local addresses _are_ used and shorter than 128 prefixes are 
>> the common case of prefix assigned on an interface.
>> 
> 
> Alex,
> 

ThomasC - is that with the Chair hat on or off?

I think you should be sure before talking MANETs in general.

Because:
-RFC2501 MANETs are not OLSR MANETs which are not DYMO MANETs which are
  not AUTOCONF networks.
-the OLSR MANET is _not_ the 6lowpan MANET, and is not the RoLL MANET
  either.
-your MANETs are not personX's MANETs.
-Finally, and very importantly: your MANETs are not personY's MANETs.
(personX and Y active in this WG).

That's why I suppose your hat was not on :-)

In this sense - which MANET are we talking about?  Can we define what
"MANET" means?  I think it would be useful.

(about the networks I deploy - they are multi-IPhop networks (Hop Limit
field gets decremented), with one 802.11b ad-hoc link (has link-local
scope, supports link-layer multicast) in between which uses exclusively
link-local addresses; the src and dst of the communication ends are not
link-local; but the link-local addresses in the ad-hoc link are very
important and easy to use, in order to have the entire network work.
Don't discourage that.  Also, I don't use /128 prefixes on the
interfaces, and I don't use /128 host-based routes but aggregated routes
into /64 prefixes.  Don't discourage that either.)

Alex

>>> And that should be (a resolution I will try to keep) my final 
>>> word on the subject. 
>>> recipient please delete it from your system and notify the
>>> sender. You should not copy it or use it for any purpose nor 
>>> disclose or distribute its contents to any other person.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 21:05:05 +0100

Henning Rogge a écrit :
>>> The attributes of wireless communication links (especially the
>>> non- transitivity of connectivity) is a property of physics.
>>> Unless you plan to rewrite physics there is not much you can do
>>> about it I think.
>> I don't plan to rewrite physics laws more than you plan to re-write
>> IPv6 and Internet.
> 
> Yes you do, but you don't notice (yes I know you would give me/us the
> same answer).

Let's say I place my view higher above the physics laws (PHY) than you do.

> You don't setup LINKS in 802.11, you set up a node and get
> connectivity with everyone else in range.

That's right - it becomes a link.  Everyone in range of my device and my
device form a link.  That's fully deterministic.  The size of that range
is specified.  That link supports link-layer multicast, has link-local
scope, doesn't have ABC problem, is transitive.

> Unless you want to limit 802.11 to directional point-2-point
> connections, there is no way to avoid the not-transitive connection
> thing.

Well, I disagree - a link formed by devices within a certain precise
range from my device is not a ptp link, supports link-layer multicast
and is transitive.

>>> The only thing we can do is a) try to ignore it, cross fingers
>>> and hope we will never run in a linklocal collision at two-hop
>>> range
> The problem is not forwarding. In the ABC case everything seems to be
> fine for A and C, even if they have choosen the same linklocal-IP.
> Noone in linklocal- range of them has the same IP.

I see what you mean.

But look at it otherwise:

If the maximum distance (range) between any two pairs of A, B and C is
the standardized 802.11b limit then there is no ABC problem and no
non-transitive issue.  Right?

If the distance between any of the two is larger than the 802.11b
standardized limit then don't presume you have a normally behaving link.

> But B communicates with BOTH OF THEM on the same interface,

I don't understand this restriction - why a single interface on B?  If
having a single interface creates problems then add another one.

If you had two 50m Ethernet Category5 cables and three machines -
wouldn't you create the same problem (Ethernet length is also
standardized) - yet nobody tells IP doesn't run on Ethernet.

> so he has two linklocal-range neighbors who have chosen the same
> linklocal-IP for their interface. So B cannot use the IP to
> communicate with A and C.

Well, I wouldn't expect A, B and C to consider they have a working link
between them if any of the two is outside the specified range.  You
were saying A and C were not in range, right?  So why would A and C
consider they had a link between them?

I think your problem of connecting two remote machines through an
intermediary close to both is really nothing new and we shouldn't spend
any cycle on it.  I mean two IP machines with a router in between does that.

>>> b) warn the users that the IPv6 specifications might lead to
>>> strange things in wireless networks
> So what ? If you come back complaining that one of your 1000
> IPv6-Autoconf networks did behave badly we can say "we warned you".
> ;)

No no, I am deaf :-)

I tell you why.

Whenever considering a 1000somethings bigger something one has to
structure them.  And the first setp in structuring is to use
deterministic links.

Also, whenever considering 1000nodes, there surely will exist _some_ 
nodes which are given little more functionalities.  I expect these to 
have several interfaces.

Besides, there's no one single human who could deploy alone a working 
1000node IP network.

>>> c) work on protocolls and algorithms to create linklocal IPs that
>>> are a little bit tighter than necessary, so we can guarantee that
>>> they will always be linklocal in our mesh networks.
>> 
>> This sounds like new contributions to the IPv6 Addressing
>> Architecture RFC, which could easily be qualified as re-writing the
>> Internet rules.
> 
> If the whole internet will become a mesh network with only wireless
> links we might do so.

I think I am very much scared to hear you expect the Internet to become
a mesh network.  I am scared because I believe it already is a mesh
network and thus I don't know what you want to do.

> The IPv6 ND will work most of the times, because the random part of
> the linklocal IP is HUGE. So you will have to wait a long time before
> you get a collision. But you might get one. Especially in a MOBILE
> adhoc network.

Hmmm, I am not afraid, DAD will help me detect the duplicates n 100% cases.

There are literally milions of MOBILE devices connected to the Internet.

Sometimes they are also literally ad-hoc, i.e. unplanned.  Recently an
unplanned connection of a MOBILE device generated a huge euro bill.
Imagine the easiness of using that MOBILE device that its owner didn't
even realize it's on a different (more expensive) network.  The IP
connection setup worked ok, the IP address changed, etc. yet the owner
didn't even notice.  Is that unplanned (i.e. adhoc) and MOBILE enough?

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 16 Nov 2009 21:23:06 +0100

Alex,

> non-transitive issue.  Right?

But why do you need a MANET for that case? I would call that IBSS
mode, you don't need any routing then.

> standardized limit then don't presume you have a normally behaving link.

This is called MANET (i.e. multi-hop communicaiton). Do you seriously
suggest to limit a MANET to the size of your living room? How would
you deploy a MANET like the one from FunkFeuer? (several hundreds of
routers in Vienna, over a huge area)? Or a military network?

> having a single interface creates problems then add another one.

So you suggest to add an interface for every neighbor in the worst
case? How many interfaces would you suggest to have on every router
then?

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 16 Nov 2009 22:11:01 +0100

Ulrich Herberg a écrit :
>> [...] I see what you mean.
>> 
>> If the maximum distance (range) between any two pairs of A, B and C
>>  is the standardized 802.11b limit then there is no ABC problem and
>>  no non-transitive issue.  Right?
> 

Right, that forms a single deterministic 4861-link, no IP routing within
it.   It's already great to have it.  Its only disadvantage may be its
  relatively small 50m range; but knowing that a single 50m cable could
connect only two machines, a 50m wifi range connecting tens of computers
is much more advantageous.

> This is called MANET (i.e. multi-hop communicaiton).

Are you saying a MANET is a network which presumes it doesn't have
normally behaving links?  DO you mean a MANET never works ok?

About MANET being "multi-hop communications" - let's agree that
multi-hop communications happened and continue to happen completely
independent of what MANET is or becomes.

First, multi-hop is what 6lowpan and RoLL call too, yet avoiding the
word MANET.

Second, multi-hop is what happens in the Internet at-large.  Internet is
a huge mesh of wired and wireless links all stitched together by IP.

Why do you want to call multi-hop communications "MANET"?

> Do you seriously suggest to limit a MANET to the size of your living 
> room?

Well, no, my living room size is smaller than 50m :-)

I don't see a MANET larger than 50m using exclusively 1-interface
routers.  That doesn't scale IMHO.

Of course, you could have independent overlapping islands of wifi
unknown links, but a fully connected network doesn't scale very large
when only 1-interface routers are used, for sure.

Do you know how many interfaces a DFZ router has?

> How would you deploy a MANET like the one from FunkFeuer? (several 
> hundreds of routers in Vienna, over a huge area)?

"FunkFeuer"(?)  Did FunkFeuer ever claim each of their hundreds Vienna
routers is a one-interface router?

> Or a military network?

Military?  Secret.  Not IETF.

>> I don't understand this restriction - why a single interface on B? 
>> If having a single interface creates problems then add another one.
>> 
>> 
>> 
> 

It's not necessary for a router to have a distinct interface for every
neighbor.  It is necessary to have at least two interfaces on wifi
routers placed at the 50m borders.

In terms of number of interfaces overall, one worst wifi case would be a
linear deployment with each node within 50m from the next, no closer.
That would require 2 interfaces on each router except the first and last.

But that's a particular case I don't see happening.

The types of physically linear deployments I know of are half wired half
wireless and are currently dealt with with mostly star topologies (e.g.
networks of IP speedcams along highways, or bus stop IP displays, IP
Access Points in metro/bus stations, IP Access Points in public parks).

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 16 Nov 2009 22:44:07 +0100

>>> standardized limit then don't presume you have a normally behaving

I preferred not take part of this discussion. But reading so much opinions
that are beside facts, I encourage everybody reading the bloody specs.
E.g. 802.11-2007 page 27:
  For wireless PHYs, well-defined coverage areas simply do not exist.
  Propagation characteristics are dynamic and unpredictable. Small 
  changes in position or direction may result in dramatic differences 
  in signal strength. Similar effects occur whether a STA is stationary
  or mobile (as moving objects may impact station-to-station propagation).

We could introduce moving teapots again :-)

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 00:13:52 +0100

Teco Boot a écrit :
>>>> If the maximum distance (range) between any two pairs of A, B 
>>>> and C is the standardized 802.11b limit then there is no ABC 
>>>> problem and no non-transitive issue.  Right?
> 
>> Right, that forms a single deterministic 4861-link, no IP routing 
>> within it.   It's already great to have it.  Its only disadvantage 
>> may be its relatively small 50m range; but knowing that a single 
>> 50m cable could connect only two machines, a 50m wifi range 
>> connecting tens of computers is much more advantageous.
> 
>>>> If the distance between any of the two is larger than the 
>>>> 802.11b standardized limit then don't presume you have a 
>>>> normally behaving link.
> 
> I preferred not take part of this discussion. But reading so much 
> opinions that are beside facts, I encourage everybody reading the 
> bloody specs. E.g. 802.11-2007 page 27: For wireless PHYs, 
> well-defined coverage areas simply do not exist. Propagation 
> characteristics are dynamic and unpredictable. Small changes in 
> position or direction may result in dramatic differences in signal 
> strength. Similar effects occur whether a STA is stationary or mobile
>  (as moving objects may impact station-to-station propagation).

Hmmm... Teco, I agree the wireless PHYs are full of surprises to... PHY
layer.

But take me the average wifi user, with a wifi manual on my laps and
here's what I see: "radio range (approximately 60 metres)".  That's my
hands-on experience of wifi adhoc mode.  Moreover, I believe it is
regulated worldwide.

Of course, add to that some millimeter-wave kitchen ovens, de-ionized
atmosphere and obstacles and PHY becomes suddenly unstable.

I believe kitchen ovens will affect the "/128 prefix on
interface" recommendation too.  When a very badly tuned oven is running
near an AUTOCONF router the use of "/128 prefix on the interface" will
not improve the communication.  Only turning that oven off will improve it.

Add to it a range-extension antenna, a clear sunny day, turn the power
knob to max, break the regulation laws, and all of a sudden we have huge
PHY coverage in the order of kilometers, as reported in the O'Reilly
802.11 book, 2002 -  practical experience.  Totally independent of /128
prefixes or /64 prefixes on interface, or of LL recommendations, and of
any routing protocol.  It's just a bigger and stronger PHY layer.

PHY or not PHY... IP or not IP.

> We could introduce moving teapots again :-)

:-) sounds interesting but what's it refering to?

Alex

---

From: Clint Chaplin <[email-masked]>
Date: Mon, 16 Nov 2009 15:33:55 -0800

"standardized IEEE 802.11b limit"?  I don't believe that IEEE 802.11b
has a limit in the standard.  If you can hear each other, you go for
it.  And, different geos allow different maximum output power.

On Mon, Nov 16, 2009 at 12:05 PM, Alexandru Petrescu
<[email-masked]> wrote:
> Also, whenever considering 1000nodes, there surely will exist _some_ nodes
> which are given little more functionalities.  I expect these to have several
> interfaces.
>

-- 
Clint (JOATMON) Chaplin
Principal Engineer
Corporate Standardization (US)
SISA

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 07:31:24 +0100

> routers is a one-interface router?
Most of them are one-hop routers. I would say more than 70%, Maybe even more.

Berlin had even a higher percentage of 1-interface routers in their 700+ node 
network for years.

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 17 Nov 2009 08:38:17 +0100

Alex,

We IETF work on standards. We cooperate with the IEEE 802 communities, 
including 802.11. This WLAN specification is evolving and nowadays
it support range extension in the spec (section 17.1, the 10MHz and 
5MHz channels).

With high gain antennas, 300km links were set up. I expect they did
not reduce TXpower, so it may be illegal. But by reducing the TXpower,
a set up with two high gain antennas enlarges the link range without
breaking laws. 5km should not be a problem.

Moreover, there are plenty of communities that have their own licensed
or protected spectrum. I am involved in those communities, and 20km links 
or more is no problem, using 802.11 based equipment. But at the same
time, I experience connectivity problems due to foliage, teapots or 
whatever. 50meters can be two teapots too far.

Am I right you admit we shall stay away from PHY details in Autoconf?

To fresh up your memory, read postings of exactly 2 years ago, e.g.:
http://www.ietf.org/mail-archive/web/autoconf/current/msg00746.html
Your text:
   It appears too exhausting to describe each and every scenario, 
   right :-) They look as easily mapped from one to another. 
   They're all networks in the end :-)

Regards, Teco

>Van: Alexandru Petrescu [mailto:[email-masked]]
>Verzonden: dinsdag 17 november 2009 0:14
>Aan: Teco Boot
>CC: 'Alexandru Petrescu'; [email-masked]
>Onderwerp: Re: practical coverage areas, PHY unknowns and user manuals
>(was: [Autoconf] Question regarding use of LLs)
>
>Teco Boot a écrit :

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 08:43:23 +0100

> breaking laws. 5km should not be a problem.
Vienna has a legal 20+ km link with 802.11 and directional antennas.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 11:08:08 +0100

Clint Chaplin a écrit :
> has a limit in the standard.

Why do the 802.11b user manuals say 50m (150ft) then?  Are they wrong?

Alex

>  If you can hear each other, you go for

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 11:08:57 +0100

> Most of them are one-hop routers. I would say more than 70%, Maybe even more.

I believe you mean one-interface routers.

Well I think we should leave place in the specs for the 30% or less 
routers which have more than one interface then.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 11:15:03 +0100

> Why do the 802.11b user manuals say 50m (150ft) then?  Are they wrong?
It's not a "802.11b user manual" but a manual for a card you can buy. And the 
manufacturer just states a typical distance you can use together with an 
access point in urban terrain. Because that's (from most manufacturers point 
of view) is the typical usecase for their cards.

The 50m has NOTHING to do with the 802.11 specification.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 17 Nov 2009 11:16:38 +0100

> routers which have more than one interface then.

Fortunately, such do not necessitate special treatment at all.

Thomas

> Alex
>
>> Berlin had even a higher percentage of 1-interface routers in their  
>> 700+ node network for years.
>> Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 11:16:43 +0100

> I believe you mean one-interface routers.
Yes.
 
> routers which have more than one interface then.
I would have to ask what's the exact split.

Most routers have only one interface because they are typical DSL-WLAN-
routers, so they are very cheap. That's a good argument for large scale 
community networks.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 11:22:32 +0100

> Fortunately, such do not necessitate special treatment at all.

Well we should ack a MANET can use routers with more than one interface. 
  On these routers the ABC link problems are less valid.

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 17 Nov 2009 11:23:36 +0100

On Nov 17, 2009, at 11:22 AM, Alexandru Petrescu wrote:

>>> Well I think we should leave place in the specs for the 30% or  
>>> less routers which have more than one interface then.
> Well we should ack a MANET can use routers with more than one  
> interface. On these routers the ABC link problems are less valid.
>

No, they are not.

Thomas

> Alex
>
>> Thomas
>>> Alex
>>>
>>>> Berlin had even a higher percentage of 1-interface routers in  
>>>> their 700+ node network for years.
>>>> Henning Rogge
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 11:24:37 +0100

> I would have to ask what's the exact split.

Well, a router with two interfaces will have less ABC link problems.

> routers, so they are very cheap.

Er?  A typical DSL-WLAN router has two interfaces: a WLAN interface and 
a DSL interface.

> That's a good argument for large scale 
> community networks.

Yes, large scale networks are supposed to use several interfaces on 
their routers.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 11:24:58 +0100

>   On these routers the ABC link problems are less valid.
That's not true. You don't seem to know anything about adhoc networks, sorry.

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 11:26:39 +0100

>> interface. On these routers the ABC link problems are less valid.

Depends how you configure them.  If you configure them such that A and C 
are too remote and B in between - yes ABC problems.

If you configure B to have two interfaces each on a distinct 4861 link 
then there are no ABC problem links.

It depends on how you set the links up.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 11:28:03 +0100

> That's not true. You don't seem to know anything about adhoc networks, sorry.

Hmmm... is this the way you make people go away from your consensus?

Alex

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 17 Nov 2009 11:29:28 +0100

On Nov 17, 2009, at 11:26 AM, Alexandru Petrescu wrote:

> Depends how you configure them.  If you configure them such that A  
> and C are too remote and B in between - yes ABC problems.
>
> If you configure B to have two interfaces each on a distinct 4861  
> link then there are no ABC problem links.
>

If you configure the devices and enforce behavior such that they are  
not part of a MANET, then you are not within scope of [autoconf].

Thomas

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 11:34:09 +0100

Thomas Heide Clausen a écrit :
>>>>>>>>> How would you deploy a MANET like the one from 
>>>>>>>>> FunkFeuer? (several hundreds of routers in Vienna, 
>>>>>>>>> over a huge area)?
>>>>>>>> "FunkFeuer"(?)  Did FunkFeuer ever claim each of their 
>>>>>>>> hundreds Vienna routers is a one-interface router?
>>>>>>> 
>>>>>> Well I think we should leave place in the specs for the 30%
>>>>>>  or less routers which have more than one interface then.

Thomas,

Again, you seem to make AUTOCONF too much related to MANET.

AUTOCONF Charter doesn't say MANET.

Are we sure Chairs and WG members are inline with respect to MANET vs
AUTOCONF?

I personally don't think AUTOCONF should do MANET exclusively.  With the
above phrase you (as Chair?) clearly rule out everything else than MANET
from AUTOCONF.

I think this is a very wrong situation to be in.

Alex

> 
> Thomas
> 
> 
>> Alex
>> 
>>> Thomas
>>>> Alex
>>>> 
>>>>> Thomas
>>>>>> Alex
>>>>>> 
>>>>>>> Berlin had even a higher percentage of 1-interface 
>>>>>>> routers in their 700+ node network for years. Henning 
>>>>>>> Rogge
>>>> 
>>>> 
>>>> _______________________________________________ Autoconf 
>>>> mailing list [email-masked]

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 17 Nov 2009 11:38:06 +0100

On Nov 17, 2009, at 11:34 AM, Alexandru Petrescu wrote:

>>>>>>>>>> How would you deploy a MANET like the one from FunkFeuer?  
>>>>>>>>>> (several hundreds of routers in Vienna, over a huge area)?
>> If you configure the devices and enforce behavior such that they  
>> are not part of a MANET, then you are not within scope of [autoconf].
>
> Thomas,
>

I believe that the charter is quite clear when it starts:

	In order to communicate among themselves, ad hoc nodes (refer to RFC
	2501)

that we are addressing MANETs.

Thomas

>>>>>>>> their 700+ node network for years. Henning Rogge
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
>
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 17 Nov 2009 11:38:08 +0100

> Hmmm... is this the way you make people go away from your consensus?

At the moment you are wasting time for everyone because you don't seem to 
grasp what this WG and MANETs in general are about. You try to press the 
working of this group into a concept that was generated mostly for wired 
network world (and highly structured networks as mobile phone ones).

MANETs work differently. They have additional problems and they are not just a 
"bunch of well behaving links".

From the charter of the AUTOCONF group:

> Description of Working Group:
> 2501) need to configure their network interface(s) with local addresses
> that are valid within an ad hoc network. Ad hoc nodes may also need to
> configure globally routable addresses, in order to communicate with
> devices on the Internet. From the IP layer perspective, an ad hoc
> network presents itself as a L3 multi-hop network formed over a
> collection of links.

> The main purpose of the AUTOCONF WG is to describe the addressing model
> for ad hoc networks and how nodes in these networks configure their
> addresses. It is required that such models do not cause problems for ad
> hoc-unaware parts of the system, such as standard applications running
> on an ad hoc node or regular Internet nodes attached to the ad hoc
> nodes. This group's effort may include the development of new protocol
> mechanisms, should the existing IP autoconfiguration mechanisms be found
> inadequate. However, the first task of the working group is to describe
> one practical addressing model for ad hoc networks.
Please count how often this text says "ad hoc network" or "ad hoc nodes".
MANET is an acronym for "mobile AD HOC NETWORK".

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 17 Nov 2009 12:34:25 +0100

Henning Rogge a écrit :
> At the moment you are wasting time for everyone because you don't 
> seem to grasp what this WG and MANETs in general are about. You try 
> to press the working of this group into a concept that was generated
>  mostly for wired network world

Well, I think Internet routing and addressing is very well structured.
You can't just change that.

An address being topologically correct at only one place in the topology
is an inherent feature of Internet routing and addressing that can't be
changed just like that.

You're touching on very sensitive issues with the LL recommendations and
with the /128 prefix per interface.

> (and highly structured networks as mobile phone ones).

1. mobile phone networks often consider infrastructure-less relaying,
    such as in LTE.  In this sense they look as ad-hoc networks.
2. highly structured networks exist outside the mobile phone industry,
    which look a lot like the ad-hocnetworks.

Highly-structured is what Internet is, otherwise it doesn't work.

> MANETs work differently. They have additional problems and they are 
> not just a "bunch of well behaving links".

Ok, do you have anything else to say about MANETs other than they're 
different?

>> Description of Working Group: In order to communicate among 
>> themselves, ad hoc nodes (refer to RFC 2501) need to configure 
>> their network interface(s) with local addresses that are valid 
>> within an ad hoc network. Ad hoc nodes may also need to configure 
>> globally routable addresses, in order to communicate with devices 
>> on the Internet. From the IP layer perspective, an ad hoc network 
>> presents itself as a L3 multi-hop network formed over a collection
>>  of links.
> 
>> The main purpose of the AUTOCONF WG is to describe the addressing 
>> model for ad hoc networks and how nodes in these networks configure
>>  their addresses. It is required that such models do not cause 
>> problems for ad hoc-unaware parts of the system, such as standard 
>> applications running on an ad hoc node or regular Internet nodes 
>> attached to the ad hoc nodes. This group's effort may include the 
>> development of new protocol mechanisms, should the existing IP 
>> autoconfiguration mechanisms be found inadequate. However, the 
>> first task of the working group is to describe one practical 
>> addressing model for ad hoc networks.
> 
> Please count how often this text says "ad hoc network" or "ad hoc 
> nodes". MANET is an acronym for "mobile AD HOC NETWORK".

Well - are you sure everybody is on the same line with you when you say
adhoc network is a MANET?

We have already seen that the MANET term of rfc2501 is not the same
MANET term described with the help of ABC problem and non-transitivity
links.

I remind that two other groups at IETF (6lowpan and ROLL) do things
similar to what you would call a "MANET" yet they don't call it "MANET".

I suggest you do the same.

Alex