Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 27 February 2009 20:03 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 1FD9B3A67B1 for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 12:03:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.026
X-Spam-Level:
X-Spam-Status: No, score=-1.026 tagged_above=-999 required=5 tests=[AWL=-1.177, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_44=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=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 ZRhGjdws8PmP for <autoconf@core3.amsl.com>; Fri, 27 Feb 2009 12:03:53 -0800 (PST)
Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by core3.amsl.com (Postfix) with ESMTP id 984883A6839 for <autoconf@ietf.org>; Fri, 27 Feb 2009 12:03:51 -0800 (PST)
Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by smtp3-g21.free.fr (Postfix) with ESMTP id 423A28180EA; Fri, 27 Feb 2009 21:04:09 +0100 (CET)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp3-g21.free.fr (Postfix) with ESMTP id DC941818052; Fri, 27 Feb 2009 21:04:06 +0100 (CET)
Message-ID: <49A8471E.6090506@gmail.com>
Date: Fri, 27 Feb 2009 21:03:42 +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>
In-Reply-To: <007b01c99911$907facf0$b17f06d0$@nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 090226-0, 26/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: Fri, 27 Feb 2009 20:03:54 -0000

Teco Boot a écrit :
> |Not all virtual interfaces are loopback.

Again, do you think all virtual interfaces are 'loopback'?

> 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'.  And you don't seem to intend to use the loopback
address.

The loopback interface is the only interface on which there's a loopback
address assigned.

> |> 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.

> |And yes the interface in the routing table for the entry address/128
> is |'lo' which is yes the loopback interface but no, never will that
> address |be in the src nor dst fields of any packet leaving the
> computer (other |than encapsulated maybe).
> 
> I checked this on the Linux host. I assigned another address on the
> lo interface. And the Linux host is reachable on this address, as
> long as other nodes has a path to this /128 prefix.

WEll yes, it is possible to manually assign any 128bit address routable
or non-routable, on the loopback interface, as it is possible to assign
any address on any interface be it virtual or physical.

> Sorry, you are wrong.
> 
> Detailed info:
> 
> debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo lo        Link
> encap:Local Loopback inet addr:127.0.0.1  Mask:255.0.0.0 inet6 addr:
> 2001:db8:1::3333/128 Scope:Global inet6 addr: ::1/128 Scope:Host UP
> LOOPBACK RUNNING  MTU:16436  Metric:1 RX packets:185 errors:0
> dropped:0 overruns:0 frame:0 TX packets:185 errors:0 dropped:0
> overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:13568 (13.2
> KiB)  TX bytes:13568 (13.2 KiB)
> 
> Tested from IOS router: nbs3725#ping 2001:db8:1::3333 Type escape
> sequence to abort. Sending 5, 100-byte ICMP Echos to
> 2001:DB8:1::3333, timeout is 2 seconds: !!!!! Success rate is 100
> percent (5/5), round-trip min/avg/max = 0/0/4 ms

Well yes, that's ok, I don't see anything wrong with nbs3725 pinging
debian-fs1's loopback interface's routable address.

But the loopback interface is not used for its intended loopback
meaning.  That loopback interface doesn't use the loopback address - 
it's a virtual interface on which the loopback address is assigned.

> Debug info, showing that you are wrong, the IP address in interface
> lo is reachable:

Well yes, because having a non-loopback IPv6 address on the loopback 
interface.

> No, absolutely not. I provided the evidence that the loopback is
> perfectly usable already.

Why the loopback interface and not another virtual interface?  Why
mixing loopback semantics with a routable address semantics?

> |I thought the unplanned aspect could be treated by IPv6 stateless 
> |autoconf and IPv6-over-Ethernet link-local addresses.
> 
> Yes and no. I like SLAAC, but with SLAAC, thewre is an address per 
> interface. In this model, the node is reachable via the loopback
> address via whatever interface.

I think this creates more headaches than it solves.

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 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?

> |> o Connectivity is not broken if a path swap occurs (the RFC3781 |>
> loopback BCP) o It provides some scalability, as only a single |>
> address is needed, even if multiple interfaces are used. o |>
> Applications are not confused by "host prefixes" to a link, where |>
> other nodes are reachable. I tested this with linux and IPv4 with |>
> /32. | |Before deciding on the solution (address assigned to a
> virtual |interface) I need to udnerstand how path swap occurs and
> why.
> 
> Because movement. A MANET Router may have multiple interfaces, some
> of them could be MANET, others wireless infrastructure mode and
> others MANET.

Sorry, I can't go along these lines.  Movement described just like that, 
without any boundary, no pattern, just movement...

I think I will simply summarize the topologies we discussed and leave it
there.

I also agree it's difficult to describe movement on paper (maybe easier 
on ppt) but we could at least try.

[...]
> |Sounds interesting.  But I think normal DHCP could run ok, provided
> the |Relays know the address of the Server.  In a first practical
> step would |be to manually configure the Server's address on each
> Relays.
> 
> When many DHCP Relay Agenst are nearby, who to select? If multicast
> is used, all of them will relay and this ends in a DHCP Relay storm
> (collisions, loss, retry .....)

That issue is simple.  Before the node can even have the choice to talk
to a Relay, it will have to connect to the wifi "adhoc".  The moment it
connected to it it will only have one choice: the Relay present on that
"adhoc" essid.

> |> 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.

> My requirements are over 25meter. 25km is no joke. Wifi is not usable
> here.

Well then.  I think the mechanisms are completely different.  A 25km
radio link would use an addressing mechanism completely different.

> |> Therefore, I think a DHCP client should start with building
> reliable |> communication to a DHCP server, and the MANET routing
> protocols can |> provide such. But the MANET routing protocol needs a
> prefix that |> corresponds to this MANET node. For this reason, I
> think it makes |> sense to start with generating a prefix without
> DHCP, and we could |> use a prefix "push model" here. | |Well I think
> this is indeed a very chickeneggy problem: are addresses in |place
> before routing is, or vice-versa.  But what would we do in |practice?
> Certainly we'd manually assign some addresses - let's see |these
> cases first.
> 
> No. MANETs are often used in workgroups, whit lack of knowledge of
> configuring something. The network must be plug&play / zero-config.
> 
> 
> 
> |>> Above, and in the following figures, I don't understand "--->, 
> |>> Prefix Information".  Is that RA?  Or OSPF?  Or routing protocol?
>  |>> Or DHCP Prefix Delegation? |> |> This is under discussion, and
> the reason we have an [Autoconf] WG. |> There are proposals that rely
> on a routing protocol, but the old |> charter mentioned being
> independent of a routing protocol. | |I think we should consider
> first the practical cases.
> 
> No. I think we have a clear picture of why MANETs are being used. We
> need an [Autoconf] solution. Let's take the next steps defining an 
> addressing model, write down the requirements and then look for
> solutions.

Sorry, it seems the Autoconf solution will come to live only if the
first practical addressing solution can get agreement on.

Alex