Re: [Autoconf] Updated ad hoc addressing model document

["Charles E. Perkins" <[e-mail]>]

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

On 2/16/2010 8:33 AM, Teco Boot wrote:

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

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.

...


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

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

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

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

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

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.


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

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

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

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


> IMHO the MANET routing protocol extends the communication
> capability from single-hop to multi-hop. We know how to this.

Thank goodness!

> But:
> The MANET addressing model shall not limit single hop
> communication in cases where the MANET routing protocol
> is inactive. This is my requirement.

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

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

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

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

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.

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

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


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

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

Nope, nopity, nope, nope, nope.

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


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

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

> I can't see how we can do this without prefix swapping, where
> the prefix comes from the border router.

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

> And for smooth
> address swapping, I suggest not repeating address uniqueness
> testing.

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

> So I suggest to use unique InterfaceIDs. By nature,
> by good randomization and / or by duplicate check.

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?


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

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
> also!

And who claimed otherwise??


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

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.