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