[Autoconf] AUTOCONF, addresses and routing

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 22 July 2010 20:17 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 3F9363A684A for <autoconf@core3.amsl.com>; Thu, 22 Jul 2010 13:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.963
X-Spam-Level:
X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_05=-1.11, 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 IqlN-DnIFSf6 for <autoconf@core3.amsl.com>; Thu, 22 Jul 2010 13:16:59 -0700 (PDT)
Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id E5BCE3A680D for <autoconf@ietf.org>; Thu, 22 Jul 2010 13:16:57 -0700 (PDT)
Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id AB23E9400BA for <autoconf@ietf.org>; Thu, 22 Jul 2010 22:17:10 +0200 (CEST)
Message-ID: <4C48A745.7050608@gmail.com>
Date: Thu, 22 Jul 2010 22:17:09 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1
MIME-Version: 1.0
To: "autoconf@ietf.org" <autoconf@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 100722-1, 22/07/2010), Outbound message
X-Antivirus-Status: Clean
Subject: [Autoconf] AUTOCONF, addresses and routing
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, 22 Jul 2010 20:17:00 -0000

Teco and I expressed a doubt about my draft being appropriated to
AUTOCONF or not.
(http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00)

I believe route updating may need to be an aspect in AUTOCONF work - it
must be coupled to the address auto-conf otherwise addresses won't be
routable.

Details:

In general I see my draft mostly about routing because its main novelty
is the insertion of entries in the routing table following reception of
RA, and then route accordingly.

Another point is that I believe, in the future, AUTOCONF work will hit
on the necessity to couple the address auto-configuration mechanism with
a means to update routing.

Why am I saying this?

Because it is the case for DHCP, for example. If DHCP Prefix Delegation
is used to assign a prefix to a MR, then it would work ok as is between
Server and MR.  However, (some months ago it was the case), it is
impossible to use DHCP Relays - in practice it breaks.  Or, the topology
DHCPSserver--Relay--MR is of paramount importance in a multi-hop
wireless mobile network.

Why DHCP Prefix Delegation breaks on Relays?  Because Relay does not
insert a routing table entry with respect to the prefix it just
delegated.  To solve it, one would require the Relay to insert an entry
in the routing table.

This is one kind of solution.

I believe with other routing protocols (OSPF, more) it is also the case:
whenever an address is assigned across hops the routing table entries
must be updated.  And this is not specified today - address
auto-configuration is decoupled from route updating, hence routing breaks.

This is why I believe route updating may be an aspect in AUTOCONF work -
it must be coupled to the address auto-conf otherwise it won't work.

(Too: an important point in the draft is it relies on link-local
addresses between the MRs, without which it wouldn't work.)

Alex