Re: [Autoconf] Autoconf addressing model

Alexandru Petrescu <> Thu, 05 March 2009 10:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D533A28C3DD for <>; Thu, 5 Mar 2009 02:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.174
X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2MxlZCamE0AH for <>; Thu, 5 Mar 2009 02:31:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B5BFD28C36B for <>; Thu, 5 Mar 2009 02:31:23 -0800 (PST)
Received: from ( []) by (8.14.2/8.14.2/CEAnet-Internet-out-1.2) with ESMTP id n25AU3mg002103; Thu, 5 Mar 2009 11:30:03 +0100
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id n25AVndA012825; Thu, 5 Mar 2009 11:31:49 +0100 (envelope-from
Received: from [] ([]) by (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id n25AVnpN029164; Thu, 5 Mar 2009 11:31:49 +0100
Message-ID: <>
Date: Thu, 05 Mar 2009 11:31:49 +0100
From: Alexandru Petrescu <>
User-Agent: Thunderbird (Windows/20081209)
MIME-Version: 1.0
To: Teco Boot <>
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>
In-Reply-To: <002201c99d76$017d4b20$0477e160$@nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 10:31:24 -0000

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 fails.
> In other circumstances, some iron would be enough for limited range (few
> 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.

> There are also stories on wlan and micro-wave ovens.

YEs, rather exaggerated.  Maybe true some years ago but less true nowadays.

> This is mentioned over and over.

Yes, I agree, but we should mention also the wifi deployments which 
work, are deterministic.  These also exist.

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

> Moreover, you might be
> familiar with planning WiFi infrastructures. Do you think this is ad hoc?

It's as much ad-hoc as the name ad-hoc is used in the 802.11 specs and 
iwconfig implementations.

> |I hope I'm clearer.
> I don't think so. You came up with scenario's that are against the 802.11
> standards and have serious problems when used in ad hoc fashion. Just my
> 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.

> |> That's already solved -- 802.11 clients can roam from access point to
> |>  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 for
> |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 am
> 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 to
> |  control the link-layers to IP addressing.  Yes, put that way I agree
> |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 depends
> |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.