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
- Re: [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Paul Lambert
- [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Charles E. Perkins
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] practical addressing Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] radio neighbors in range Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Rex Buddenberg
- Re: [Autoconf] practical addressing Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] radio neighbors in range Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Joe Macker
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] radio neighbors in range Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Teco Boot