Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 05 March 2009 13:48 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 352233A6BC0 for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 05:48:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.18
X-Spam-Level:
X-Spam-Status: No, score=-2.18 tagged_above=-999 required=5 tests=[AWL=0.069, 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 kNsClCLPEYJr for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 05:48:51 -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 DD2F03A6BBB for <autoconf@ietf.org>; Thu, 5 Mar 2009 05:48:50 -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 n25DnJwB021987; Thu, 5 Mar 2009 14:49:19 +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 n25DnJEk032022; Thu, 5 Mar 2009 14:49:19 +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 n25DnI6v018202; Thu, 5 Mar 2009 14:49:18 +0100
Message-ID: <49AFD85E.5040301@gmail.com>
Date: Thu, 05 Mar 2009 14:49:18 +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> <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><49AD5184.6080300@gmail.com> <000101c99c3c$3121a870$9364f950$@nl><49AD9760.3080909@gmail.com> <49AD98D4.3@earthlink.net><49AD9EA8.6040803@gmail.com> <49ADA17B.9040600@earthlink.net><49ADAF7C.1050509@gmail.com> <49ADB9FB.6050600@earthlink.net> <49AE3A3A.5000305@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D783@xmb-rtp-208.amer.cisco.com> <49AE9827.5090309@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5D803@xmb-rtp-208.amer.cisco.com> <49AEBA6D.7030903@gmail.com> <7FB7EE0A621BA44B8B69E5F0A09DC76407B5DB1F@xmb-rtp-208.amer.cisco.com> <49AF97FA.70200! 07@gmail.com> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.9! 060905@gmail.com> <003a01c99d8e$f47ba2f0$dd72e8d0$@nl>
In-Reply-To: <003a01c99d8e$f47ba2f0$dd72e8d0$@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: Thu, 05 Mar 2009 13:48:52 -0000

Teco Boot a écrit :
[...]
> You missed the point MANET works even in the circumstances you described.
> MANET Routing provides the best available paths to users (tries to ...). Of
> course: no path available, no communication.

I agree with the last part: the risk is that even the best designed 
MANET protocol will not work when trees fall, cages shield and obstacles 
get in the way.   These are goals which can't be addressed.

[...]
> |> Not by definition and not directly. Nodes are free to use any other
> |> Interface ID.
> |
> |Well ok, but I haven't seen much a fe80::1 address on an Ethernet
> |interface.  You may, and then I'll wonder why.
> 
> Why can't I configure it? Of course I can.
> 
> debian-fs1:~# ip -6 addr                        
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
>     inet6 2001:db8:1:0:20c:29ff:fee3:bdf5/64 scope global dynamic 
>        valid_lft 2592000sec preferred_lft 604800sec
>     inet6 fe80::1/64 scope link 
>        valid_lft forever preferred_lft forever
>     inet6 fe80::20c:29ff:fee3:bdf5/64 scope link 
>        valid_lft forever preferred_lft forever
> 
> nbs3725#sh ipv int fa0/0.22
> FastEthernet0/0.22 is up, line protocol is up
>   IPv6 is enabled, link-local address is FE80::2
> 
> No problem either with configuring this on each and every interface of a
> node. As long as the LL is unique on the link.

Yes, I agree it can.  I don't understand why would one do it.

When over Ethernet there's the MAC address deriving into IID, helping 
ensuring uniqueness.

When over point-to-point links PPP with IPv6 could be used negotiating 
the link layer ID, again ensuring uniqueness.

But I agree an administrator may want to plan all the link-local 
addresses and assign them manually, for some links which don't have MAC 
addresses, are not 802.16 and are not used.

> So the following topology is valid:
> 
> +----------+                        +----------+
> |          |fe80::1/64              |          |
> |          +========================+          |
> | router 1 |              fe80::2/64| router 2 |
> |          |fe80::1/64              |          |
> |          +========================+          |
> |          |              fe80::2/64|          |
> +----------+                        +----------+
> 
> Agreed on this?

Agreed.  But why /64?  An address is /128, and the link-local address' 
prefix is /10.

> Maybe the OLSR / NHDP design team needs to verify their design on this
> topology. Due to lack of a RouterID, topology databases may lack  sufficient
> information to distinguish the two links.

I agree this should be checked for all routing protocols, to find out 
whether loops form.

> When fixed, let's check also the
> following:
> 
> 
> +----------+                        +----------+
> |          |fe80::1/64              |          |
> |          +========================+          |
> | router x |              fe80::2/64| router y |
> |          |fe80::2/64              |          |
> |          +========================+          |
> |          |              fe80::1/64|          |
> +----------+                        +----------+
> 
> 
> I tested the loopback interface advantage (router 11 & 12):
> 
> +------------+                         +------------+
> |            |fe80::11/64              |            |
> | Router-11  +=========================+ Router-12  |
> |            |              fe80::12/64|            |
> | loopback0  |fe80::11/64              | loopback0  |
> | FD::11/128 +=========================+ FD::12/128 |
> |            |              fe80::12/64|            |
> +------------+                         +------------+
> 
> I turned on OSPFv3 and set up a terminal connection from Router-11 to
>  Router-12, using the loopback interfaces. Then I shut down and
> brought up again the interfaces (ifdown/ifup, if you like), remotely,
> one at a time. I experienced no problems with my terminal session.

I agree.

> I repeated the test with the link local addresses. Here also, I
> experienced no problems. This is because there are two links with
> exactly the same address pairs (an advantage to use same LL addresses
> on all interfaces). 

Demonstrating the advantage of loopback0 vs eth0 would have implied that
you start OSPFv3 on eth0 instead of loopback0 and that it would have
crashed.

But even then, I'm sure there may exist OSPFv3 implementation which
would not crash when running over eth0 and ifconfig down eth0.

In this sense, if the loopback0 interface is a solution to crashing
OSPFv3-over-eth0, then it is an implementation solution. Some
implementations do, others don't.

 > With a multi-hop path, this will not work.

In my sense, you already pictured a multi-hop network in the first 
topology, so it should work.

 > +----------+                        +----------+
 > |          |fe80::1/64              |          |
 > |          +========================+          |
 > | router 1 |              fe80::2/64| router 2 |
 > |          |fe80::1/64              |          |
 > |          +========================+          |
 > |          |              fe80::2/64|          |
 > +----------+                        +----------+

Alex