Re: [Autoconf] Autoconf addressing model

"Teco Boot" <> Thu, 05 March 2009 12:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D1973A6BB3 for <>; Thu, 5 Mar 2009 04:35:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.728
X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.318, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2WNQ4EnZiqbb for <>; Thu, 5 Mar 2009 04:35:42 -0800 (PST)
Received: from (hpsmtp-eml18.KPNXCHANGE.COM []) by (Postfix) with ESMTP id BC0A03A6BAC for <>; Thu, 5 Mar 2009 04:35:41 -0800 (PST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 13:36:06 +0100
Received: from M90Teco ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 13:36:06 +0100
From: "Teco Boot" <>
To: "'Alexandru Petrescu'" <>
References: <> <1235680887.4585.5.camel@localhost> <002f01c998bf$8f112210$ad336630$@nl><> <007201c99903$c4182c80$4c488580$@nl><> <007b01c99911$907facf0$b17f06d0$@nl><> <009501c99920$92154340$b63fc9c0$@nl><> <003001c99b2c$a3fcf4a0$ebf6dde0$@nl><> <000101c99c3c$3121a870$9364f950$@nl><> <><> <><> <> <> <> <> <> <> <> <49AF97FA.70200!> <002201c99d76$017d4b20$0477e160$@nl> <49AFAA15.90>
In-Reply-To: <>
Date: Thu, 5 Mar 2009 13:36:06 +0100
Message-ID: <003a01c99d8e$f47ba2f0$dd72e8d0$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmdfZtfl2cSE9SrQ+m8mQENYhi63wAAxAAQ
Content-Language: nl
X-OriginalArrivalTime: 05 Mar 2009 12:36:06.0152 (UTC) FILETIME=[F402F080:01C99D8E]
Subject: Re: [Autoconf] Autoconf addressing model
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Mar 2009 12:35:43 -0000


|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu []
|Verzonden: donderdag 5 maart 2009 11:32
|Aan: Teco Boot
|CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)';
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|Teco Boot a écrit :
|> |If all such ad-hoc interfaces of that IPv6 subnet stay within 25meter
|> |range then they're all fully exposed (no hidden terminals).
|> Not true. Maybe in a lab environment, there is no condition where it
|> In other circumstances, some iron would be enough for limited range
|> meters). Think of (closed) workplace shelters (EMC or ABC protected).
|Ok I agree there could be such a situation.  What if we came up with an
|object name which doesn't have hidden terminal problems when EMC cages
|are used, and on which an IPv6 subnet could be deployed safely.

TDMA? (or other media access technologies)

But this is of no help. The MANET link characters occur in real life. Why do
you suggest denying this?

By the way, hidden terminal problem has nothing to do with totally
unreachability, as in the EMC cage. The opposite is true, EMC cages (or
turning off the radio) solves the hidden terminal problem. Connectivity gets
hurt. Every improvement may have some disadvantages.

|> There are also stories on wlan and micro-wave ovens.
|YEs, rather exaggerated.  Maybe true some years ago but less true
|> This is mentioned over and over.
|Yes, I agree, but we should mention also the wifi deployments which
|work, are deterministic.  These also exist.

No one had any doubt about this, I think. Why mentioning an endless list on
things that work? Let's focus on what urgently needs improvements.

|> |And I also mean that larger networks could be made out of building
|> |blocks of 25m (because of powerlevel-limited because
|> |unlicensed-spectrum), by using Routers.  And still keeping the IPv6
|> |subnet to be as small at the safe area in which there are all exposed
|> |terminals, no hidden terminals.
|> No. There is a limit on spectrum and not all segments can use their
|> This introduces hidden terminal in your scenario.
|Well if each subnet is 25meter wide and they don't mix with each other
|then there are no interferences on the spectrum, because power levels
|are diminishing with distance.

Again and again and again. This may be true in a well planned network. It
fails when nodes move. So it does NOT apply to a MANET.

|> Moreover, you might be
|> familiar with planning WiFi infrastructures. Do you think this is ad
|It's as much ad-hoc as the name ad-hoc is used in the 802.11 specs and
|iwconfig implementations.

I think you absolutely don't know where you are talking about. Sorry to say

|> |I hope I'm clearer.
|> I don't think so. You came up with scenario's that are against the
|> standards and have serious problems when used in ad hoc fashion. Just
|> opinion.
|Well since you seem so confident about how wrong I am then please come
|up with descriptions of wireless systems which work, and which don't
|risk hidden-terminal problems, no electro-magnetic cages, no obstacles,
|no spectrum interference, etc.

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.

|> |> That's already solved -- 802.11 clients can roam from access point
|> |>  access point.
|> |
|> |Well yes and no, depends how it's deployed.  If the APs are bridging
|> |into a backbone then yes, terminals keep their addresses.  But if the
|> |APs route then it's not solved.  (Proxy) Mobile IP may be a solution
|> |it, but it has its inconvenients in path lengths (RO) and tunnels.
|> No problems if the APs route and the stations run a MANET protocol. I
|> aware of other solutions also, where stations stay hosts (e.g. inject
|> ND/ARP/other info in routing).
|IPv6 ND over 802.15.4 draft seems to specify that too.
|> |> But again, this should not be an 802.11-centric discussion.
|> |
|> |I agree to have it on more than 802.11.
|> |
|> |I've been told recently it's not good for link layer characteristics
|> |  control the link-layers to IP addressing.  Yes, put that way I
|> |with it - I don't want link-layers to control IP, rather vice-versa.
|> |
|> |But it's also  true that an IPv6 link-local address on Ethernet
|> |directly on the MAC addres (a link-layer ID),
|> 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.
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?
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. When fixed, let's check also the

+----------+                        +----------+
|          |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 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).
With a multi-hop path, this will not work.