Re: [Autoconf] Updated ad hoc addressing model document

Thomas Heide Clausen <thomas@thomasclausen.org> Thu, 04 February 2010 12:43 UTC

Return-Path: <thomas@thomasclausen.org>
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 740573A6849 for <autoconf@core3.amsl.com>; Thu, 4 Feb 2010 04:43:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 yAYX80wUu0Aj for <autoconf@core3.amsl.com>; Thu, 4 Feb 2010 04:43:35 -0800 (PST)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 8899C3A67D8 for <autoconf@ietf.org>; Thu, 4 Feb 2010 04:43:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D2D0B430348; Thu, 4 Feb 2010 04:44:21 -0800 (PST)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from [10.0.2.6] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id CE28343034E; Thu, 4 Feb 2010 04:44:20 -0800 (PST)
Message-Id: <C8A0698C-B04F-475B-B750-842C8786778F@thomasclausen.org>
From: Thomas Heide Clausen <thomas@thomasclausen.org>
To: Teco Boot <teco@inf-net.nl>
In-Reply-To: <00a601caa19e$7122c810$53685830$@nl>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Thu, 4 Feb 2010 13:43:03 +0100
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> <00a601caa19e$7122c810$53685830$@nl>
X-Mailer: Apple Mail (2.936)
Cc: autoconf@ietf.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: Thu, 04 Feb 2010 12:43:36 -0000

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
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf