Subject: Re: [Autoconf] call for consensus about link local address support

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 01 Sep 2009 00:41:44 -0700

Hello Ryuji,

I support (b).  In fact, I very strongly support it.

And, if further reasoning is needed, I would supply it in a
different note.  Bottom line is, I think that requiring link-local
will drastically limit our solution space and eliminate some
very useful solutions (such as those which have already
been built).

To be accurate, I think we ought to support unique-local
-INCLUSIVE OR- global addresses.  In some situations
(disconnected networks) global address autoconfiguration
may not be possible.

Regards,
Charlie P.

Ryuji Wakikawa wrote:
> Hi all,
>
> This is consensus call about the link-local address support in MANET.
> Please review the following call for consensus and vote your opinion 
> by Sep10th.
>
> DT will update the document according to our consensus.
>
> thanks,
> Thomas & ryuji
>
> ------------------------------------------------------------------
> CALL FOR CONSENSUS
>
> Deadline: 2009-09-10 6:00PM PST.
>
> Target ID: Design Team Document
> "IP Addressing Model in Ad Hoc Networks"
> http://tools.ietf.org/html/draft-baccelli-autoconf-adhoc-addr-model-01
>
> Issue (cited from the above draft):
> - Use of Link Local Addresses - while the use of link local addresses on
>  interfaces connecting to a MANET link is not prohibited, the semantics
>  of "link local" in this context is yet to be defined, taking into
>  account the unusual requirements that follow, concerning such
>  addresses. These requirements include for example uniqueness within a
>  scope spanning beyond a single IP hop.
>
> Some discussions can be found at the IETF75 AUTOCONF minutes
> http://www.ietf.org/proceedings/75/minutes/autoconf.txt
>
> Please vote your preference between the following two alternatives.
> If you have another alternative, please propose it and give your
> reasons why you prefer that alternative.
>
> a) The document shall support link-local addresses as required
>  for nodes in a MANET in addition to unique-local and global
>  addresses.
>
> b) Support unique-local and global addresses as required for MANET
>  nodes.  The document shall not prohibit using link-local addresses,
>  but shall describe the difficulties inhibiting compliance in MANET
>  with the standardized IPv6 properties that characterize the use of
>  link-local addresses.
> ------------------------------------------------------------------
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf
>
>

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 1 Sep 2009 10:30:24 +0200

Hello Ryuji,

I agree with Charlie and support (b). In my opinion, there are still many
unresolved issues with link-locals in MANETs and could delay or even limit
solutions. The document should not prohibit link-locals though (which it
does not), it just does not require them.

Regards,
Ulrich

On Tue, Sep 1, 2009 at 9:41 AM, Charles E. Perkins <
[email-masked]> wrote:

>> Please review the following call for consensus and vote your opinion by
>> Sep10th.
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Sep 2009 10:47:09 +0200

Hi Ryuji,

[...]

> a) The document shall support link-local addresses as required for
> nodes in a MANET in addition to unique-local and global addresses.

I support a).  This means AUTOCONF supports link-local addresses as any
other IPv6 node does support them.  It does not eliminate solutions for
global and unique-local addresses.

I am running a prototype in a AUTOCONF situation - link-local addresses
are used exclusively between several Mobile Routers, without
infrastructure.  It works ok.

In my prototype some problematic issues may show up but they are are
related to the way the link-layer works and is implemented, and not to
the fact that these are IPv6 link-local addresses.

Alex

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

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 1 Sep 2009 10:51:17 +0200

Hi Alexandru,

I am interested to know about your prototype. How do you assure uniqueness
of the LL addresses? Are your nodes mobile? (I mean, do they actually move
around?)

Ulrich

On Tue, Sep 1, 2009 at 10:47 AM, Alexandru Petrescu <
[email-masked]> wrote:

> Hi Ryuji,
>
> Ryuji Wakikawa a écrit :
>
>> ------------------------------------------------------------------ CALL
>> FOR CONSENSUS
>>
>> b) Support unique-local and global addresses as required for MANET nodes.
>>  The document shall not prohibit using link-local addresses, but shall
>> describe the difficulties inhibiting compliance in MANET with the
>> standardized IPv6 properties that characterize the use of link-local
>> addresses.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 01 Sep 2009 10:55:57 +0200

I vote a).

Carlos

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Sep 2009 11:10:10 +0200

Hi Ulrich,

Ulrich Herberg a écrit :
> Hi Alexandru,
> 
> I am interested to know about your prototype. How do you assure 
> uniqueness of the LL addresses?

With DAD.  The subnet is stable.

> Are your nodes mobile? (I mean, do they 
> actually move around?)

Yes, I move them around within a range of cca 50meters and some 
obstacles.  They are intended to be mostly static but they can also move 
within the acceptable limits of this particular wireless link-layer.

Comments?

Alex

> 
> Ulrich
> 
> On Tue, Sep 1, 2009 at 10:47 AM, Alexandru Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Ryuji,
> 
>     Ryuji Wakikawa a écrit :
> 
>         b) Support unique-local and global addresses as required for
>         MANET nodes.  The document shall not prohibit using link-local
>         addresses, but shall describe the difficulties inhibiting
>         compliance in MANET with the standardized IPv6 properties that
>         characterize the use of link-local addresses.
>          [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2009 11:15:15 +0200

I vote for sollution b)

>   with the standardized IPv6 properties that characterize the use of
Link-local addresses can be useful for interface IPs in MANETs, but because 
the default IPv6 link-local scope is not transitive (link-local scopes 
overlap, but they are have differences) they can be a problem for a MANET (or 
a manet autoconf implementation).

Because of movement in the MANET LL might have to change on the fly because 
two nodes which have chosen the same LL because they were out of communication 
range get into range later.

If an autoconf implementation supports link-local IPs for interfaces (either 
because of limitation of movement or clever design or the implementation) it 
should state this feature, but support for link-local IPs should not be 
mandatory.

Of course the Autoconf WG documents should not forbid the usage of link-local 
IPs.

Henning Rogge

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: [email-masked]
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2009 11:16:22 +0200

> within the acceptable limits of this particular wireless link-layer.

How do DAD deal with the case of three nodes A-B-C (B can see both A and C, A 
and C cannot see each other) when node A and C choose the same link-local IP 
for their interface ?

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 1 Sep 2009 10:19:26 +0100

b.

Getting into a debate about what link local addresses are and
are not allowed to do in a MANET would delay yet further, and
possibly to the point of failure, the real work that has not
started. This was, as I read it, pretty much the only position
that all in the room and online in Stockholm could agree on.

If, and preferably after this is agreed and the WG is rechartered
to avoid muddying the waters, someone were to raise an ID discussing
link local addresses in MANETs, what they are and are not allowed to
do (with reference to the two hop range issue, and whether mobility
de facto makes this all the MANET) and the results allowed a wider
use of link local addresses, they could be added with no significant
changes. But if the most restrictive view of link local addresses
prevailed, time would not have been wasted waiting for that.

-- 
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: [email-masked] [mailto:[email-masked]] On
Behalf Of Ryuji Wakikawa
Sent: 31 August 2009 11:00
To: [email-masked]
Subject: [Autoconf] call for consensus about link local address support

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

Hi all,

thanks,
Thomas & ryuji

********************************************************************
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: Tue, 01 Sep 2009 11:21:59 +0200

> and C cannot see each other) when node A and C choose the same link-local IP 

I don't have the A-B-C case to deal with.

If I had to deal with it I would use a link-layer solution (a bridge), 
such that DAD messages see all three nodes A, B and C.

Comments?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Sep 2009 11:23:34 +0200

Please define "MANET"...

Alex

Dearlove, Christopher (UK) a écrit :
> b.
> 
> Getting into a debate about what link local addresses are and are not
> allowed to do in a MANET would delay yet further, and possibly to the
> point of failure, the real work that has not started. This was, as I
> read it, pretty much the only position that all in the room and
> online in Stockholm could agree on.
> 
> If, and preferably after this is agreed and the WG is rechartered to
> avoid muddying the waters, someone were to raise an ID discussing

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 1 Sep 2009 10:23:52 +0100

RFC 2501

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 01 September 2009 10:23
To: Dearlove, Christopher (UK)
Cc: Ryuji Wakikawa; [email-masked]
Subject: Re: [Autoconf] call for consensus about link local address support

                    *** WARNING ***

Please define "MANET"...

Alex

-- 
Alexandru Petrescu
CEA LIST
Ingénieur Chercheur
tél 0169089223
[email-masked]
http://www-list.cea.fr

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 1 Sep 2009 11:26:58 +0200

Hi Alex,

Henning asked exactly the question I wanted to raise as well.

>>> With DAD.  The subnet is stable.
What subnet?

>> How do DAD deal with the case of three nodes A-B-C (B can see both A and
>> C, A and C cannot see each other) when node A and C choose the same
>> link-local IP for their interface ?
>>
>
> If I had to deal with it I would use a link-layer solution (a bridge), such
> that DAD messages see all three nodes A, B and C.
>
> Comments?
>

This is a very special case that cannot be assumed in general. The case
described by Henning is the general case that may (and will in mobile
scenarios) happen. We have to deal with that case in MANETs. As the
addressing document says:
"When more specific assumptions can be made regarding the connectivity to
other interfaces on the link, these SHOULD be considered when configuring
subnet prefixes."

Ulrich

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Sep 2009 11:27:28 +0200

> RFC 2501

That is so much remote about all we do here that I am highly surprised 
is given as a reference here.

It does not mention A-B-C, IPv6, DAD... nothing.

That RFC is irrelevant about what we do in AUTOCONF.

Or is as relevant as anything else which has to do with MANET.

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2009 11:29:25 +0200

> such that DAD messages see all three nodes A, B and C.
Do you use wireless radios for your MANET ? If yes the A-B-C szenario is one 
of the most primitive things you can do with three nodes (and enough distance 
to prevent direct communication between node A and C).

Henning Rogge

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Sep 2009 11:36:05 +0200

Ulrich Herberg a écrit :
> On Tue, Sep 1, 2009 at 11:21 AM, Alexandru Petrescu 

'subnet'... in this particular case I meant the link on which the 
interfaces self-configure their IPv6 link-local addresses.  That link I 
use is stable. It has no A-B-C. Moreover it is secure.

>         How do DAD deal with the case of three nodes A-B-C (B can see
>         both A and C, A and C cannot see each other) when node A and C
>         choose the same link-local IP for their interface ?
> 
> 
>     If I had to deal with it I would use a link-layer solution (a
>     bridge), such that DAD messages see all three nodes A, B and C.
> 
>     Comments?
> 
> 
> This is a very special case that cannot be assumed in general.

What is special?  The fact that I don't use a bridge?  The fact that 
there is no A-B-C problem?

I think rather this is the most generic thing which happens the most 
often. (rather than the A-B-C situation which has to be created 
specially and artificially).

> The case 
> scenarios) happen. We have to deal with that case in MANETs.

I think the case described by Henning (A-B-C) is a special case which 
needs special treatment.  IT has to be set up specially in order to 
observe it; it is not obvious.

> As the 
> "When more specific assumptions can be made regarding the connectivity 
> to other interfaces on the link, these SHOULD be considered when 
> configuring subnet prefixes."

The link I mentioned above (wrongly a 'subnet' maybe) has no prefix 
configured on it, other than the fe80::/10 prefix.

This is not a specific assumption, but something that works out of the 
box, just set the link-layer, put the interfaces up and ping.  This is 
the first thing one sees when setting such an 'ad-hoc' network.  That's 
why I consider it general.

More people can set this no-A-B-C case than people can set the A-B-C case.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Sep 2009 11:39:08 +0200

Henning Rogge a écrit :
> Do you use wireless radios for your MANET ?

Yes.

 > If yes the A-B-C szenario is one

That is a problem.  I need at least 100 meters of linear distance to set 
this A-B-C problem up.

However, my setup is on a smaller than 50meter radius scale.

I think more people have 50m radius to test with than 100m.

If I had 100m to test with and three nodes then the 'B' node would be a 
bridge solving the A-B-C problem.

Comments?

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 1 Sep 2009 10:42:07 +0100

You didn't ask me to discuss DAD etc., you asked what a
MANET was. And RFC 2501 is still the baseline document
for the MANET WG. And it explicitly discusses doing
routing at L3. You say you solve the A - B - C problem
at L2. Fine, many people create MANETs at L2. That is
not however what we are doing here, and RFC 2501 is
entirely to the point. If you are going to dismiss the
A - B - C issue as "solve at L2" you are doing something
quite different, and any conclusions you draw without it
are entirely beside the point here. In what we are doing
here, the A - B - C (or non-transitivity of connectivity)
is an inevitable problem and has the consequences for
considering link local addresses that have been discussed.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 01 September 2009 10:27
To: Dearlove, Christopher (UK)
Cc: Ryuji Wakikawa; [email-masked]
Subject: Re: [Autoconf] call for consensus about link local address support

                    *** WARNING ***

Alex

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2009 11:43:25 +0200

> specially and artificially).
I totally disagree with you, I think the A-B-C case is THE typical basic block 
of a larger mesh network. A node which stands between two other nodes which 
cannot see each other.

If you have a mesh without this your cannot even create a multihop MANET 
without multiple interfaces on each node !

> I think more people have 50m radius to test with than 100m.
I think what people use for testing does not matter at all. What matters is 
deployment of MANETs and they are typical deployed in scenarios where you need 
multihop forwarding because some nodes cannot see each other.

> bridge solving the A-B-C problem.
You limit your autoconf sollution to networks where every node can see every 
other node. That's not a MANET in my oppinion.

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 1 Sep 2009 11:44:20 +0200

Alex,

you are describing your testbed that is limited to 50 meters. Tell me, how
would you handle the following case: Every person in Paris has a wireless
device (i.e. mobile phone with 802.11). How would you configure such a MANET
with DAD and link-locals? And I mean configure on L3, not on L2 (which would
be outside the scope of AUTOCONF)

Ulrich

Ulrich

On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu <
[email-masked]> wrote:

>> of the most primitive things you can do with three nodes (and enough
>> distance to prevent direct communication between node A and C).
>>
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 1 Sep 2009 10:47:00 +0100

>> of the most primitive things you can do with three nodes (and enough
distance 

> However, my setup is on a smaller than 50meter radius scale.

"There are more things in heaven and on earth that are dreamed of in
your philosophy."

> I think more people have 50m radius to test with than 100m.

Actually, our interest is in what people really want in practical
situations than in testing. Yes, testing over longer ranges is
moree difficult. But as longer ranges are reality, testing has to
follow reality. (In fact I'd rather have kilometres than hundreds
of metres in many cases.)

> bridge solving the A-B-C problem.

You have missed the point of ten years of work in this community
(and more before that).

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Sep 2009 11:49:49 +0200

Ulrich Herberg a écrit :
> Alex,
> 
> you are describing your testbed that is limited to 50 meters. Tell me, 
> how would you handle the following case: Every person in Paris has a 
> wireless device (i.e. mobile phone with 802.11). How would you configure 
> such a MANET with DAD and link-locals? And I mean configure on L3, not 
> on L2 (which would be outside the scope of AUTOCONF)

Ulrich,

It is obvious that a large network such that you describe (15million 
devices in a city) need IP routers and wouldn't work solely with IPv6 
link-local addresses.

Many setups each limited to 50meters could be inter-connected by IP 
routers.  A few by L2 bridges.

It is not clear though how large networks does AUTOCONF address.

I sense there is a private assumption that the AUTOCONF mechanism should 
work at the scale of an large network (your Paris question makes think 
so)... this should be clarified - how large the AUTOCONF network looks like?

Alex

> 
> Ulrich
> 
> Ulrich
> 
> On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu 
>         of the most primitive things you can do with three nodes (and
>         enough distance to prevent direct communication between node A
>         and C).
> 
> 
>     That is a problem.  I need at least 100 meters of linear distance to
>     set this A-B-C problem up.
> 
>     If I had 100m to test with and three nodes then the 'B' node would
>     be a bridge solving the A-B-C problem.
> 
>     Comments?
> 
>     Alex
> 
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 01 Sep 2009 11:53:35 +0200

> "There are more things in heaven and on earth that are dreamed of in

Call me ignorant while you're at it - won't solve the AUTOCONF issues.

> of metres in many cases.)

Hmm...

> You have missed the point of ten years of work in this community

I vote for a) and that's it for today.

Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 1 Sep 2009 11:59:48 +0200

Alex,

> routers.  A few by L2 bridges.

You mean a real setting? Or your testbed? As Chris mentioned, testbeds
should reflect reality, and I don't think that a testbed contained in a 50m
radius reflects any real setting. At least it's not the most general case.
The Paris example is something more realistic, even though a solution has to
cope with that. In an addressing document, we will not talk about the size
of the MANET.

> so)... this should be clarified - how large the AUTOCONF network looks like?

We are talking about an addressing document here (not a solution). This
document will not say: "your MANET may not exceed 50 meters in diameter and
may not have more than 100 nodes".

Ulrich

>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>    Henning Rogge a écrit :
>>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 1 Sep 2009 11:21:23 +0100

I might not go as far as the Paris scenario as a first typical use case.
But suppose we have a number of users (tens at least, maybe more)
scattered over an area which is hundreds of metres wide, with radios
with ranges of order of magnitude 100 metres, and moving about
within that area and/or moving such that the area they cover also
moves. Movement is at least partly random (i.e. topology varies).

 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ulrich Herberg
Sent: 01 September 2009 11:00
To: Alexandru Petrescu
Cc: [email-masked]
Subject: Re: [Autoconf] call for consensus about link local address support

                    *** WARNING ***

Alex,

On Tue, Sep 1, 2009 at 11:49 AM, Alexandru Petrescu <[email-masked]> wrote:

	Ulrich Herberg a écrit : 

		you are describing your testbed that is limited to 50 meters. Tell me, how would you handle the following case: Every person in Paris has a wireless device (i.e. mobile phone with 802.11). How would you configure such a MANET with DAD and link-locals? And I mean configure on L3, not on L2 (which would be outside the scope of AUTOCONF)

	It is obvious that a large network such that you describe (15million devices in a city) need IP routers and wouldn't work solely with IPv6 link-local addresses.
	
	Many setups each limited to 50meters could be inter-connected by IP routers.  A few by L2 bridges.

You mean a real setting? Or your testbed? As Chris mentioned, testbeds should reflect reality, and I don't think that a testbed contained in a 50m radius reflects any real setting. At least it's not the most general case. The Paris example is something more realistic, even though a solution has to cope with that. In an addressing document, we will not talk about the size of the MANET.

	I sense there is a private assumption that the AUTOCONF mechanism should work at the scale of an large network (your Paris question makes think so)... this should be clarified - how large the AUTOCONF network looks like?

We are talking about an addressing document here (not a solution). This document will not say: "your MANET may not exceed 50 meters in diameter and may not have more than 100 nodes".

Ulrich

		On Tue, Sep 1, 2009 at 11:39 AM, Alexandru Petrescu <[email-masked] <mailto:[email-masked]>> wrote:
		
		   Henning Rogge a écrit :

		
		           If I had to deal with it I would use a link-layer solution
		           (a bridge),
		           such that DAD messages see all three nodes A, B and C.

		   Yes.

		

		
		   Comments?
		
		   Alex

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 1 Sep 2009 12:30:13 +0200

I admit that I chose an extreme example which may not be the first use case
(at least not yet). However, even for that extreme example, the addressing
document in its current version would be applicable. And in that scenario
(even in much smaller scenarios), the mentioned A-B-C scenario would be
encountered all the time and could probably not be fixed with bridges, so
using link-locals has some severe problems.

Ulrich

P.S. According to Wikipedia, Paris has 2.2 million inhabitants and the
metropolitan area around 11 million ;-)

On Tue, Sep 1, 2009 at 12:21 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Ulrich Herberg
> *Sent:* 01 September 2009 11:00
> *To:* Alexandru Petrescu
> *Cc:* [email-masked]
> *Subject:* Re: [Autoconf] call for consensus about link local address
> support
>
>                     *** WARNING ***
>
>>> such a MANET with DAD and link-locals? And I mean configure on L3, not on L2
>>> (which would be outside the scope of AUTOCONF)
>>>
>>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 1 Sep 2009 12:36:18 +0200

> metropolitan area around 11 million ;-)
A manet with millions of nodes is just a few years away... At 
Freifunk/Olsr.org we have tested a network with 1000 nodes and hope we can 
extend our software to city-meshes with 10000+ nodes. But I don't think 
100.000 or even a million nodes is impossible, it will just require more 
applied research. ;)

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 1 Sep 2009 15:47:05 +0200

For support of millions of nodes, I think using a backbone 
makes sense. Luckily, this is in place.
All we have to do is provide topologically correct addresses
and select the direct path to nearby nodes and the path to a
border router to nodes that are beyond some limit.
Not available today with IETF protocols, but for sure possible
and more or less operational already.

Teco.

|Van: Henning Rogge
|Am Tue September 1 2009 12:30:13 schrieb Ulrich Herberg:
|> P.S. According to Wikipedia, Paris has 2.2 million inhabitants and the
|> metropolitan area around 11 million ;-)
|A manet with millions of nodes is just a few years away... At
|Freifunk/Olsr.org we have tested a network with 1000 nodes and hope we
|can
|extend our software to city-meshes with 10000+ nodes. But I don't think
|100.000 or even a million nodes is impossible, it will just require more
|applied research. ;)
|
|Henning Rogge

---

From: Stan Ratliff <[email-masked]>
Date: Tue, 1 Sep 2009 11:08:22 -0400

Hello Ryuji,

Another vote for option (b).

Regards,
Stan

On Sep 1, 2009, at 4:30 AM, Ulrich Herberg wrote:

> Hello Ryuji,
>
> I agree with Charlie and support (b). In my opinion, there are still  
> many unresolved issues with link-locals in MANETs and could delay or  
> even limit solutions. The document should not prohibit link-locals  
> though (which it does not), it just does not require them.
>
> Regards,
> Ulrich
>
> On Tue, Sep 1, 2009 at 9:41 AM, Charles E. Perkins <[email-masked] 
> > wrote:
>
> Hello Ryuji,
>

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Wed, 2 Sep 2009 01:25:35 +0200

Hi Ryuji, all, 

> Please review the following call for consensus and vote your 
> opinion by Sep10th.
> 
> If you have another alternative, please propose it and give 
> your reasons why you prefer that alternative.
> 

a) is my preference, narrowed down to *IPv6* link-locals.

This is about the ad hoc addresssing model. I'm not entirely sure what
"shall support" means in this context. However, for the sake of
completeness, the document should acknowledge the existence of IPv6
link-local addresses, state compliance (or not) with what existing RFCs
mandate w.r.t. link-locals, describe their use in MANET routing and/or
data forwarding, as well as mention potential pitfalls associated with
their use.

If/when the WG moves on to discussing "solution space", it may decide to
concentrate on mechanisms for the auto-configuration of global addresses
and ULAs. At the Stockholm meeting there already seemed to be concensus
on doing so. I am fine with that.

Thanks,
Ronald in 't Velt
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: mase <[email-masked]>
Date: Wed, 02 Sep 2009 09:32:04 +0900

I vote for b.

Thanks,
Kenichi

---

From: Henning Rogge <[email-masked]>
Date: Wed, 2 Sep 2009 08:37:43 +0200

> data forwarding, as well as mention potential pitfalls associated with
Okay, it seems we have a problem with the wording of a) and b).

When I read the options a) and b) I was a little bit unsure what to do with 
them. I talked with Ulrich Herbert about it and we decided that a) means that 
ALL autoconf drafts have to support link-local addresses while b) means that 
link-local support is not mandatory for autoconf sollutions, but may be 
included in drafts as a feature.

The other viewpoint I had for the two options was that a) means link-local 
support is considered for documents of the autoconf WG, but b) means that it 
is 'out of scope' of this working group.

Can someone confirm we have an issue or that I'm just confused ?

I see potential THREE options being discussed:

1) link-local support should be mandatory for autoconf. Every autoconf draft 
working on the problem configuring interfaces must support link-local IPs.

2) link-local support is optional for autoconf. It's within the are of this 
WG, but not all autoconf drafts need to support it. Drafts MUST state if they
support link-local IPs or not.

3) link-local support is out of scope for this WG. They should not be included 
into autoconf drafts.

I thought that a) means 1) and b) means 2), but I'm not sure if parts of this 
group think that b) means 3).

Henning Rogge

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 2 Sep 2009 09:20:11 +0200

Hi Ronald,

I agree with Henning. When I read your answer, I was not sure whether your
arguments are really for vote a). In my opinion, the argument would fit to
b) as well.

Am Wed September 2 2009 01:25:35 schrieb Velt, R. (Ronald) in 't:
> > link-local addresses,

IMO, the document does not (and will not) deny the existence of IPv6 link
locals. It just does not mandate that such an address must be
auto-configured by a solution. It does not exclude so either, due to some
pitfalls, as you say.

> state compliance (or not) with what existing RFCs

Erik Nordmark wrote a -- as I think -- very useful paragraph about the
pitfalls of link-locals. That could be included in the document, I suggest.

On Wed, Sep 2, 2009 at 8:37 AM, Henning Rogge <[email-masked]> wrote:

> them. I talked with Ulrich Herbert

It's Herber*g* :-p

> about it and we decided that a) means that

I let others (Ryuji?) confirm (or not) this possible wording issue.

Ulrich

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 2 Sep 2009 16:35:31 +0900

Hi

> 3) link-local support is out of scope for this WG. They should not  

This consensus call is only for our single WG item, "IP Addressing  
Model in Ad Hoc Networks".
We seek the consensus whether we will deal with link-local address or  
not in this work.

a) The link-local address is supported for MANET nodes.
b) The link-local address is not supported and not defined for MANET  
nodes in the document.
      The difficulty and possible problems of the link-local addresses  
in MANET will be explained in the document.

regards,
ryuji

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 2 Sep 2009 10:49:09 +0200

Even further confused.
I still vote for A, as link-locals are required on IPv6 nodes [RFC4291], 
for sure for router interfaces [RFC4861].
As Ronald pointed out, the addressing model is just the addressing model
and not the requirements document for Autoconf solutions. And I also felt
that we had consensus in Stockholm on including link-locals in the document
(is A), but with clarifying text (as Erik Nordmark provided, and where I
suggested some updates).
I see 4 options on the table:
1: link-locals are not configured on interfaces in a MANET
2: link-locals are configured on interfaces in a MANET, but not used
3: link-locals are configured on interfaces in a MANET, but used only where 
   applicable
4: we need an address autoconfiguration mechanism for link-local addresses
in
   a MANET.
I think we end up somewhere between 2 and 3 (A??). Erik his text was more or

less 2, my adjustment "up/downgraded" to 3.

I don't understand some of us worked on OSPF-MANET, but vote for B. If B is
1 (or 2?), I expect some clarifications.
There is a lot of stuff around, requiring ND. Any idea how to support this?

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Ryuji Wakikawa
|Verzonden: woensdag 2 september 2009 9:36
|Aan: Henning Rogge
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] call for consensus about link local address
|support
|
|Hi
|
|On 2009/09/02, at 15:37, Henning Rogge wrote:
|
|> Am Wed September 2 2009 01:25:35 schrieb Velt, R. (Ronald) in 't:
|>>> a) The document shall support link-local addresses as required
|>>>  for nodes in a MANET in addition to unique-local and global
|>>>  addresses.
|>>>
|>>> b) Support unique-local and global addresses as required for MANET
|>>>  nodes.  The document shall not prohibit using link-local addresses,
|>>>  but shall describe the difficulties inhibiting compliance in MANET
|>>>  with the standardized IPv6 properties that characterize the use of
|>>>  link-local addresses.
|>>
|>> a) is my preference, narrowed down to *IPv6* link-locals.
|>>
|>> This is about the ad hoc addresssing model. I'm not entirely sure
|>> what
|>> "shall support" means in this context. However, for the sake of
|>> completeness, the document should acknowledge the existence of IPv6
|>> link-local addresses, state compliance (or not) with what existing
|>> RFCs
|>> mandate w.r.t. link-locals, describe their use in MANET routing and/
|>> or
|>> data forwarding, as well as mention potential pitfalls associated
|>> with
|>> their use.
|> Okay, it seems we have a problem with the wording of a) and b).
|>
|> When I read the options a) and b) I was a little bit unsure what to
|> do with
|> them. I talked with Ulrich Herbert about it and we decided that a)
|> means that
|> ALL autoconf drafts have to support link-local addresses while b)
|> means that
|> link-local support is not mandatory for autoconf sollutions, but may
|> be
|> included in drafts as a feature.
|>
|> The other viewpoint I had for the two options was that a) means link-
|> local
|> support is considered for documents of the autoconf WG, but b) means
|> that it
|> is 'out of scope' of this working group.
|>
|> Can someone confirm we have an issue or that I'm just confused ?
|>
|>
|>
|>
|> I see potential THREE options being discussed:
|>
|> 1) link-local support should be mandatory for autoconf. Every
|> autoconf draft
|> working on the problem configuring interfaces must support link-
|> local IPs.
|>
|> 2) link-local support is optional for autoconf. It's within the are
|> of this
|> WG, but not all autoconf drafts need to support it. Drafts MUST
|> state if they
|> support link-local IPs or not.
|>
|> 3) link-local support is out of scope for this WG. They should not
|> be included
|> into autoconf drafts.
|
|
|This consensus call is only for our single WG item, "IP Addressing
|Model in Ad Hoc Networks".
|We seek the consensus whether we will deal with link-local address or
|not in this work.
|
|a) The link-local address is supported for MANET nodes.
|b) The link-local address is not supported and not defined for MANET
|nodes in the document.
|      The difficulty and possible problems of the link-local addresses
|in MANET will be explained in the document.
|
|
|regards,
|ryuji
|
|>
|>
|> I thought that a) means 1) and b) means 2), but I'm not sure if
|> parts of this
|> group think that b) means 3).
|>
|> Henning Rogge
|>
|> *************************************************
|> Diplom Informatiker Henning Rogge
|> Forschungsgesellschaft für
|> Angewandte Naturwissenschaften e. V. (FGAN)
|> Neuenahrer Str. 20, 53343 Wachtberg, Germany
|> Tel.: 0049 (0)228 9435-961
|> Fax: 0049 (0)228 9435-685
|> E-Mail: [email-masked]
|> Web: www.fgan.de
|> ************************************************
|> Sitz der Gesellschaft: Bonn
|> Registergericht: Amtsgericht Bonn VR 2530
|> Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender
|> (Stellv.)
|>
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 2 Sep 2009 15:36:44 +0100

> for sure for router interfaces [RFC4861].

The suggested compromise in Stockholm was that IPv6 nodes
would have link local addresses, but they might not be used,
and wouldn't be the intended target of autoconf.

> And I also felt
> (is A)

This is showing where the A/B distinction may not be clear.

The consensus in Stockholm was definitely not for A as I
understood it from Ryuji's post. The consensus was, I agree,
not to say that "link local addresses are prohibited" but, as
I understood it, it was for "we will design an autoconf
mechanism that will hand out addresses, those addresses will
be global or unique local". (Those are only meant to be rough
statements, not precise ones.)

> I see 4 options on the table:

Yes, it isn't simply A/B.

> 1: link-locals are not configured on interfaces in a MANET

That I think is not allowed.

     applicable

I'll come back to those.

> 4: we need an address autoconfiguration mechanism for link-local
addresses
     in a MANET.

That I think is not going to work, because that will bog down the group
(in fact I think it will kill it) while the conflicting "whatever
addresses
you need will be visible two hops away" and "link local addresses should
not be seen more than one hop away" requirement and position deadlock.

> I think we end up somewhere between 2 and 3 (A??).

Agreed, it is somewhere in the 2 to 3 range. But I see that as B, not A,
where either we have 2, or we have 3, and "autoconfigured by a mechanism
designed in the autoconf group" is considered not applicable for link
local addresses.

> Erik his text was more or

> 1 (or 2?), I expect some clarifications.

I think even 3, subject to the comments I made above (maybe call that
2.5)
could be B.

I suggest that rather than the A/B thing, someone appropriate
sets out what they think the Stockholm consensus was (it will take
a few bullet points) and sees who can support it. I think that
will actually show more agreement that is currently appearing,
and if there is disagreement, will focus it on key points.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 2 Sep 2009 17:36:42 +0200

> statements, not precise ones.)

I also felt like the Stockholm consensus was more along the lines described
above by Chris, with an accompanying, explicit warning about the use of LLs
(for which Erik proposed some initial text in an email he sent during this
very meeting ;)

Anybody else feeling the same?

Emmanuel

---

From: Stan Ratliff <[email-masked]>
Date: Wed, 02 Sep 2009 12:23:53 -0400

Ryuji,

You confused me with that response. Your last articulation of option (b)
is NOT something I'd support, as it appears to totally preclude use of
link locals. I'm much more in favor of the initial option (b) text,
which is:
  "Support unique-local and global addresses as required for MANET
nodes. The document shall not preclude using link-local addresses, but
shall describe the difficulties inhibiting compliance in MANET with the
standardizes IPv6 properties that characterize the use of link-local
addresses."

Regards,
Stan

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 2 Sep 2009 19:01:32 +0200

I am in favor of B by the way (to be a little more explicit than my previous
email ;).cheers,
Emmanuel

---

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Sep 2009 14:07:44 -0400

> I still vote for A, as link-locals are required on IPv6 nodes

I agree. I've been hesitant to jump into this discussion, but it is a
requirement that all IPv6 interfaces have a link-local address.

For autoconf to somehow think it doesn't need a LL address or is
exempt from having one, makes me scratch my head in confusion.

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 2 Sep 2009 11:24:49 -0700

> From: Thomas Narten [mailto:[email-masked]]
> Sent: Wednesday, September 02, 2009 11:08 AM
> To: Teco Boot
> Cc: [email-masked]

Yes - all IPv6 interfaces are required to have an IPv6
link-local address. How a MANET interface might *use*
an IPv6 link-local address is out of scope, and should
not be rolled into a single consensus call item.
 
> exempt from having one, makes me scratch my head in confusion.

Right.

Fred
[email-masked]

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Wed, 2 Sep 2009 21:09:56 +0200

Hello Ryuji, 

>This consensus call is only for our single WG item, "IP 
>Addressing Model in Ad Hoc Networks".
>We seek the consensus whether we will deal with link-local 
>address or not in this work.
>
>b) The link-local address is not supported and not defined for 
>MANET nodes in the document.
>      The difficulty and possible problems of the link-local 
>addresses in MANET will be explained in the document.

There was no doubt in my mind what the consensus call is about. I merely
questioned the meaning of the phrase "shall support" with reference to a
document that is an addressing model definition, *not* a protocol
specification. Just semantics, I guess. Given the choice between a) and
b), my preference is still a).

Thanks,
Ronald

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 Sep 2009 09:57:50 -0700

Hello Chris,

Dearlove, Christopher (UK) wrote:
>> I still vote for A, as link-locals are required on IPv6 nodes
>>     
> [RFC4291], 
>   

In an effort to promote further consensus, I would support this
statement, but...  (see below).
>   
>> And I also felt
>> that we had consensus in Stockholm on including link-locals in the
>>     
> document
>   
>> (is A)
>>     
>

I liked that you used "or" between "global" and "unique local".  This 
definitely
matches my preference.

> That I think is not allowed.

Where is it disallowed?

What if _every_ MANET interface configures exactly
the same link-local address but (see below)...
>> 2: link-locals are configured on interfaces in a MANET, but not used

that widely-assigned link-local address is "not used" ... or ....

>> 3: link-locals are configured on interfaces in a MANET, but used only
>>     
> where 
>      applicable
>   

that widely-assigned link-local address is never "applicable"
> I'll come back to those.
>
>   
>> 4: we need an address autoconfiguration mechanism for link-local
>>     
> addresses
>      in a MANET.
>

Yes, I agree this is poison, not to mention absolutely unnecessary.

> and if there is disagreement, will focus it on key points.

Fine with me, except that it opens the door to incessant
disagreement on what the consensus was.

I'd prefer to see if we could get at least a rough consensus
on one of the two choices.  I also don't think they are so
hard to understand.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 Sep 2009 12:40:52 -0700

Hello Fred,

I'll ask you the same question I asked Chris:

> not be rolled into a single consensus call item.

What if the SAME link-local address were assigned to EVERY
manet node in the network, and it was NEVER used?

Then we have satisfied the claimed requirement.

>> exempt from having one, makes me scratch my head in confusion.

Well, "autoconf" doesn't "think".  But I think that we don't need
the LL addresses.  In fact I am sure of it.  The only rationale
for requiring them (_in the general case_) is to satisfy the demands
of those people who are so insistent that we have to have them.

Not that they would necessarily be used for anything at all.

Not that the mandate to have them would be enforceable.

It's just busy work and yet another roadblock to progress.

Of course, as has been stated many many many times in
the past, if your design can benefit from LL addresses, there
is absolutely no prohibition against their use.

But if my design cannot use them, you will still insist
that I create them and let them sit in some dark unused
corner of protocol requirement hell.

Or else some people will scratch their head in puzzlement.

Never mind that link-locals are, to say the least, adverse to
wireless mobility and are best suited for nodes that are
either not wireless or not mobile.

Regards,
Charlie P.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Sep 2009 16:49:42 -0400

> manet node in the network, and it was NEVER used?

Why do we worry (and focus?) on these sorts of bizarre and unlikely
cases? Is this WG intentionally trying to focus on scenarios that are
unsolvable? 

Reality check for a moment. LL addresses (in IPv6) are generated off
of a MAC address. These are highly likely to be unique. 

And if MAC addresses are not unique, what that means is that you have
multiple interface cards that use the same MAC address on the same
network. Bad things tend to happen when you try to operate networks
with such characteristics, because there are all sorts of assumptions
built into various protocols that MAC addresses will be unique. Even
if you somehow managed to assign unique addresses in this case, things
would still likely not work right because of the duplicate MAC
addresses underneath.

My point; if you have multiple identical LL addresses on your local
network, you probably have BIG problems already, and autoconf is the
least of your worries.

If the reason folk don't want to use LL is that they might not be
unique, can we please instead break this into two problems:

 1) assume LL address are unique and go from there, develop some
 approaches and solutions

 2) assume they are not unique and spend another 3 years spinning your
    wheels on a very hard problem. (And please, make this a separate
    document and mailing list, so folk interested in option 1 can
    focus on that.)

Thoma

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 Sep 2009 14:14:08 -0700

Hello Fred,

Templin, Fred L wrote:
> Charlie,
> What kind of a question is that? Configure the link-locals
> as you would for any other interface and such a scenario
> would never arise - use the link-locals between consenting
> nodes if you'd like, too. That's all.
>   

Can't do it.  Can't guarantee uniqueness across time and space.
Can't use DAD for link-locals.

So I can't "Configure the link-locals as you would for any other interface".

Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Wed, 2 Sep 2009 22:38:52 +0200

> either not wireless or not mobile.
we might even have a "best of both worlds" approach.

If we have a protocol that calculates routing-scope unique addresses for each 
interface, we could just use this protocol to calculate routing-scope unique 
link-locales.

In my understanding of IPv6 link-local addresses must be unique AT LEAST on 
the link, so using a routing-scope autoconf for them would be okay.

This way we still could using link-local IPs (which will be not forwarded 
beyond the link), it will be just another approach to get them.

At least this would be an optional possibility to use it, if someone does not 
need link-local IPs and does not care about the "IPv6 must have them", they 
can be just droped.

Henning Rogge

---

From: Thomas Narten <[email-masked]>
Date: Wed, 02 Sep 2009 17:28:34 -0400

> Now this is a great idea.  Let's have an autoconf effort for those
> who assume unique LL addresses.  And let's have a separate autoconf
> effort for those who do not.  I'll be in the second camp, and we
> already have working code.

Yep, I hear there is working code all over the place. That's nice.

Now why can't we translate that into a useful specification?

(My possibly biased answer: because this group can't agree on even the
most basic lowest-common denominator underlying assumption about
anything. And if you can't agree on any underlying base line, there is
little point in trying to develop any solution, since it clearly won't
mean the various assumptions people have.)

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 Sep 2009 14:24:06 -0700

Hello Thomas,

> cases? Is this WG intentionally trying to focus on scenarios that are

Quite the opposite, I am very sure.  I think we ought to focus on scenarios
that are solvable.  Which does not always include unique link-local.

> of a MAC address. These are highly likely to be unique. 

That argument was deemed not good enough.  A huge battle ensued.  We 
mandated
DAD for IPv6 nodes.  You edited a relevant document, as I remember.

Would you like to say that LL addresses are required when MAC addresses
are unique?

> network. 
Or you don't have MAC addresses.

> Bad things tend to happen when you try to operate networks
> with such characteristics,

There are 4 billion nodes out there doing it today.  O.K. with me if you
want to say they are bad.

>  because there are all sorts of assumptions
This is not true.  See above!  However, you are really zeroing in on the
point -- which is that if you can't already guarantee MAC layer addresses
are unique, you are biting off a huge chunk to try to guarantee that LL
addresses are unique.  UNLESS, that is, you have the luxury of a very
very nice broadcast medium.

Which we don't.

> network, you probably have BIG problems already, and autoconf is the

My point: you don't need to mandate LL addresses in all cases -- which
completely then circumvents the problem (BIG or not).

>  1) assume LL address are unique and go from there, develop some

For mobile wireless nodes, that is a very restrictive assumption.  But I 
agree that
once you make the assumption, you can make solutions.  That, 
unfortunately, don't
apply in the problem space of interest.

>     document and mailing list, so folk interested in option 1 can

Now this is a great idea.  Let's have an autoconf effort for those who 
assume
unique LL addresses.  And let's have a separate autoconf effort for 
those who
do not.  I'll be in the second camp, and we already have working code.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 02 Sep 2009 15:21:09 -0700

Hello Thomas,

> Now why can't we translate that into a useful specification?

We did.  It triggered the formation of the working group.  Then we 
needed to make
a problem statement.  Then some people thought the problem had to do 
with link-local
addresses instead of getting autoconfiguration to work in the scenarios 
that were the
impetus for the people starting the working group.  Then a process of 
years of
compromise, discussion, and non-consensus evolved.
> mean the various assumptions people have.)

As you point out, there may be two camps:
- People who insist on having link-locals, and
- People who don't.
Maybe they're not compatible.

I'm happy to have two different discussions and
two different specification efforts.

Are you expressing a low opinion of working code
and systems?

Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 2 Sep 2009 13:36:20 -0700

Charlie,

> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Wednesday, September 02, 2009 12:41 PM
> To: Templin, Fred L
> Cc: Thomas Narten; Teco Boot; [email-masked]

Fred

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 3 Sep 2009 10:10:51 +0100

> definitely matches my preference.

I have no idea whether people thought they were supporting exclusive
or inclusive or. It wasn't something I thought about, and don't have
a view on.

>> That I think is not allowed.

As I recall, someone (the minutes will probably indicate who, they
are pretty extensive) quoted from the IPv6 RFC (I should have noted
that this is an IPv6 comment only) that said (roughly) that an
interface must have a link local address.

> that widely-assigned link-local address is never "applicable"

The "all the same" part I have no idea about. The "never used"
option (which one of your two I don't know) was suggested in
Stockholm.

> disagreement on what the consensus was.

I think incessant disagreement is endemic here.

> on one of the two choices.  I also don't think they are so

I think the key point is that A/B as worded aren't doing
that job. I was suggesting (but might be wrong) that it
would be easier to achieve consensus starting from one
statement that, if necessary, was tweaked, rather than
start from two statements that polarise.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 3 Sep 2009 10:54:28 +0100

I believe
- Yes, you can generate LL addresses as Thomas indicates.
  That satisfies some requirements.
- However those are not the routable address needed, as they
  are local.
- The autoconf work is to generate those addresses, to be used
  by MANET routing protocols, and then by applications.
- We also need those other addresses for even link symmetry
  checking if there is a prohibition on link local addresses
  being seen non-locally, as the physics is non-transitive,
  and that's not changing.
- Trying to argue about two-hop (or, with mobility, MANET
  wide) visibility of link local addresses is doomed to spin
  wheels - in my estimation until the WG dies.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Thomas Narten
Sent: 02 September 2009 21:50
To: Charles E. Perkins
Cc: [email-masked]
Subject: Re: [Autoconf] call for consensus about link local address
support

                    *** WARNING ***

Thoma

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Sep 2009 12:06:57 +0200

> - However those are not the routable address needed, as they

Yes, but they should be used as src/dst fields in messages exchanging 
routing information data (if the routing protocol exchanges messages 
like OSPF does).

They [link-local addresses] can also be used as src/dst fields in 
AUTOCONF messages which allocate new unique global or unique-local 
addresses.

For example - an AUREQ (address uniqueness request) with link-local 
src/dst which is sent and re-sent across a "MANET" to request if a 
certain global address exists already.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 3 Sep 2009 11:29:19 +0100

You are assuming that you are allowed to distribute a link
local address across an entire MANET. People do that, and
it can work. But other people aren't happy with that being
permitted by the definition of link local, as it will mean
that router A with no connection to router B will receive
router B's link local address (via at least router C). That
happens even just for router C transmitting router A's
address to establish that it has a symmetric link to router A,
due to the physical nature of wireless broadcast.

If we say this (non-local link local addresses) is what we are
doing, that will not (in my and other people's estimation) get
a consensus of any sort in a useful timescale. So my view is
that, for pragmatic reasons at least, let's not do that, and
concentrate on autoconfiguration of addresses that can
definitely be used non-locally, and which we also need
for other purposes.

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: 03 September 2009 11:07
To: Dearlove, Christopher (UK)
Cc: Thomas Narten; Charles E. Perkins; [email-masked]
Subject: Re: [Autoconf] call for consensus about link local address support

                    *** WARNING ***

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 03 Sep 2009 13:12:51 +0200

Dearlove, Christopher (UK) a écrit :
> You are assuming that you are allowed to distribute a link local 
> address across an entire MANET.

No, I am not assuming a link-local address distributed across an entire
"MANET", but across a link.

A message with a src link-local address received by a "MANET" node can
be re-constructed and re-sent using its own link-local address, by that
node, if needed to go to another link.

In this way, messages with src/dst link-local addresses are not
forwarded outside of a link, but are re-constructed.

> People do that, and it can work. But other people aren't happy with 
> that being permitted by the definition of link local,

I agree a message with a link-local address in src/dst field not to be
forwarded outside of a link.  The message can be re-constructed to
respect this rule.

> as it will mean that router A with no connection to router B will 
> receive router B's link local address (via at least router C).

Not if the src address is re-written (or the message re-constructed).

These are special control messages (not application flows) used for
AUTOCONFing global or unique-local addresses.

> That happens even just for router C transmitting router A's address
> to establish that it has a symmetric link to router A, due to the 
> physical nature of wireless broadcast.
> 
> If we say this (non-local link local addresses) is what we are doing,
>  that will not (in my and other people's estimation) get a consensus
>  of any sort in a useful timescale. So my view is that, for pragmatic
>  reasons at least, let's not do that, and concentrate on 
> autoconfiguration of addresses that can definitely be used 
> non-locally, and which we also need for other purposes.

The first steps of any autoconfiguration mechanism must put something in 
the src/dst fields.  What do you think will be there?  I believe 
link-local addresses in there.

And/or link-scoped multicast addresses.  And/or Link-Local Multicast 
Group for MANET Routers (RFC5498).

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 3 Sep 2009 08:26:52 -0700

Charlie,

> Sent: Wednesday, September 02, 2009 2:14 PM
> To: Templin, Fred L
support
> Can't use DAD for link-locals.

Who said anything about uniqueness? And, it seems like
a rather myopic viewpoint to assert that anything
having to do with a MANET would be "guaranteed".
 
> So I can't "Configure the link-locals as you would for any other
interface".

Sure you can; the specs tell how.

Fred

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 03 Sep 2009 09:47:56 -0700

Hello Chris,

> or inclusive or. It wasn't something I thought about, and don't have

It's not about "exclusive" vs. "inclusive" OR.
I was commenting that OR is better than AND
as a connective between "global" and "unique local".

The reason is that we can't have "global" for
standalone MANETs.  So "AND" would be an
immediate showstopper.

Given "OR", I'm quite sure we would insist on
"inclusive OR".  Exclusive would be silly :-),
although not unfathomable.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 3 Sep 2009 19:30:56 +0200

|Van: Dearlove, Christopher (UK)
|I believe
.....
|- We also need those other addresses for even link symmetry
|  checking if there is a prohibition on link local addresses
|  being seen non-locally, as the physics is non-transitive,
|  and that's not changing.

Not sure on this. When LLs have unique IfId's, there is no 
need for other addresses. Or when unique RouterId's are used.

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 03 Sep 2009 10:53:16 -0700

Hello Fred,

> having to do with a MANET would be "guaranteed".

Well, O.K., if link-locals don't have to be unique, then I am
surprised.  Maybe you didn't mean that.  Are you sure you don't
want unique link-locals?

>  
>   
>> So I can't "Configure the link-locals as you would for any other
>>     
> interface".
>

I must have missed that.  Or else you are thinking about
something different than I am.

Maybe a concrete example will help.

Here are four nodes at time T_0:

                      A --------- B --------- C --------- D

The dashed lines indicate neighborliness at time T_0.
Assume all bidirectional links.

At time T_1, a second later, the neighborhoods
are as follows:

                      A --------- C --------- B --------- D

Please explain how you identify the links upon which
your assignment of link-local addresses are valid, and
indicate a compatible assignment of link local addresses,
and indicate which specs provide you with the protocol
mechanism for carrying out the proposed assignment.
How many links are there in your model of this network?

Do you think your link definition is the only one that should
be considered valid for work in [autoconf]?

Narten's answer was "unique MAC-layer addresses".
Do you agree with that?  Do you think we should restrict
work in [autoconf] to be applicable only to such networks
in which that restriction is valid?

Do you have any intuition about the scalability of the
system resulting from your definitions?

What if you discovered that your definitions resulted in a
system that was three orders of magnitude less scalable than
an alternative that did not impose a requirement for assigning
unique link-local addresses? -- or, a system that, effectively,
didn't even define any broadcast-oriented links at all?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Sep 2009 11:37:16 -0700

Hello folks,

I asked some very pertinent questions to this list a few
weeks ago.

Up until now, no one who has been clamoring for mandatory
inclusion of link-local addresses in [autoconf] design documents
has answered my questions about a very simple network.
Four nodes!

I can tell you_exactly_ how it _can_ work if we don't
MANDATE link-locals, and my solution is scalable.

I think the matter is important enough to deserve a
response -- especially given the amount of time (measured
in _years_!)  demanded by the link-local proponents for
previous discussions of the abstract concepts.

Do any link-local proponents have any answers?
Please see my example network and my questions,
re-posted below.

Regards,
Charlie P.

PS. Again, for the nth time, I am not against link locals.
       I am against mandating their use, and I am against
       requiring all solutions to resolve the issues surrounding
       the assignment of link-local addresses.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Sep 2009 12:15:12 -0700

Charlie,

If you are talking about me, your questions were unanswerable
because you made incorrect first assumptions about my meaning
and then vectored off from there.

Fred

> Sent: Monday, September 21, 2009 11:37 AM
> To: [email-masked]
> Cc: Templin, Fred L

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Sep 2009 12:27:32 -0700

Hello Fred,

I'd appreciate it if you could point out
where I went wrong.

Plus, my example network does not
in any way depend on my assumptions
about your meanings.

I'm happy to resume the discussion!
And I really prefer to not be misled
by wrong ideas about what you meant.

Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Sep 2009 12:43:25 -0700

Charlie,

> Sent: Monday, September 21, 2009 12:28 PM
> To: Templin, Fred L
> Cc: [email-masked]

I'm sorry, but I'm not going to get drawn into
an on-list interrogation.

> in any way depend on my assumptions

On this point, we disagree.

Fred

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Sep 2009 14:05:52 -0700

Hello Fred,

> an on-list interrogation.

I'd be happy to carry on privately if you prefer.
I can't remember such a conversation where I was
told that I have wrong assumptions, but that no one
would even tell me which assumptions are wrong
(at least in the engineering realm).

> On this point, we disagree.

How in the heck can different engineering perspectives
be resolved if the proponents won't converse?
My questions were very reasonable, I thought.

If link-local proponents (a) insist that all networks must
have link-local addresses (b) won't answer a question
about how it can be done with four nodes, and (c)
do not desire to tackle the issues online, I am amazed
that we would wait four years for the outcome.

Regards,
Charlie P.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 21 Sep 2009 17:06:28 -0700

Charlie,

There are myriad unspoken assumptions in your messages wrapped
around nodes moving, definitions of "link", *guaranteed*
uniqueness, etc. that are way outside of the scope of what
I have been thinking. But, the way I have been thinking for
link-local configuration is EUI-64 - in particular, when the
L2 address can be statelessly derived from the L3 address
there should be no need to maintain a coherent neighbor cache.

Again, I am thinking only about link-local *configuration*;
what happens after the link-local is configured is out of
scope for what I have been meaning to convey.

Fred

> Sent: Monday, September 21, 2009 2:06 PM
> To: Templin, Fred L
> Cc: [email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Sep 2009 22:16:12 -0700

Hello Fred,

Thanks for the honor of your reply.  Turns out we may not
be very far apart after all.

Of course I have no objection whatsoever to carrying out the
indicated link-local address formation for EUI-64 derived addresses.
I'm very happy if there is a statement somewhere that nodes should
do this when they have been configured with known-unique
such addresses.  I also agree with you that the neighbor cache
would not need additional maintenance in that case.  Furthermore,
I also think that the *use* of such configured addresses does not
have to be in scope for the [autoconf] discussion.

The point of my example was almost precisely that I do _NOT_
have assumptions about the definitions of "link", and I had
wanted to draw out your assumptions for further inspection.
I do _NOT_ have other unspoken assumptions, except for
the one assumption that I think we ought to be having
honest discussions about what can, cannot, should, and,
should not be assumed.  If you find in any of my messages
the unspoken assumptions, you should point them out to
me.  Otherwise I really insist on not fitting that description.

If anyone else wants to take a crack at my four-node
example, and suggest their solution, I'd still like to
see it.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 23 Sep 2009 19:27:43 +0200

Charles, sorry for late reply.

Charles E. Perkins a écrit :
[...]

[...]

> indicate a compatible assignment of link local addresses,

I assume in your sketch that C and B each has two interfaces, and that a 
single segment is 50m long and that the link-layer technology is wifi.

How to identify the links?  Each link (a segment) is a different SSID. 
This is a field in each 802.11 header of each packet.

The link-local address assignment is like this:

   A(fe80::MAC_FFFE1)---(fe80::MAC_FFFE2)C(fe80::MAC_FFFE3)-...
   ...---(fe80::MAC_FFFE4)B(fe80::MAC_FFE5)---(fe80::MAC_FFE6)D

The notation fe80::MAC_FFFEx means the IPv6 link link-local address 
derived from the MAC address of that interface and having FFFE in the 
middle somewhere, as per rfc2464.

> mechanism for carrying out the proposed assignment.

RFC2464 is sufficient for self-forming the link-local addresses.

> How many links are there in your model of this network?

Three links - as many as segments.

> be considered valid for work in [autoconf]?

The above (mine?) link definition is ok for the purpose of my prototype. 
  This is straightforward and should not be forbidden.

As for the change in topology from A-B-C-D to A-C-B-D from T_0 to T_1 - 
your challenge should dissected in the separate steps:

A-B-C-D        T_0
A- -B-C-D      T_1
A -B- -C-D     T_2
A -C- -B- -D   T_3
A-C- -B-  -D   T_4
A-C-B- -D      T_5
A-C-B-D        T_6

At T_1 A and B realize they can no longer talk  to each other.  They do 
so with NUD.

At T_2 B and C realize can't reach each other.  Also NUD.

At T_3 C and D realize can't reach each other.  Also NUD.

At T_4 A and C realize they can talk to each other.  By using periodic 
NAs, RSs, RAs.

At T_5 B and C can talk, they discover that also with NA.

Finally, at T_6 B and D talk (also discover that with NA).

Of course, until now A can not send a packet with a dst address D, 
because only link-local addresses are used above.  In order to achieve 
A-to-D communnication, a mechanism for global address (or ULA) and 
subnet prefix assignment should be used.

This can be achieved as follows:
-on each interface of each node pre-configure a unique /64 subnet
  prefix.
-designate A and D to send Router Advertisements with prefixes that
  should be interpreted as to install in the receivers' routing tables
  (an extended "intepretation" of RFC4191 "more specific routes").
-designate B and C to also send such extended RAs but _only_ if there
  isn't already somebody else sending such an extended RA on that link,
  or if a new NA is heard from a neighbor it hasn't seen before.

This should be done carefully such as to avoid loops.

So, what do you think Charlie?  And of course - what do the others think?

> Do you agree with that?

I agree unique MAC-layer addresses are helping forming unique IPv6 
link-local addresses.

> Do you think we should restrict

Of course, I don't agree restricting work.  I don't agree forbidding 
link-local addresses either.

> system resulting from your definitions?

Hmm... tough question.  I believe the method I presented above should 
scale well provided (1) all nodes are pre-configured with prefixes 
unique and (2) MAC addresses are unique.  But I have of course some doubts.

But whereas you're very specific A-B-C-D to A-C-B-D you don't say how 
would you like it to scale: would it always be rectilinear scaling (max 
2 interfaces per node)?  Something else?

> didn't even define any broadcast-oriented links at all?

This is speculation from your part.  You are asking to compare against 
something that you don't say what is.

(no offence pointing at 'you' - it is more or less intended response to
  previous comments :-)

Yours,

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 23 Sep 2009 19:42:56 +0200

[...]

> -on each interface of each node pre-configure a unique /64 subnet

And of course, people are interested in more than simply pre-configuring 
  /64 unique prefixes on each node.  This can be achieved as follows:

-designate A to be a DHCPv6 server having a pool of such prefixes to use
  with a technique called "prefix delegation" RFC number here.
-designate B, C and D to request a prefix each time they think their
  neighbors on one interface has changed.
-designate B, C and D to RA that prefix on the other interface (on the
  interface different from the one where it received the prefix).  If
  there's only one interface then don't advertise on the "other"
  interface because it doesn't exist.
-Designate B and C to become DHCP Relays once they have received a
  prefix (following a change in the neighbor state).

In this sense - what do you think?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 23 Sep 2009 19:50:36 +0200

>  with a technique called "prefix delegation" RFC number here.

And of course, it may be possible that it is not liked that a single 
designated machine (A) acts as a DHCPv6 server and the others not.

IF this is the case then modify the behaviour as follows:

-all nodes are tentative DHCP Servers.  Each is pre-configured with
  a unique _pool_ of prefixes (meaning A has p1, p2 and B has p3, p4).
-add a new field in RA which says "I want to act as a DHCP server".
-any node can become an "acting" or "elected" DHCP Serverprovided it has
  not already received an RA saying somebody else is a tentative DHCP
  Server.

This should be done carefully such as to avoid a situation where nobody 
becomes a DHCP Server because everybody else wants to.

And of course, it may replied that pre-configuring pools of prefixes is 
not enough self-configuration...

Alex

>> would you like it to scale: would it always be rectilinear scaling 
>> (max 2 interfaces per node)?  Something else?
>>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 23 Sep 2009 11:07:50 -0700

Hello Alex,

Alexandru Petrescu wrote:
> I assume in your sketch that C and B each has two interfaces, and that 
> a single segment is 50m long and that the link-layer technology is wifi.

The way I think of it, C and B have a single network interface.  Each 
segment is
only meant to signify a relatively reliable signal path.  A packet 
transmitted by
C would be detectable by both A and B (almost) simultaneously, if we 
disregard
propagation delays.  Link-layer technology isn't specified, but WiFi 
would give
good intuition.

> This is a field in each 802.11 header of each packet.

Do you mean to specialize your solution to situations where the SSID
can be used to identify intended recipients?

> middle somewhere, as per rfc2464.

Check.

> RFC2464 is sufficient for self-forming the link-local addresses.

Check.

> Three links - as many as segments.

Check.

> The above (mine?) link definition is ok for the purpose of my 
> prototype.  This is straightforward and should not be forbidden.

I'm quite sure no one would forbid such a
model of link establishment.  That would be
wrong.

>
> As for the change in topology from A-B-C-D to A-C-B-D from T_0 to T_1 
> - your challenge should dissected in the separate steps:
>
> A-B-C-D        T_0
> A- -B-C-D      T_1
> A -B- -C-D     T_2
> A -C- -B- -D   T_3
> A-C- -B-  -D   T_4
> A-C-B- -D      T_5
> A-C-B-D        T_6
>
> At T_1 A and B realize they can no longer talk  to each other.  They 
> do so with NUD.
>

The timeouts for these operations are not compatible with
the expected rate or motion.  If the internodal distances are
50 meters, then the transition time between the illustrated
two network configurations would not likely be as low as
1 second.  Then you might have enough time for occasionally
correct operation  -- but I'm sure there would be failures
anyway.

If the transition happens in 1 second, your RAs need to
arrive perhaps as often as 100ms apart.  If there were
20 nodes instead of 4, your advertisement period might
be as low as 5ms.  You would have a massive problem
with collisions of advertisements unless you synchronize
and stagger the RAs.  The synchronization problem by
itself will cause you to age prematurely.

You can't rely on NUD.  For example, it requires
active signaling:
> Receipt of other Neighbor Discovery messages such as Router
>    Advertisements and Neighbor Advertisement with the Solicited flag set
>    to zero MUST NOT be treated as a reachability confirmation. 

So if you want to overlay active confirmations on top
of the passive one-way path verifications, you will
compound the problems mentioned above that are
due to frequent transmissions of RAs.

Basically, even for four nodes, I think you are hosed,
and for 20 nodes, it borders on insanity.  We have
been able to show operation of AODV for
thousands of nodes.  Still needs improvements!
But, if we were MANDATED to run RAs and NUD,
it would be absolutely and irretrievably unattainable.

> subnet prefix assignment should be used.

Check.

> -on each interface of each node pre-configure a unique /64 subnet
I'd say one per node.

>  or if a new NA is heard from a neighbor it hasn't seen before.

In the initial configuration, when does B learn that it can
communicate directly with C?  As long as C is happy with
D and B is happy with A, they might never learn about
each other.

> I agree unique MAC-layer addresses are helping forming unique IPv6 

This has never been at issue, but of course I do agree with you.

> link-local addresses either.

I don't remember anyone forbidding link-local addresses.

> (max 2 interfaces per node)?  Something else?

I'm not sure what rectilinear scaling would be, but I would
not expect most networks to necessarily conform to any
rectilinear layouts.  The other networks are, however, much
harder to draw with ASCII stick figures.

> something that you don't say what is.

I'm thinking about AODV-style networks with hundreds
or thousands of nodes.
> (no offence pointing at 'you' - it is more or less intended response to

Absolutely no offense taken, and thanks for the time you
spent to make the reply.

Regards,
Charlie P.