Re: [Autoconf] Updated ad hoc addressing model document

"Teco Boot" <teco@inf-net.nl> Sat, 30 January 2010 11:21 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1016B3A67F6 for <autoconf@core3.amsl.com>; Sat, 30 Jan 2010 03:21:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8iirRlHCkGn for <autoconf@core3.amsl.com>; Sat, 30 Jan 2010 03:21:40 -0800 (PST)
Received: from CPSMTPM-EML102.kpnxchange.com (cpsmtpm-eml102.kpnxchange.com [195.121.3.6]) by core3.amsl.com (Postfix) with ESMTP id 9C8D93A67AB for <autoconf@ietf.org>; Sat, 30 Jan 2010 03:21:38 -0800 (PST)
Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML102.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sat, 30 Jan 2010 12:22:03 +0100
From: "Teco Boot" <teco@inf-net.nl>
To: "'Charles E. Perkins'" <charles.perkins@earthlink.net>
References: <be8c8d781001260409qd23d4era0eac47eaeb3dba2@mail.gmail.com> <8DCBF4A4-7879-4148-A8FE-9A73219536B9@gmail.com> <008c01caa0fe$0eee3530$2cca9f90$@nl> <4B631699.7040504@earthlink.net> <009001caa10d$8729a2a0$957ce7e0$@nl> <4B6347DA.1040004@earthlink.net>
In-Reply-To: <4B6347DA.1040004@earthlink.net>
Date: Sat, 30 Jan 2010 12:22:00 +0100
Message-ID: <00a601caa19e$7122c810$53685830$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcqhI2CYrfC3lkyqSIm4UUM5KirB6AAegQTA
Content-Language: nl
X-OriginalArrivalTime: 30 Jan 2010 11:22:03.0481 (UTC) FILETIME=[72B46490:01CAA19E]
Cc: autoconf@ietf.org, 'Thomas Heide Clausen' <thomas@thomasclausen.org>
Subject: Re: [Autoconf] Updated ad hoc addressing model document
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jan 2010 11:21:41 -0000

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.


>>>> And the text on link locals does not describe how IPv6 works. LLs
>are
>>>> used in MANETs for multiple purposes. We can't without.
>>>>
>>>>
>>> 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.
>>
>
>O.K.
>
>> One can think of updating the IPv6 RFCs. I'll stay on current
>> practice.
>>
>
>Me, too.
>
>Current practice includes running AODV and OLSR and DYMO.

These protocols use link-locals, when RFC5498 and RFC3484 are 
implemented.


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


Regards, Teco.