Subject: Re: [Autoconf] Updated ad hoc addressing model document

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 4 Feb 2010 13:43:03 +0100

On Jan 30, 2010, at 12:22 PM, Teco Boot wrote:

> Charlie,
>
>>>>> My requirement is that L3 communication between nodes, that have  
>>>>> L2
>>>>> connectivity, must be possible in all conditions, including
>> conditions
>>>>> with a non-operational MANET protocol.
>>>>>
>>>>>
>>>> I don't see that the addressing model prevents any such L3
>>>> communication.
>>>>
>>> How are packets forwarded?
>>> The destination address (which is direct L2 neighbor in this case)
>>> needs to be found in a forwarding table, normally the routing table.
>>> Neighbor cache could be used also.
>>> How to get this info in such a table?
>>>
>>
>> Node A broadcasts a "Hello" message.
>> Node B hears it, and puts node A in its forwarding table.
>>
>> The nodes may take subsequent actions to verify
>> bidirectionality, exchange other table entries, etc.
>
> My point is that L3 communication becomes dependent on a L3 routing
> protocol. We didn't have this in the IP stack before.

Well.....L3 communication depends on a populated routing table, thus  
on something populating the routing table.
L3 multi-hop communications depends on something clever (a routing  
protocol, a DHCP server, a human, for example and depending on the  
place) populating routing tables.

I do not see what this document does that changes that?

>> One should think of updating the IPv6 RFCs, since the link-local
>> constructions contained therein were written _explicitly_ in
>> disregard of the needs for wireless links of the sort familiar to
>> practitioners in this group.
>
> I use link-locals on wireless links, and it works great.
> What is your point?

I am not Charlie, so I won't speak to what his point is.....but a  
point can be made that you have observed a particular and specific  
setup in which this holds true. That's good!

This document aims at describing something that can hold in more than  
one particular  and specific setup and, if respected, will allow  
unencumbered operation, outside of a particular and specific setup.

Cheers,

Thomas

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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 4 Feb 2010 13:43:08 +0100

Dear Teco,

Thanks for your review. See comments below.

On Jan 29, 2010, at 17:13 PM, Teco Boot wrote:

> Ryuji, Thomas,
>
> I commented on the document.
> I don't see any reflection in the document, nor received questions
> for clarification.
>
> I am quite uncomfortable with a large drawback of the proposed
> addressing model, which makes it unacceptable for the deployed MANETs
> I am involved in.
> My requirement is that L3 communication between nodes, that have L2
> connectivity, must be possible in all conditions, including conditions

I would wonder if you have a MANET if you are not running a MANET  
protocol?

That said, I am not sure I understand what the drawbacks you identify  
are. The document takes the "most conservative" approach, i.e. a  
network in which interfaces are configured in accordance to this,  
should allow any operation. The document, as I read it, uses "should",  
which does not prohibit alternatives (with the usual caveat concerning  
a "should").

I believe that if you have no "MANET protocol", but still want L3  
communication between identified interfaces (IP addresses), then you  
would want a mechanism/protocol assigning these addresses? For the  
reasons outlined in that document, those addresses should (to allow  
any operation / any protocol to operate) satisfy the suggested rules  
in the document. If you do deviate from the "should", the usual  
caveats for a "should" apply -- and it might be OK for your deployment?

Cheers,

Thomas

> Maybe this drawback is overlooked or underestimated.
>
> And the text on link locals does not describe how IPv6 works. LLs are
> used in MANETs for multiple purposes. We can't without.
>
> My other comments are textual or on incompleteness. Especially, the
> document doesn't describe anything useful for assigning globals.
>
> Regards, Teco
>
>
>> -----Oorspronkelijk bericht-----
>> Van: [email-masked] [mailto:[email-masked]]  
>> Namens
>> Ryuji Wakikawa
>> Verzonden: woensdag 27 januari 2010 9:00
>> Aan: Emmanuel Baccelli
>> CC: [email-masked]
>> Onderwerp: Re: [Autoconf] Updated ad hoc addressing model document
>>
>> Hi all,
>>
>> Emmanuel updated the document according to the WG last call.
>> Please confirm the changes specially if you sent comments during  
>> WGLC.
>>
>> We will pass this document to Jari for the next stage soon.
>>
>> thanks,
>> ryuji
>>
>>
>> On 2010/01/26, at 4:09, Emmanuel Baccelli wrote:
>>
>>> Folks,
>>>
>>> here's an updated version of the ad hoc addressing model document,
>> following the comments gathered during working group last call. We  
>> took
>> as much as possible on board, as discussed on the mailing list.  
>> Please
>> review this revision, and let us know if you have further comments.
>>>
>>> http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-02.txt
>>>
>>> Regards,
>>>
>>> Emmanuel
>>>
>>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 4 Feb 2010 13:43:11 +0100

On Jan 29, 2010, at 19:04 PM, Teco Boot wrote:

<SNIP>

>>
>> This isn't true.  You can build MANETs without using link-local at  
>> all
>> in any fashion.
>>
>> I'm not saying you have to ignore link-local.
>
> If LLs are configured, they are used for L2 address resolving.
> Also for MANET protocols, if destination address is LL mcast.

I do not think that this document speaks to multicast addresses at all.

Thomas

---

From: Zach Shelby <[email-masked]>
Date: Thu, 4 Feb 2010 15:22:46 +0200

On Feb 4, 2010, at 14:43 , Thomas Heide Clausen wrote:
> I would wonder if you have a MANET if you are not running a MANET protocol?
> 
> That said, I am not sure I understand what the drawbacks you identify are. The document takes the "most conservative" approach, i.e. a network in which interfaces are configured in accordance to this, should allow any operation. The document, as I read it, uses "should", which does not prohibit alternatives (with the usual caveat concerning a "should").
> 
> I believe that if you have no "MANET protocol", but still want L3 communication between identified interfaces (IP addresses), then you would want a mechanism/protocol assigning these addresses? For the reasons outlined in that document, those addresses should (to allow any operation / any protocol to operate) satisfy the suggested rules in the document. If you do deviate from the "should", the usual caveats for a "should" apply -- and it might be OK for your deployment?

I agree with this interpretation. The autoconf addressing model doesn't prevent you from applying another mechanism in addition to the (really minimal) base it provides. At least this is what we are doing in 6lowpan. The autoconf model provides a way to model these "links with undetermined properties" in a pretty clean way (best I have seen so far... it is a mind-boggling problem). On top of that we are defining a mechanism to bootstrap nodes, configure addresses etc. which works without a routing protocol, or with one (e.g. RPL or MANET). This doesn't directly apply to your case, just an example.

So to really make such a network work you have options like:

autoconf + manet (all nodes must be routers)
autoconf + something (no routing)
autoconf + something + manet (maybe to also support hosts?)
autoconf + 6lowpan-nd + rpl (typical 6lowpan setup right now)

I guess autoconf as a WG will go on to define "something", or at least identify "something(s)" at some point? At least it would be useful to help people really apply this model in practice.

Zach

>>> Van: [email-masked] [mailto:[email-masked]] Namens
>>> Ryuji Wakikawa
>>> Please confirm the changes specially if you sent comments during WGLC.
>>> 
>>> following the comments gathered during working group last call. We took
>>> as much as possible on board, as discussed on the mailing list. Please

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 04 Feb 2010 14:55:50 +0100

Le 04/02/2010 13:43, Thomas Heide Clausen a écrit :
>>> This isn't true. You can build MANETs without using link-local at all
>>> in any fashion.
>>>

Well I think it should :-)

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 4 Feb 2010 15:22:52 +0100

Hi Thomas,

>Van: Thomas Heide Clausen [mailto:[email-masked]]
>Verzonden: donderdag 4 februari 2010 13:43
>Aan: Teco Boot
>CC: 'Charles E. Perkins'; [email-masked]

Up to now, all IP addressing models I am aware of provide 1-hop L3
communication between nodes that have L2 connectivity.

The proposed addressing model for MANETs breaks this. Now there
is a need for something clever. This clever thing could be
stopped. 

>unencumbered operation, outside of a particular and specific setup.

There is no reason not using link-locals for 1-hop traffic.
If you say this is a particular and specific setup, is this a 
qualification for IPv6?
If not, what are you referring to?

Regards, Teco.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 4 Feb 2010 19:08:05 +0100

> is a need for something clever. This clever thing could be

What makes the route to the 'local network' appear in the routing  
table? In that case the 'something clever' is whatever enters that  
route. Often, that 'something clever' is the same thing as what  
configures the interface....

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 04 Feb 2010 10:14:29 -0800

Hello Teco,

> communication between nodes that have L2 connectivity.

If I get your point, what you mean is that when two nodes
share a link, they can use L3 protocols to communicate.

As far as I understand it, the addressing model does not
change this.  IP supports point-to-point communication
between such "adjacent" nodes.

How adjacency is discovered is usually considered
out of scope.  Either subnet prefixes are "assigned"
(suddenly, it doesn't look like a Manet anymore)
or "discovered" (oops, we're running new protocols)
or "assumed".  In the latter case, you'd better make
your assumptions minimal, or else (protocol-wise)
you are moving back into traditional a fixed network
model.  I know it's nicer there and all.

> is a need for something clever. This clever thing could be

I do not agree with this.  See above.  I also do not
agree that we must avoid being clever.  However,
I agree that simpler is better, all the while adhering
to Einstein's famous dictum.

> If not, what are you referring to?

I read this, and had to smile.  Of course there's no reason
to avoid link-locals for 1-hop traffic as long as you _know_
it's one hop.  In fact, blast away.

But for people who are running networks without such
comforts, assurance of availability for a L2 communication
channel is often necessary or at least highly desirable.
Then suddenly your link-local address is potentially
(a) invalid (b) unavailable or (c) ambiguous.  These
are normally considered poor indicators for IP-based
communications.

And that is the problem needing solution in the
general case, which has motivated the current form
of the addressing model document.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 5 Feb 2010 09:09:03 +0100

Hi Thomas,

>configures the interface....

The IP stack puts the configured prefixes on IP interfaces in the 
routing table. This provides L3 connectivity whenever there is a L2
link. 
The 'something clever' puts longer prefixes in the routing table.
This could introduce multi-hop paths for 1-hop reachable nodes, for sure
when link metrics are in place. And of course multi-hop paths to nodes
that are in the MANET, but not 1-hop reachable.

I strongly disagree with "that 'something clever' is the same thing as 
what configures the interface". Our old charter was clear the Autoconf
mechanism shall be independent of MANET protocols.

Regards, Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 5 Feb 2010 09:09:17 +0100

Hi Thomas,

>CC: 'Ryuji Wakikawa'; [email-masked]

The MANET protocol could get stopped, e.g. maintenance.
I am involved in MANETs in real world deployments. The requirement
comes from operational needs.

>which does not prohibit alternatives (with the usual caveat concerning

I thought we should work on a practical addressing model.
In practice, it is useful to have IP access to nearby nodes,
also when the MANET protocol is non-operational.

>would want a mechanism/protocol assigning these addresses? 

I don't want "no MANET protocol".
I want L3 connectivity when there is a L2 link, and the MANET protocol
is non-operational.

>           For the

Yes, we all are free to ignore the document.
But there were strong opinions that the defined addressing models shall 
work in all scenarios?

The addressing model I use works great for all proactive MANET protocols
I am aware of. 
For the reactive routing protocols, there are some implementation issues:
The RREQ should be triggered after "address not reachable", i.e. interaction
with ARP/ND.

Regards, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 5 Feb 2010 09:38:58 +0100

Hi Charlie,

>model.  I know it's nicer there and all.

Thanks for this analysis.

>I do not agree with this.  See above.

It is fact of life that the "clever thing could be stopped".
And existing IP addressing models don't depend on such clever 
thing. Here, we have the "assumption". Right?

>               I also do not
>agree that we must avoid being clever.

Agreed. That is why I use an addressing model that is better resistant
against failures.

>       However,

OK, now we are there.
MANET protocols that use RFC5498 can perfectly use link-locals.
Same for L2 address resolving, as ND does.

>are normally considered poor indicators for IP-based

What happens if your ULA or global is (a) invalid,
(b) unavailable or (c) ambiguous? 
I don't see a difference with link-locals.
Link-locals are used for protocols that require 1-hop
communication or when no other addresses are available.
In the latter, it is also 1-hop only.

>of the addressing model document.

With IPv6 in mind, the general case can easily include
link-locals. Wouldn't it be nice to support IPv6 basics?

Regards, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 5 Feb 2010 12:24:28 +0100

Hi Zach,

>are. The document takes the "most conservative" approach, i.e. a network
>in which interfaces are configured in accordance to this, should allow
>any operation. The document, as I read it, uses "should", which does not
>prohibit alternatives (with the usual caveat concerning a "should").
>>
>reasons outlined in that document, those addresses should (to allow any
>operation / any protocol to operate) satisfy the suggested rules in the
>document. If you do deviate from the "should", the usual caveats for a
>"should" apply -- and it might be OK for your deployment?
>
>I agree with this interpretation. The autoconf addressing model doesn't
>prevent you from applying another mechanism in addition to the (really
>minimal) base it provides. At least this is what we are doing in
>6lowpan. The autoconf model provides a way to model these "links with
>undetermined properties" in a pretty clean way (best I have seen so
>far... it is a mind-boggling problem). On top of that we are defining a
>mechanism to bootstrap nodes, configure addresses etc. which works
>without a routing protocol, or with one (e.g. RPL or MANET). This
>doesn't directly apply to your case, just an example.
>
>I guess autoconf as a WG will go on to define "something", or at least
>identify "something(s)" at some point? At least it would be useful to
>help people really apply this model in practice.
 
The first, "autoconf + manet" is not complete. We need L2 address 
resolving. To me, it is obvious to use ND (to stay on IPv6).
This makes the list like this:
autoconf + ND + manet (all nodes must be routers)
                      (maybe to also support hosts?)
autoconf + ND         (no routing)
autoconf + 6lowpan-nd + rpl (typical 6lowpan setup right now)

rpl is member of MANET protocol family, 6lowpan-nd is ND extension.
So the list is:
autoconf + ND* + manet* (all nodes must be routers)
                        (maybe to also support hosts?)
autoconf + ND*          (no routing)

My BRDP autoconf proposal runs on ND. Then, we have:
ND* + manet* (all nodes must be routers)
             (maybe to also support hosts?)
ND*          (no routing)

BRDP is easy to integrate in rpl. I am open for other ideas.
Good to know there are MANET protocols that support attached "satellite"
hosts.

Regards, Teco

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 5 Feb 2010 15:10:45 +0100

Dear Teco,

> The 'something clever' puts longer prefixes in the routing table.

That's your idea of what constitutes "something clever".....I never  
said that.

> what configures the interface".

I think it is quite clever when (quoting you): "The IP stack puts the  
configured prefixes on IP interfaces in the  routing table."

> Our old charter was clear the Autoconf

I do not see anything in this document which imposes a MANET protocol.

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 5 Feb 2010 17:36:34 +0100

Thomas,

Is this catching words?

Agreed that standard "not that clever" behavior of the IP stack is
putting prefixes, configured on interfaces, in the routing table?

Agreed that putting other prefixes is 'something clever'?

Agreed that with the proposed addressing model, under conditions that
the 'something clever' is not functioning, L3 communication fails for
links between two nodes that have L2 communication?

If I am missing something, please come up with it.

Regards, Teco

>Verzonden: vrijdag 5 februari 2010 15:11
>Aan: Teco Boot
>CC: [email-masked]

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 5 Feb 2010 18:48:37 +0100

Dear Teco,

> Is this catching words?

Not at all. It was explaining what I meant by "something clever" --  
you, incorrectly, read something into that phrase that wasn't intended.

> links between two nodes that have L2 communication?

No, I do not agree with the above.

> If I am missing something, please come up with it.

That's not how it works.

There's a document that has attained what appears to be relatively  
wide consensus. You state that there's something wrong with the  
document and that you have an "alternative model". That's fair enough,  
but then the onus is on you to explain what is wrong, lay out your  
"alternative model", and make sure that in doing so it addresses also  
the concerns which draft-ietf-autoconf-adhoc-addr-model raise.

Absent that (and we have had since the Stockholm IETF), I propose that  
we move forward draft-ietf-autoconf-adhoc-addr-model.

Sincerely,

Thomas

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 05 Feb 2010 10:19:12 -0800

Hello Teco,

> routing table. This provides L3 connectivity whenever there is a L2

You used "configured" in a magic way.
Where did the configuration arise?

> that are in the MANET, but not 1-hop reachable.

O.K.

> mechanism shall be independent of MANET protocols.

I do not remember anyone claiming that they were the same.
What am I missing?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 05 Feb 2010 10:24:16 -0800

Hello Teco,

> also when the MANET protocol is non-operational.

Well, as far as I can tell, we have
been doing just that, and in practice
a node can have access to neighbors when
the protocol isn't operational.

> I want L3 connectivity when there is a L2 link, and the MANET protocol

Your wish is granted...

> But there were strong opinions that the defined addressing models shall

Surely, the defined models _do_ work in all scenarios.

Perhaps in some scenarios additional assumptions can be
made for more scalable address aggregation to be
maintained.  Or, were you thinking of something else?

> The addressing model I use works great for all proactive MANET protocols

So does the model in the document under discussion.

> The RREQ should be triggered after "address not reachable", i.e. interaction

I'm wondering about RREQ for link-local addresses.
That seems almost like a contradiction in terms.
I'd prefer to have routes composed of links, not
the other way around.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 5 Feb 2010 19:29:19 +0100

Hi Charlie,

The difference between configured "wide prefix per MANET segment"
versus "longest / non-overlapping prefix prefix per MANET interface"
is that the first is relatively static. The latter needs active
neighborhood discovery.

I say the first one is "less clever" and it is standard IP stack behavior.
Prefix can be learned with ND. Another mechanism is needed for IPv4.

Regards, Teco

>Van: Charles E. Perkins [mailto:[email-masked]]
>Verzonden: vrijdag 5 februari 2010 19:19
>Aan: Teco Boot
>CC: 'Thomas Heide Clausen'; [email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 05 Feb 2010 10:35:34 -0800

Hello Teco,

On 2/5/2010 12:38 AM, Teco Boot wrote:

>
> ... existing IP addressing models don't depend on such clever

First, I do not understand what the "assumption"
is that you mean here.

Second, existing IP addressing models that you
might be referring to, depend on a model of a
link == communication medium that does not pertain
to all ad hoc networks.

> Agreed. That is why I use an addressing model that is better resistant

I didn't see which model you meant.

> Same for L2 address resolving, as ND does.

You can be very mysterious at times.  I admit defeat,
unable to meet the challenge of understanding your meaning.

As you well know, ND works for nodes in range.
As specified now, it does not work for nodes that
are not in range, in case you wanted to tackle the
onerous project of creating a wireless link that
exceeds the transmission range of any node in the
link.

> In the latter, it is also 1-hop only.

Teco, whenever you ask this question, please first
revisit my explanation which I have offered perhaps
a dozen times in the past:
- determining link-local uniqueness should not require
   multi-hop protocol action
- with ad hoc networks, you may not know if a node
   with a link-local address on a particular link
   is actually adjacent/neighboring/in-range/...

On the positive side, you have asked the same
question so many times that I have the answer
instantly at the ready.

> link-locals. Wouldn't it be nice to support IPv6 basics?

I have IPv6 in mind.  The general case does not
easily include link-locals over wireless media.

The particular specializations _may_ include
link-locals.

Wouldn't it be nicer to avoid requiring
particular specializations when the general
case is just waiting for us to quit delaying
and standardize an already-known solution?

Regards,
Charlie P.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 09 Feb 2010 18:17:28 +0100

> links between two nodes that have L2 communication?

I agree with this.

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: Tue, 09 Feb 2010 09:51:11 -0800

Hello Carlos,

Questions/comments inline:

>> putting prefixes, configured on interfaces, in the routing table?

What "not that clever" agent is putting them there?

>> Agreed that putting other prefixes is 'something clever'?

"other prefixes" == ???

>> links between two nodes that have L2 communication?

But the document says:

=>    If L2 communication is enabled between a pair of interfaces, IP
=>    packet exchange is enabled regardless of the IP subnet configuration
=>    on each of these interfaces.

Thus, Teco's assertion is wrong.

It seems to me that each of the three parts quoted above
are either highly questionable, mysterious, or wrong.

What's to agree with?

Regards,
Charlie P.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Tue, 09 Feb 2010 18:57:23 +0100

Hello Charlie,

> >> Agreed that putting other prefixes is 'something clever'?

If an prefix::iid/lprefix on-link address is configured in one
interface, then a route to that prefix prefix:://lprefix is configured
and I can communicate with other addresses of the same prefix on the
same L2 link. If the address is off-link, something else is needed to
communicate.

A good example of the above are link-locals.

With current document, we always need something else to communicate.
This is not something I'm necessarily against, I just said that I agree
that something else is needed with current addressing model.

Carlos

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 16 Feb 2010 16:41:57 +0100

Thomas,

Late response. I have little time to work on Autoconf. 
I have to deploy something. Sorry for that.

>Verzonden: vrijdag 5 februari 2010 18:49
>Aan: Teco Boot
>CC: [email-masked]

I think you miss something important here. 

>> If I am missing something, please come up with it.

I'm posting this issue AFTER testing.
And I'm quite familiar with currently shipped MANET products.
I can't see how these can support the suggested addressing model.
I also asked Mark on this. No response yet !!

Far more important. It doesn't work when I post during WGLC, and it is 
ignored totally. I checked mail archives, there wasn't a single response
form doc editors for clarification, nor corrections in the draft.

>wide consensus. 

OK, this is up to you as chair. But wide consensus?

>                You state that there's something wrong with the

I explained what is wrong. And at least one (Carlos) understands
the issue in the document.

Again, my response during WGLC on this topic:
Page 4:
   If L2 communication is enabled between a pair of interfaces, IP
   packet exchange is enabled regardless of the IP subnet configuration
   on each of these interfaces.
This is only possible if the IP stack is aware of the L2 link between the 
pair of interfaces. One way of establishing this is configure an on-link 
subnet prefix. Now we choose not to configure so, and instead run a MANET
protocol. But this makes IP communication dependent on the MANET protocol, 
which can have a negative effect on managing the network. Think of remote
management and updates on the MANET protocol.

>we move forward draft-ietf-autoconf-adhoc-addr-model.

I might write something. No time today.

Thanks, Teco

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 16 Feb 2010 17:33:50 +0100

Hi Charlie,

Also sorry for late response.

>link == communication medium that does not pertain

No, existing IP addressing models work with non-transitive links
also. When there is a link, there is IP communication.
For example OSPFv2 has the Point-to-MultiPoint mode
to support these networks. You can read RFC2328 for a 
description. There are a huge number of networks that
works this way.

>I didn't see which model you meant.

How do IEEE 802.11 IBSS users configure their network today?

>unable to meet the challenge of understanding your meaning.

Sorry. Maybe I should include a complete packet trace.
In short: OLSR packets source address is typically LL
when using IPv6 LL-MANET-Routers, because LL-MANET-Routers
has scope Link-Local. See RFC5498 for the details.

And the IPv6 stack uses the link-locals for MLD and ND.
Try to get rid of it yourself. You guess need to rewrite 
a lot in the IPv6 stack.

>exceeds the transmission range of any node in the

IP depends on sub-IP links. So yes, you are right.
But what is your message? Can ARP resolve L2 addresses
multi-hop? Do you need something like that?
No, of course not.

IMHO the MANET routing protocol extends the communication 
capability from single-hop to multi-hop. We know how to this.
But:
The MANET addressing model shall not limit single hop
communication in cases where the MANET routing protocol
is inactive. This is my requirement.
Also important, as far as I know, the majority of current
operational MANETs have a common prefix for the MANET segment.
And the MANET routing protocol advertises the /32 "host prefix"
in the MANET, if this address is required to be reachable.
This works great. That is the reason it is deployed so much.

>   multi-hop protocol action

IMHO this answer is incorrect. Or do you use non-link-local
addresses that determine global uniqueness with single-hop
communication? Or addresses with an angel, defending uniqueness?

>   is actually adjacent/neighboring/in-range/...

This is a valid answer. But handling this issue requires an 
update on address selection. So we have to write a draft that
updates RFC3484 one day. Many products in use have a policy
that selects global or ULA over link-local addresses for packets
that may require multi-hop communication. LL addresses should not
be preferred for that.

>question so many times that I have the answer

And there is a good reason for repeating this question.
I'll stop when there is a nice mechanism for IPv6 multi-homed 
MANETs without NAT.
I can't see how we can do this without prefix swapping, where
the prefix comes from the border router. And for smooth
address swapping, I suggest not repeating address uniqueness
testing. So I suggest to use unique InterfaceIDs. By nature, 
by good randomization and / or by duplicate check. 

>easily include link-locals over wireless media.

It is up and running in many scenario's already. I can't 
remember a single issue.
Yes, duplicate testing. That is an issue for non-link-locals
also!

>and standardize an already-known solution?

Yes. But we don't agree on what is used today.

Regards, Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 16 Feb 2010 12:46:43 -0800

Hello Teco,

Replies inline.  I had hoped that my
answers were going to resolve your
issues, but I see there is still
more to be discussed...

> No, existing IP addressing models work with non-transitive links

I don't think anyone is disputing that _some_ of them do.

> also.  When there is a link, there is IP communication.

I don't think anyone is disputing that.

...

> How do IEEE 802.11 IBSS users configure their network today?

A lot of different ways, some of which are quite
incompatible with some ad hoc networks.

> Sorry. Maybe I should include a complete packet trace.

I hope it's possible to exhibit your meaning by distilling
something important out of a mass of information.

> has scope Link-Local. See RFC5498 for the details.

I never denied that some protocols should be allowed
to use link-local addresses.  It seems to me, though,
that various OLSR proponents are very much in favor
of promulgating the existing addressing document.
So, the dichotomy that you seem to suggest does not
exist.  And such false dichotomies have plagued this
discussion for so many years.  And continue to do so,
it seems.

> Try to get rid of it yourself. You guess need to rewrite

Not really.  We did it a very long time ago.
It worked great.

> multi-hop? Do you need something like that?

Me?  Need multi-hop links?  Surely you jest :-).

> capability from single-hop to multi-hop. We know how to this.

Thank goodness!

> is inactive. This is my requirement.

I don't see any suggestion that your requirement
has been contravened.

> This works great. That is the reason it is deployed so much.

I like it.  Why can't we go with that for a while?

> IMHO this answer is incorrect.

I guess you think multi-(L3)hop  protocols can be
used to insure link-local uniqueness.

This is a matter on which consensus might be
measured.  If more people agree with you, then
I'll be surprised.

If it's L2, then it's out of scope for this
discussion.

> communication? Or addresses with an angel, defending uniqueness?

Global uniqueness can be ascertained with
multi-hop protocols.  I can't imagine that
anyone would seriously argue against this.

> update on address selection.

I am sorry, but I think this is one of the most
outrageously wrong proposals you have made.  To put
it mildly, I disagree most vociferously.  I almost
dare you to find a single AD who might agree.

> So we have to write a draft that

Nope, nopity, nope, nope, nope.

This is quite orthogonal to any discussion about
preferring global vs. ULAs.

> I'll stop when there is a nice mechanism for IPv6 multi-homed

So, we can't make an addressing model in [autoconf]
without boiling all 7 NAT oceans?  You can't be
serious.

> the prefix comes from the border router.

That's because you insist on flogging yourself
with link-local bullwhips.

> And for smooth
> testing.

Finally, a statement I can agree with :-).

> So I suggest to use unique InterfaceIDs. By nature,

If you have unique InterfaceIDs, there is _no issue_.
Nothing to talk about.  Zippity nil nada.  So go write
the [autoconf] document that restricts to that
condition.  You'll have lots of friends, I reckon.
It's a different problem (or, more properly, a way
of defining the problem out of existence).  This
is also a point I have tried to make at least a
dozen times.  If that's the universe in which you
are trying to reside, why not do so and formalize
your intent?

> It is up and running in many scenario's already. I can't

You apparently assume unique InterfaceIDs.  I no longer
see where our discussions need to intersect.

> Yes, duplicate testing. That is an issue for non-link-locals

And who claimed otherwise??

> Yes. But we don't agree on what is used today.

The way it seems to me, is that you don't agree
that anyone can use anything else other than
unique InterfaceIDs (i.e., what you use today).

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 16 Feb 2010 13:20:54 -0800

Hello Teco,

I'm not a document author, but I have
been answering your questions.

More comments below.

> I think you miss something important here.

What?  I agree that L2 neighbors can exchange L3 packets
even with no MANET routing protocol operational.  Do you
disagree??!

> ignored totally.

I even disagree with this, since I have not
ignored your postings.  What am I, chopped
liver?  [old New Yorker joke...]

> the issue in the document.

All the defects you have claimed, I have
tried to redress.

> pair of interfaces.

That is tautological.  Let's agree to agree on statements
that are tautological.

> One way of establishing this is configure an on-link
> subnet prefix.

That's one way.

> Now we choose not to configure so, and instead run a MANET
> protocol.

This is hardly the only other choice available.

> But this makes IP communication dependent on the MANET protocol,
> which can have a negative effect on managing the network.

Well, so much for _that_ straw man.  It burned so
easily down to the ground.

>                         Think of remote

I'm thinking about that.  What inference am I
supposed to draw?

Regards,
Charlie P.