Re: [Autoconf] Autoconf addressing model
"Teco Boot" <teco@inf-net.nl> Thu, 05 March 2009 12:35 UTC
Return-Path: <teco@inf-net.nl>
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 2D1973A6BB3 for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 04:35:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.728
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WNQ4EnZiqbb for <autoconf@core3.amsl.com>; Thu, 5 Mar 2009 04:35:42 -0800 (PST)
Received: from hpsmtp-eml18.kpnxchange.com (hpsmtp-eml18.KPNXCHANGE.COM [213.75.38.118]) by core3.amsl.com (Postfix) with ESMTP id BC0A03A6BAC for <autoconf@ietf.org>; Thu, 5 Mar 2009 04:35:41 -0800 (PST)
Received: from cpsmtp-eml101.kpnxchange.com ([213.75.84.101]) by hpsmtp-eml18.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 13:36:06 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml101.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Mar 2009 13:36:06 +0100
From: Teco Boot <teco@inf-net.nl>
To: 'Alexandru Petrescu' <alexandru.petrescu@gmail.com>
References: <499F0BA7.90501@piuha.net> <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><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.90 60905@gmail.com>
In-Reply-To: <49AFAA15.9060905@gmail.com>
Date: Thu, 05 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]
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 12:35:43 -0000
Inline. |-----Oorspronkelijk bericht----- |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] |Verzonden: donderdag 5 maart 2009 11:32 |Aan: Teco Boot |CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; autoconf@ietf.org |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 |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. Wires? 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 |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. 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 |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. 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 |hoc? | |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 so. |> |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. 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 |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. 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 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 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. Teco. |Alex
- Re: [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Paul Lambert
- [Autoconf] new charter Jari Arkko
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Charles E. Perkins
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter HyungJin Lim
- [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter HyungJin Lim
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] practical addressing (was: new cha… Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] practical addressing Alexandru Petrescu
- Re: [Autoconf] new charter Alexandru Petrescu
- [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] radio neighbors in range Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Rex Buddenberg
- Re: [Autoconf] practical addressing Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] radio neighbors in range Teco Boot
- Re: [Autoconf] new charter Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] radio neighbors in range Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Carlos Jesús Bernardos Cano
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] Autoconf addressing model HyungJin Lim
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] new charter Alexandru Petrescu
- Re: [Autoconf] new charter Joe Macker
- Re: [Autoconf] new charter Dearlove, Christopher (UK)
- Re: [Autoconf] radio neighbors in range Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Charles E. Perkins
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Stan Ratliff (sratliff)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- Re: [Autoconf] Autoconf addressing model Joe Macker
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Dearlove, Christopher (UK)
- Re: [Autoconf] Autoconf addressing model Teco Boot
- Re: [Autoconf] Autoconf addressing model Alexandru Petrescu
- [Autoconf] new charter Ryuji Wakikawa
- Re: [Autoconf] new charter Teco Boot