Re: [Autoconf] Autoconf addressing model
Alexandru Petrescu <alexandru.petrescu@gmail.com> Sat, 28 February 2009 14:07 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 4E7E33A6A6A for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 06:07:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.173
X-Spam-Level:
X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, 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 qkfXsCU-qvG9 for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 06:07:07 -0800 (PST)
Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by core3.amsl.com (Postfix) with ESMTP id C94F93A6A4D for <autoconf@ietf.org>; Sat, 28 Feb 2009 06:07:05 -0800 (PST)
Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by smtp4-g21.free.fr (Postfix) with ESMTP id D01654C8148; Sat, 28 Feb 2009 15:07:24 +0100 (CET)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp4-g21.free.fr (Postfix) with ESMTP id 84C6B4C8125; Sat, 28 Feb 2009 15:07:21 +0100 (CET)
Message-ID: <49A944FF.9000102@gmail.com>
Date: Sat, 28 Feb 2009 15:06:55 +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>
In-Reply-To: <009501c99920$92154340$b63fc9c0$@nl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 090227-0, 27/02/2009), Outbound message
X-Antivirus-Status: Clean
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: Sat, 28 Feb 2009 14:07:08 -0000
Teco Boot a écrit : > > |-----Oorspronkelijk bericht----- > |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > |Verzonden: vrijdag 27 februari 2009 21:04 > |Aan: Teco Boot > |CC: autoconf@ietf.org > |Onderwerp: [SPAM] Re: Autoconf addressing model > |Urgentie: Laag > | > |Teco Boot a écrit : > |> |Not all virtual interfaces are loopback. > | > |Again, do you think all virtual interfaces are 'loopback'? > > Not at all. > > And "loopback" on its own is meaningless. No, I think loopback address and loopback interface are meaningful. > |> Router folks use "loopback" for what is meant here. Virtual > |> interfaces have a much, much broader meaning. A tunnel interface or > |> VLAN / FR / ATM subinterface is a virtual interface but definitely > |> not what I intent to use. I prefer keep using the term loopback here. > | > |I strongly disagree using the term loopback interface, at least because > |it can be easily interpreted as the interface on which there's a > |'loopback address'. > > > 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. > I agree on that there can be confusion on loopback address (node local) and > loopback interface. I agree. > |The loopback interface is the only interface on which there's a loopback > |address assigned. > > This is NOT a node requirement. > > RFC4291: > 2.5.3. The Loopback Address > > The unicast address 0:0:0:0:0:0:0:1 is called the loopback address. > It may be used by a node to send an IPv6 packet to itself. It must > not be assigned to any physical interface. It is treated as having > Link-Local scope, and may be thought of as the Link-Local unicast > address of a virtual interface (typically called the "loopback > interface") to an imaginary link that goes nowhere. > > Note the wording "may be". Note the status of that rfc compared to the two rfcs you cited previously calling the loopback interface a virtual interface. > The other way around is definitely false: > RFC3484 (default address selection): > Implementations that wish to support the use > of global source addresses assigned to a loopback interface should > behave as if the loopback interface originates and forwards the > packet. > > Assigning non-"loopback addresses" on the loopback interfaces is permitted. YEs, it is permitted, I agree. But why should one do it? > |> |> RFC3871: It is a common practice among operators to configure |> > |> "loopback" pseudo-interfaces to use as the source and destination of > |> |> management traffic. | |Well that RFC is completely wrong please > |> someone correct it. The |loopback address is ::1 and it can't be > |> used to communicate outside the |computer. Yes pseudo-interface (and > |> maybe 'virtual') but no loopback. > |> > |> I think you mix up "host loopback" and "router loopback". These are > |> very, very different! > | > |I think there's no difference between host and router loopback. > > Yes. > On a host (strong end system model, RFC1122), traffic sent out the host MUST > have the source address of the outgoing interface. On a router, this is not > the case. Therefore assignment of addresses on loopback interfaces on > routers is different than on (strong ES) hosts. YEs, I agree permitted, and implemented. But why should a MANET do that - it could do it with virtual interfaces, not loopback. > |In a first step, do we agree that the node has typically more than one > |interface? We didn't seem to. If not, then why should we need to have > |the node reachable via whatever interface, since there's only one. > > If there is only one (external) interface, there is no redundancy and the > advantages do not apply. Let's decide whether we deal with nodes having two-or-more physical interfaces or with single-physical-interface nodes. > |If there are at least two interfaces, then why can't we use a different > |address on each of the interfaces? What's wrong with that? The fact > |that the node moves? Well, you seemed to accept host-based /128 routes > |- in this case instead of 1 there'll be 2 host-based /128 routes. > |What's wrong with that again? > > At least 2 advantages: > o 1 address: lower overhead ?? overhead of what? > o no address swap needed when session swaps from one interface to the other > (and if interfaces go down!). Swapping sessions from one physical interface to another can happen by using virtual interfaces. IT can happen too without any virtual interface. Some Mobile IPv6 implementation does it. > 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. > 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. > |> |> However, there is a chicken - egg problem. In a wired network, the > |> |> DHCP client - DHCP relay agent relation is stable. This is > |> certainly |> not the case in a MANET. | |Well it is the case in a > |> MANET made of 25meter IPv6 subnets. > |> > |> Voice over IP over WLAN for 25meter? Just shout!! > | > |:-) :-) I agree. > | > |But the IP in VoIP over a 25m IPv6 subnet allows me to talk to another > |IP much further who wouldn't hear my shout otherwise. > > Yes. a MANET topology could be a short-range / high data rate radio link to > another MANET Router, with low data rate / long range to a remote peer, and > another hop via short-range / high data radio link. In a mobile ad hoc > environment, nodes are free to move and the network should provide the best > connectivity to the users that is technical feasible. > > Not only the nodes may move, obstacles may also move (teapot, truck). Ah! Thank you for the pictures below. Later I will collect all the pictures posted recently. I will list them in a email for future record. [...] > What about this scenario: here, the obstacle is moving: > > (802.11 term: STA is station) > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ | | | ___/ | > | STA-A | | | STA-A OBSTACLE | > | '--_ | | | '--_ | > | '----STA-C | | '----STA-C | > | OBSTACLE | | | > +------------------------+ +------------------------+ > 1-1: No hindrance 1-2: B-C blocked > > +------------------------+ +------------------------+ > | | | O | > | ____STA-B | | B STA-B | > | ___/ | | | S | | > | STA-A OB | | | STA-A T | | > | ST | | | A | | > | AC STA-C | | C STA-C | > | LE | | LE | > +------------------------+ +------------------------+ > 1-3: A-C blocked 1-4: A-B & A-C blocked > > MANET Scenarios with blocking obstacle This is absolutely wonderful. I set it aside. > Compare with this one: > > (802.11 term: AP is access point) > > +------------------------+ +------------------------+ > | | | | > | ____STA-B | | ____STA-B | > | ___/ | | ___/ | > | AP-A | | AP-A OBSTACLE | > | '--_ | | '--_ | > | '----STA-C | | '----STA-C | > | OBSTACLE | | | > +------------------------+ +------------------------+ > 4-1: No hindrance 4-2: No hindrance > > +------------------------+ +------------------------+ > | | | O | > | ____STA-B | | B STA-B | > | ___/ | | S | > | AP-A OB | | AP-A T | > | ST | | A | > | AC STA-C | | C STA-C | > | LE | | LE | > +------------------------+ +------------------------+ > 4-3: A-C & B-C blocked 4-4: All blocked > > 802.11 BSS L2 topology with blocking obstacle > > > In these scenario's, the MANET model provides better connectivity. I won't > say more bandwidth, lower loss or other link quality metrics, but for high > availability the MANET model definitely wins. I set this aside too. HAving them pictured, may I ask you: do you think anything will ever be able to communicate through Obstacles? 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