Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal.

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 29 June 2010 12:34 UTC

Return-Path: <alexandru.petrescu@gmail.com>
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 688273A6AE1 for <autoconf@core3.amsl.com>; Tue, 29 Jun 2010 05:34:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.318
X-Spam-Level:
X-Spam-Status: No, score=-0.318 tagged_above=-999 required=5 tests=[AWL=-0.483, BAYES_40=-0.185, HELO_EQ_FR=0.35]
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 w5GDf-b4E0eL for <autoconf@core3.amsl.com>; Tue, 29 Jun 2010 05:34:46 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 830A33A6893 for <autoconf@ietf.org>; Tue, 29 Jun 2010 05:34:43 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o5TCYf13004519 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <autoconf@ietf.org>; Tue, 29 Jun 2010 14:34:42 +0200
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o5TCYfuF030090 for <autoconf@ietf.org>; Tue, 29 Jun 2010 14:34:41 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o5TCYfLK026140 for <autoconf@ietf.org>; Tue, 29 Jun 2010 14:34:41 +0200
Message-ID: <4C29E861.4080706@gmail.com>
Date: Tue, 29 Jun 2010 14:34:41 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: autoconf@ietf.org
References: <BFD8FF22-FD36-436E-9985-7BFA2E234081@gmail.com> <201006290803.34192.henning.rogge@fkie.fraunhofer.de>
In-Reply-To: <201006290803.34192.henning.rogge@fkie.fraunhofer.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Subject: Re: [Autoconf] Call for comments to a new AUTOCONF charter proposal.
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: Tue, 29 Jun 2010 12:34:47 -0000

Le 29/06/2010 08:03, Henning Rogge a écrit :
> On Tue June 29 2010 06:20:28 Ryuji Wakikawa wrote:
>> Description of Working Group:
>>
>> RFC 5889 presents one possible IPv6 addressing model for ad hoc nodes. In
>> this model the ad hoc routers need to configure their network interface(s)
>> with addresses valid in the ad hoc network, and may configure additional
>> prefixes for use by attached nodes.
>>
>> After completing the work on RFC 5889, the main purpose of the AUTOCONF WG
>> is to standardize how existing IPv6 address configuration tools can be
>> used for address configuration:
>>
>> 1. A DHCPv6-based mechanism for configuring required interface addresses
>> for the routers in the ad hoc network. This mechanism is expected to
>> produce addresses with properties outlined in RFC 5889. This mechanism
>> uses the existing DHCPv6 protocol unchanged, and assumes a central node
>> that can allocate addresses on a first-come-first-served basis. Other
>> nodes in the ad hoc network will relay messages to the central node in
>> order to help a new node get an address for itself. This mechanism is only
>> suitable for deployments were a central node can be set up. It should be
>> noted that many existing deployments employ Internet gateways that can act
>> as such a central node as well. Future extensions such as central node
>> election may make this mechanism suitable for also for stand-alone ad hoc
>> networks.
 >
> I don't think elections are a good way to add redundancy for an address
> configuration system. The dependency of a single node in the whole network to
> configure the addresses will be a bottleneck for larger mesh networks.

But elections is what gets rid of central node bottlenecks... if that 
single node fails then elect another.

>> 2. A DHCPv6-based mechanism for delegating a prefix(es) to each router for
>> use by applications running on the routers themselves, or for
>> configuration of attached hosts/networks. This mechanism works in a
>> similar manner to the one above, but allocates prefixes instead of
>> addresses.
>
> I don't see a difference between 1 and 2, for IPv6 case 1 is just case 2 with
> a prefix length of 128 (or 64 if we use the IPv6 autoconf postfix).

To my quick reading 2) does prefixes too whereas 1) does addresses only.

Alex

>
> --------------
> Does this proposal mean the autoconf group will not work on a distributed
> address configuration scheme for mesh networks ?
>
> Henning Rogge
>
>
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf