Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 03 March 2009 15:49 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 061723A67BD for <autoconf@core3.amsl.com>; Tue, 3 Mar 2009 07:49:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[AWL=-0.247, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_13=0.6]
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 C-THVU86R8ZO for <autoconf@core3.amsl.com>; Tue, 3 Mar 2009 07:48:59 -0800 (PST)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id A7CBA3A6452 for <autoconf@ietf.org>; Tue, 3 Mar 2009 07:48:58 -0800 (PST)
Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n23FnOGD006065; Tue, 3 Mar 2009 16:49:24 +0100
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.13.8/8.13.8) with ESMTP id n23FnOiF025871; Tue, 3 Mar 2009 16:49:24 +0100 (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 n23FnOBV002825; Tue, 3 Mar 2009 16:49:24 +0100
Message-ID: <49AD5184.6080300@gmail.com>
Date: Tue, 03 Mar 2009 16:49:24 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Teco Boot <teco@inf-net.nl>
References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl> <49A7E58C.2020303@gmail.com> <007201c99903$c4182c80$4c488580$@nl> <49A82E55.10208@gmail.com> <007b01c99911$907facf0$b17f06d0$@nl> <49A8471E.6090506@gmail.com> <009501c99920$92154340$b63fc9c0$@nl> <49A944FF.9000102@gmail.com> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl>
In-Reply-To: <003001c99b2c$a3fcf4a0$ebf6dde0$@nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] Autoconf addressing model
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, 03 Mar 2009 15:49:00 -0000

Teco Boot a écrit :
> Hi Alex,
> 
> More on "loopback interface".
> And more on non-blocking obstacles.
> 
> 
> 
> |> Check for example ISP BCP, rfc5375
> |
> |Checked.  The fact that Cisco uses 'loopback interface' to be something
> |completely different than the interface holding the loopback address
> |doesn't mean I should too.  I disagree with Cisco on this particular
> |point.
> 
> RFC5373 is not a "Cisco document". It is a IETF product, produced by v6ops.
> V6ops produces informational or BCP RFCs only.
> Many router vendors support loopback interfaces.

> Do you disagree with the v6ops document, best practices of most (all?) ISPs
> and most router vendors?

rfc5373 is not a BCP.  Besides, it is a Request for Comments, so my 
comment is that a loopback interface is not good for what we plan to do 
here.

> ID.autoconf-manetarch-07 section 5.1 also suggests using the loopback
> interface for binding a globally unique address.

My comment to this suggestion is the following: the usage of host-based 
routes effectively limits the size of the domain where that is 
manageable; depending on the link-layer type, it could be less than 
25meters large.  That may exclude connecting to the wider Internet.

> My suggestion is using the loopback interface for the /128 (or /32)
> address(es), not the MANET Interface(s) as suggested in 5.2.

I disagree using /128 host-based routes on the surronding neighbors 
provided we don't have good reason to do so.  And provided /64 routes 
could work as well.


> |> Assigning non-"loopback addresses" on the loopback interfaces is
> |permitted.
> |
> |YEs, it is permitted, I agree.
> |
> |But why should one do it?
> 
> I came up with a handful advantages already:  
>  o Lower overhead. If each MANET interface would use a [MANET local]
>    and optionally a set of globally unique addresses, more addresses
>    are used and load on the MANET (and other) protocols is higher.

I don't understand why you think load on protocols is higher if there 
are several global addresses assigned to a router having several interfaces.

>  o No address swap needed when session swaps from one interface to the
>    other. Protocols like MIP6, HIP and SHIM6 could repair the issue in
>    some cases, in other cases they cannot. How to reach a MIP6 HA in
>    a disconnected MANET?)

If a Router has two interfaces, and two global addresses (one for each 
interface), and if host-based routes surround this router, then there's 
not a need for address swap either.  Thus I don't understand why is 
there a need to have a single address for a Router having two interfaces.

>  o If a MANET interfaces goes up and down (e.g. single neighbor flapping), 
>    the application may get affected. Using a virtual interface (typically
>    the loopback interface), application layer recovery is circumvented.

If a Router has a single real interface then no amount of virtual 
interfaces can make it more reliable.

If a Router has two real interfaces then any additional amount of 
virtual interfaces will not contribute anything to reliability.

If a Router has a single Real interface, and the implementation of the 
particular routing protocol breaks when that interface is WiFi and its 
driver puts it down when disassociating, then yes, it's better to have 
that implementation of that routing protocol to run over a virtual 
interface, and maybe the loopback interface.  But better upgrade to a 
better implementation of either the wifi driver or of the routing protocol.

> |> Your assumption is single hop communication and no MANET routing
> |> protocol. I
> |> am interested in the more complex topologies.
> |
> |The pictures I drawn are multihop.  And indeed I don't assume a MANET
> |routing protocol.  Neither does the charter.  And that's ok.
> 
> Sorry, I missed this. Do you mean that host - router is multi-hop? Who is
> forwarding?

The picture I posted initially had Host-Router-Host with two different 
subnets and Router with a routing table and forwarding process.

> Let's use figure 1-2 below. Is there connectivity between B and C, via A?

 > |>           +------------------------+   +------------------------+
 > |>           |                        |   |                        |
 > |>           |           ____STA-B    |   |           ____STA-B    |
 > |>           |       ___/      |      |   |       ___/             |
 > |>           |  STA-A          |      |   |  STA-A      OBSTACLE   |
 > |>           |      '--_       |      |   |      '--_              |
 > |>           |          '----STA-C    |   |          '----STA-C    |
 > |>           |  OBSTACLE              |   |                        |
 > |>           +------------------------+   +------------------------+
 > |>                1-1: No hindrance            1-2: B-C blocked

Yes, there is.  If STA-A is WiFi then link layer ensures repeating the 
packets.  If STA-A is WiMax then it will forward packets (router).


> |> There is no "essid" in ad hoc mode. It is the "ssid" of the IBSS. Only
> |> ESS
> |> has essid.
> |> Let's try to be accurate.
> |
> |iwconfig essid "adhoc1" mode ad-hoc
> |is also accurate.
> 
> Please use terms as standardized.
> ESSID stands for the name of an extended service set (ESS). An ESS is a set
> of basic service sets, connected over a distribution service. ESS is far
> from IBSS (more or less the opposite). I can't help the Linux iwconfig
> syntax uses essid for what should be the well defined 802.11 SSID.

What's the Cisco equivalent for iwconfig?

Alex