Re: [Autoconf] Updated ad hoc addressing model document

["Teco Boot" <[e-mail]>]

Hi Charlie,

Also sorry for late response.


>> ... existing IP addressing models don't depend on such clever
>> thing. Here, we have the "assumption". Right?
>
>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.

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 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.
>
>I didn't see which model you meant.

How do IEEE 802.11 IBSS users configure their network today?


>>> 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.
>>
>> OK, now we are there.
>> MANET protocols that use RFC5498 can perfectly use link-locals.
>> 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.

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.


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

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.


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

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?


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

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.


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

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. 


>>> And that is the problem needing solution in the
>>> general case, which has motivated the current form
>>> 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?
>
>I have IPv6 in mind.  The general case does not
>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!


>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?

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


Regards, Teco