From Fred.L.Templin@boeing.com Mon Nov 2 12:55:06 2009 Return-Path: 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 CC50A3A6A8D for ; Mon, 2 Nov 2009 12:55:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 YO0ldzQ0a9yw for ; Mon, 2 Nov 2009 12:55:06 -0800 (PST) Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id E4C533A6A3C for ; Mon, 2 Nov 2009 12:55:05 -0800 (PST) Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id nA2KtL1u022566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Nov 2009 12:55:23 -0800 (PST) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id nA2KtLoH017946; Mon, 2 Nov 2009 14:55:21 -0600 (CST) Received: from XCH-NWHT-04.nw.nos.boeing.com (xch-nwht-04.nw.nos.boeing.com [130.247.64.250]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id nA2KtKGd017923 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Mon, 2 Nov 2009 14:55:21 -0600 (CST) Received: from XCH-NW-15V.nw.nos.boeing.com ([130.247.25.102]) by XCH-NWHT-04.nw.nos.boeing.com ([130.247.64.250]) with mapi; Mon, 2 Nov 2009 12:55:20 -0800 From: "Templin, Fred L" To: Teco Boot Date: Mon, 2 Nov 2009 12:55:19 -0800 Thread-Topic: [Autoconf] Regarding Baccelli/Townsley Internet-Draft Thread-Index: AcpZUscGKthy6+KURNG4bL3INNc3pgAKUdWgACDFp3AAf9E6oA== Message-ID: <12F4112206976147A34FEC0277597CCF27A49CCF41@XCH-NW-15V.nw.nos.boeing.com> References: <4A EA586C.9080104@earthlink.net> <12F4112206976147A34FEC0277597CCF27A49CCB78@XCH-NW-15V.nw.nos.boeing.com> <006401ca5a00$e6b5e2a0$b421a7e0$@nl> In-Reply-To: <006401ca5a00$e6b5e2a0$b421a7e0$@nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Regarding Baccelli/Townsley Internet-Draft X-BeenThere: autoconf@ietf.org 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: Mon, 02 Nov 2009 20:55:06 -0000 Teco, > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: Saturday, October 31, 2009 1:05 AM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Regarding Baccelli/Townsley Internet-Draft >=20 > >Templin, Fred L wrote: >=20 > >Second, I want there to be flexibility to allow for > >"tethered" hosts that are always single-hop neighbors > >on a router's interface that otherwise has undetermined > >connectivity properties. That may mean that the router's > >interface may need to configure a prefix other than /32 or > >/128. >=20 > Yes, I deploy this stuff. >=20 > But proponents on the baccelli draft would say this is > supported, as there is some determined connectivity. > I'm not sure this is valid argumentation, because I > think the proponents know little of my MANETs. Are you saying that we need a use case analysis of the abundance of possible MANET scenarios? Fred fred.l.templin@boeing.com =20 > But also for this case (same as LLs), I think it makes sense > we Autoconf work on for a maximum-length, global / ULA prefix. > But the practical addressing model for MANETs shall dot say > these are preferred. These are needed if nothing else is > available and can be a stepping stone to acquire other prefixes. >=20 >=20 > Regards, Teco From teco@inf-net.nl Mon Nov 2 13:48:47 2009 Return-Path: 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 07C6428C116 for ; Mon, 2 Nov 2009 13:48:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] 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 w2eY4fNGXa0P for ; Mon, 2 Nov 2009 13:48:46 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 7CBDE3A68ED for ; Mon, 2 Nov 2009 13:48:45 -0800 (PST) Received: (qmail 972 invoked from network); 2 Nov 2009 22:49:00 +0100 Received: from unknown (HELO M90Teco) (62.140.137.108) by server9.hosting2go.nl with SMTP; 2 Nov 2009 22:49:00 +0100 From: "Teco Boot" To: "'Templin, Fred L'" References: <4A EA586C.9080104@earthlink.net> <12F4112206976147A34FEC0277597CCF27A49CCB78@XCH-NW-15V.nw.nos.boeing.com> <006401ca5a00$e6b5e2a0$b421a7e0$@nl> <12F4112206976147A34FEC0277597CCF27A49CCF41@XCH-NW-15V.nw.nos.boeing.com> In-Reply-To: <12F4112206976147A34FEC0277597CCF27A49CCF41@XCH-NW-15V.nw.nos.boeing.com> Date: Mon, 2 Nov 2009 22:48:23 +0100 Message-ID: <00bf01ca5c06$484808c0$d8d81a40$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpZUscGKthy6+KURNG4bL3INNc3pgAKUdWgACDFp3AAf9E6oAABH21w Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Regarding Baccelli/Townsley Internet-Draft X-BeenThere: autoconf@ietf.org 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: Mon, 02 Nov 2009 21:48:47 -0000 Hi Fred, >> >Templin, Fred L wrote: >> >> >Second, I want there to be flexibility to allow for >> >"tethered" hosts that are always single-hop neighbors >> >on a router's interface that otherwise has undetermined >> >connectivity properties. That may mean that the router's >> >interface may need to configure a prefix other than /32 or >> >/128. >> >> Yes, I deploy this stuff. >> >> But proponents on the baccelli draft would say this is >> supported, as there is some determined connectivity. >> I'm not sure this is valid argumentation, because I >> think the proponents know little of my MANETs. > >Are you saying that we need a use case analysis of >the abundance of possible MANET scenarios? I'm not sure. I can't publish all my scenario's here. But for sure the baccelli draft does not support all of them. That is why I asked questions on "all" "general case" etc. I have a few real world use cases by hand that could be made public. Maybe I'll write those down some day. It would show the need for multi-homing. An interesting one: Regional fire brigades: small MANETs connected to Internet with ADSL, 3G and two satcom systems. It is deployed in a couple of months. Any idea on addressing model, without NAPT / NAT66 or tunnels? IPv6 is not realistic here and today anyway. But it would fit a nice goal: an attached MANET without NAT or tunnels. And with a little effort on replacing default gateways, it would support multi-homing. Regards, Teco From Thomas@ThomasClausen.org Fri Nov 6 02:09:07 2009 Return-Path: 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 3717A3A692A for ; Fri, 6 Nov 2009 02:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 zcAPChorPV0t for ; Fri, 6 Nov 2009 02:09:06 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 838183A68D0 for ; Fri, 6 Nov 2009 02:09:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3EA33430907 for ; Fri, 6 Nov 2009 02:09:30 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-8-79.w83-112.abo.wanadoo.fr [83.112.70.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id B307D4308FE for ; Fri, 6 Nov 2009 02:09:29 -0800 (PST) Message-Id: <048B55A7-F211-493D-B7F2-460256925690@ThomasClausen.org> From: Thomas Heide Clausen To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 6 Nov 2009 11:09:27 +0100 X-Mailer: Apple Mail (2.936) Subject: [Autoconf] Hiroshima WG meeting preparation: Scribe-solicitation X-BeenThere: autoconf@ietf.org 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: Fri, 06 Nov 2009 10:09:07 -0000 All, Following the excellent example of [mext], I thought it might be a good idea to do some of the administrative tasks done in advance. The [autoconf] session is scheduled: o Monday, nov. 9, 2009 at 1740-1940 Arcacia West We're looking for volunteers to help with the following tasks: o Minute taking (two volunteers) o Jabber Scribe (one volunteer) o Jabber "Speaker" (one volunteer) (for taking questions/comments on Jabber and relaying over the mike). Considering that we expect quite a few to be following the meeting remotely this time, these three tasks are of paramount importance to the WG, and volunteer assistance will be greatly appreciated by everybody. We have in the past had both excellent minute takers and Jabber scribes, and we hope that there will be also excellent volunteers for these tasks at this meeting. Please do let the chairs know asap that (not if!) you are willing to help out with these important tasks, Thanks. Thomas From thomas@thomasclausen.org Fri Nov 6 04:05:18 2009 Return-Path: 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 517B03A68B1 for ; Fri, 6 Nov 2009 04:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 KvFTjMFOqeRA for ; Fri, 6 Nov 2009 04:05:17 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 666F83A6877 for ; Fri, 6 Nov 2009 04:05:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1AA43430085 for ; Fri, 6 Nov 2009 04:05:41 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (ASte-Genev-Bois-153-1-8-79.w83-112.abo.wanadoo.fr [83.112.70.79]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 91B70430084 for ; Fri, 6 Nov 2009 04:05:40 -0800 (PST) Message-Id: <4B245284-98A4-4BF9-B11F-C058F8A28029@thomasclausen.org> From: Thomas Heide Clausen To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 6 Nov 2009 13:05:37 +0100 X-Mailer: Apple Mail (2.936) Subject: [Autoconf] All Presenters: Request for Hiroshima Slides X-BeenThere: autoconf@ietf.org 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: Fri, 06 Nov 2009 12:05:18 -0000 Dear all, The agenda for the [autoconf] meeting in Hiroshima is on-line: http://www.ietf.org/proceedings/09nov/agenda/autoconf.txt If you have a presentation on the agenda, please think of sending your slides (if possible in PDF, such that they're readable by all) to the chairs well in advance such that we can stick them on-line also in advance of the meeting. Note that we're meeting Monday afternoon! As we expect a fair number of remote attendees, it would be good to have the slides on-line sooner rather than later. Also, it allows us all to prepare well for a productive meeting. Thanks, Thomas From Chris.Dearlove@baesystems.com Fri Nov 6 08:06:18 2009 Return-Path: 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 6133D28C0DE for ; Fri, 6 Nov 2009 08:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] 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 x4lNTShyHrKD for ; Fri, 6 Nov 2009 08:06:17 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 62A0D3A6359 for ; Fri, 6 Nov 2009 08:06:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,694,1249254000"; d="scan'208";a="31607403" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 06 Nov 2009 16:06:39 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nA6G6kQs004880; Fri, 6 Nov 2009 16:06:46 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Nov 2009 16:06:38 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 6 Nov 2009 16:06:38 -0000 Message-ID: In-Reply-To: <048B55A7-F211-493D-B7F2-460256925690@ThomasClausen.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Hiroshima WG meeting preparation: Scribe-solicitation thread-index: AcpeyUAa503j+r4MScaB/oYZMPiGpgAMUlEQ References: <048B55A7-F211-493D-B7F2-460256925690@ThomasClausen.org> From: "Dearlove, Christopher (UK)" To: "Thomas Heide Clausen" , X-OriginalArrivalTime: 06 Nov 2009 16:06:38.0889 (UTC) FILETIME=[1F542190:01CA5EFB] Subject: Re: [Autoconf] Hiroshima WG meeting preparation: Scribe-solicitation X-BeenThere: autoconf@ietf.org 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: Fri, 06 Nov 2009 16:06:18 -0000 > We have in the past had both excellent minute takers and Jabber > scribes, and we hope that there will be also excellent volunteers for > these tasks at this meeting. Whether or not the former applies to me, I have taken some minutes in Autoconf at some past meetings. But I won't be in Hiroshima I'm afraid, and the time difference makes remote attendance not good from Europe (though not as bad as for the MANET meeting). Hope to see some of you in Anaheim. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Fri Nov 6 09:23:20 2009 Return-Path: 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 00C3128C177 for ; Fri, 6 Nov 2009 09:23:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 VZk90c22bcPB for ; Fri, 6 Nov 2009 09:23:19 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 6940428C162 for ; Fri, 6 Nov 2009 09:23:17 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nA6HNcYJ032106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Nov 2009 18:23:38 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nA6HNcAk024458; Fri, 6 Nov 2009 18:23:38 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nA6HNbg7009094; Fri, 6 Nov 2009 18:23:37 +0100 Message-ID: <4AF45B99.8040206@gmail.com> Date: Fri, 06 Nov 2009 18:23:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <048B55A7-F211-493D-B7F2-460256925690@ThomasClausen.org> In-Reply-To: <048B55A7-F211-493D-B7F2-460256925690@ThomasClausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Hiroshima WG meeting preparation: Scribe-solicitation X-BeenThere: autoconf@ietf.org 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: Fri, 06 Nov 2009 17:23:20 -0000 Thomas Heide Clausen a écrit : [...] > The [autoconf] session is scheduled: > > o Monday, nov. 9, 2009 at 1740-1940 Arcacia West [Hiroshima] [...] > We have in the past had both excellent minute takers and Jabber > scribes, and we hope that there will be also excellent volunteers for > these tasks at this meeting. It's going to be 9h40-11h40am Monday November 9th in France - sorry, I don't think I can jabber scribe at that time, office hours being much demanding Monday morning. Alex > > Please do let the chairs know asap that (not if!) you are willing to > help out with these important tasks, > > Thanks. > > Thomas _______________________________________________ Autoconf > mailing list Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From ulrich@herberg.name Sat Nov 7 00:01:34 2009 Return-Path: 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 8E24B28C0FC for ; Sat, 7 Nov 2009 00:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.614 X-Spam-Level: X-Spam-Status: No, score=-1.614 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 IddIyoWc7R9M for ; Sat, 7 Nov 2009 00:01:33 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id A14ED28C0E9 for ; Sat, 7 Nov 2009 00:01:33 -0800 (PST) Received: by mail-bw0-f223.google.com with SMTP id 23so1910738bwz.29 for ; Sat, 07 Nov 2009 00:01:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.32.209 with SMTP id e17mr5718527bkd.84.1257580917374; Sat, 07 Nov 2009 00:01:57 -0800 (PST) In-Reply-To: <4AF45B99.8040206@gmail.com> References: <048B55A7-F211-493D-B7F2-460256925690@ThomasClausen.org> <4AF45B99.8040206@gmail.com> Date: Sat, 7 Nov 2009 17:01:57 +0900 Message-ID: <25c114b90911070001t4d2234bds1bae8d1d7de79645@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org, Thomas Heide Clausen Subject: Re: [Autoconf] Hiroshima WG meeting preparation: Scribe-solicitation X-BeenThere: autoconf@ietf.org 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: Sat, 07 Nov 2009 08:01:34 -0000 I could do the scribe or jabber speaker. Ulrich On Sat, Nov 7, 2009 at 2:23 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : > [...] >> >> The [autoconf] session is scheduled: >> >> o =A0 =A0Monday, nov. 9, 2009 at 1740-1940 Arcacia West [Hiroshima] > > [...] >> >> We have in the past had both excellent minute takers and Jabber >> scribes, and we hope that there will be also excellent volunteers for >> these tasks at this meeting. > > It's going to be 9h40-11h40am Monday November 9th in France - sorry, I > don't think I can jabber scribe at that time, office hours being much > demanding Monday morning. > > Alex > >> >> Please do let the chairs know asap that (not if!) you are willing to >> =A0help out with these important tasks, >> >> Thanks. >> >> Thomas _______________________________________________ Autoconf >> mailing list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From ietf@thomasclausen.org Sun Nov 8 01:19:03 2009 Return-Path: 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 CF7723A695A for ; Sun, 8 Nov 2009 01:19:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1] 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 lA8Z43zku8eg for ; Sun, 8 Nov 2009 01:19:02 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 60C2C3A6783 for ; Sun, 8 Nov 2009 01:19:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id D66B8430697 for ; Sun, 8 Nov 2009 01:19:27 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (host-113-143.meeting.ietf.org [133.93.113.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id C92EA43067C for ; Sun, 8 Nov 2009 01:19:26 -0800 (PST) Message-Id: <26EE915F-A1A5-4682-BF2F-31828F5A84B1@thomasclausen.org> From: Thomas Heide Clausen To: autoconf@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-9-191894252 Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 8 Nov 2009 10:19:28 +0100 X-Mailer: Apple Mail (2.936) Subject: [Autoconf] Consensus Call Summary & Plan Forward X-BeenThere: autoconf@ietf.org 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: Sun, 08 Nov 2009 09:19:03 -0000 --Apple-Mail-9-191894252 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit All, On October 22 we asked the WG, via autoconf@ietf.org, on advice on how to best make progress. Specifically, the question was: > That said, we (and, this we is also the chairs) will take this > opportunity to ask the WGs opinion on how to progress. If you have > any opinion, please let it be known to the WG (via this mailing > list) before 29/10/09 (i.e. Thursday next week) at noon CET. Please > be specific and constructive, i.e., pick one of: > > o if you think that the WG should proceed with draft-ietf-autoconf- > adhoc-addr-model > as a baseline, say so! > > o if you think there're cardinal (but fixable) issues missing or > wrong with > draft-ietf-autoconf-adhoc-addr-model, then let the WG know what > these > issues are, and propose a solution before the deadline. The Editors > will certainly do their best to address the issues. > > o if you think that draft-ietf-autoconf-adhoc-addr-model is beyond > hope, > let the WG know explicitly how you suggest that we progress at > this point -- > considering the current timeline!! About 20 or so responded to this question, with roughly 70% of the respondents supporting proceeding with draft-ietf-autoconf-adhoc-addr- model as baseline for future progress. We therefore observe that: o There's CONSENSUS for continuing with draft-ietf-autoconf-adhoc- addr-model as a BASELINE for future progress. The key word in the above is "BASELINE". During the discussions on the list in the past 3 weeks or so, a couple of issues were raised that need to be duly addressed, by inclusion in the document or by discussion and consensus to not include. We're trying to summarize those issues below: o Link Local Addresses - As a reminder, after Stockholm, consensus was established to NOT have [autoconf] configure Link Local Addresses, and to encourage that other addresses, which [autoconf] should develop methods for obtaining and ensure properties of, be used. In draft-ietf-autoconf-adhoc-addr-model, this is reflected by stating that in MANETs, Link Local Addresses are "discouraged". This phrasing has on the list been suggested inappropriate, we should consider alternatives. Below, an extract of that which was the essence of that discussion in Stockholm. The objective was to state that as [autoconf] does not do anything to generate and preserve properties of Link Local addresses, for the network parts where [autoconf] is applicable, it is recommended to in these parts of the network use addresses which [autoconf] *does* generate and ensure properties of. In other words: "no guarantees are made by [autoconf] for LL addresses, so using those may break stuff. Use at your own risk. We RECOMMEND using other addresses with properties ensured by [autoconf]" - Issues which were brought up include (i) if LL addresses generated from MAC addresses are "unique enough", (ii) compatibility with other protocols which stipulate the use of LL address. and (iii) the definition of DAD as given in RFC4862 o Interface Definition / Description - As a reminder, prior to our past rechartering, we went through a large effort in trying to describe "MANET Interfaces", and fell short of the goal of doing so satisfactory. The rechartering was, in part, done with a recognition of this fact, and re-scoped [autoconf] to consider *a* addressing model for which there's an existence proof that it works. In draft-ietf-autoconf-adhoc-addr-model, this is reflected by stating "undefined connectivity properties". This phrasing has on the list been suggested insufficient. We should therefore consider alternatives/expansion of the phrasing hereof - but, we insist, avoid going back down the rathole of trying to produce an "interface model" or "link model". We're not chartered to do that, and past efforts have shown that to be a difficult task to do (especially on a short timescale) The authors of the (now expired) I-D, draft-baccelli-multi-hop-wireless-communication have kindly accepted to launch these discussions by a presentation in Hiroshima. o Prefix lengths on the interfaces that [autoconf] is concerned with - As a reminder, there has (long ago, even before the rechartering) been consensus on the use of /32 and /128 prefix lengths for *these* interfaces. There are ways of using shorter prefixes, but again, the re- chartering had as premiss to scope [autoconf] to consider *a* addressing model for which there is an existence proof that it works. In draft-ietf-autoconf-adhoc-addr-model, this is reflected in section 4 (the justification) and in section 6 (the recommendation - a "should" for /32 and /128). We should therefore consider if there's a need for further explanation (section 4) for this recommendation, as well as verify and handle any potential conflicts with RFC4291 (if any). We plan to discuss these in Hiroshima, and to issue consensus calls shortly after the [autoconf] session in Hiroshima has concluded and minutes have been posted. The objective is closing these issues quickly. We will want to establish consensus on these issues such that draft-ietf-autoconf-adhoc-addr-model can be considered "done", come early December. The meeting agenda is online at http://www.ietf.org/proceedings/09nov/agenda/autoconf.txt See y'all in the land of Sake and Sushi, Ryuji & Thomas --Apple-Mail-9-191894252 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable All,

On October 22 we = asked the WG, via autoconf@ietf.org, on advice on = how to best make progress. Specifically, the question = was:

That said, we (and, this we is = also the chairs) will take this opportunity to ask the WGs opinion on = how to progress. If you have any opinion, please let it be known to the = WG (via this mailing list) before 29/10/09 (i.e. Thursday next week) at = noon CET. Please be specific and constructive, i.e., pick one = of:

if you think that the WG should proceed with = draft-ietf-autoconf-adhoc-addr-model

o if you = think there're cardinal (but fixable) issues missing or wrong = with
= draft-ietf-autoconf-adhoc-addr-model, then let the WG know what = these
issues = are, and propose a solution before the deadline. The = Editors
will = certainly do their best to address the = issues.

o if you = think that draft-ietf-autoconf-adhoc-addr-model is beyond = hope,
let the = WG know explicitly how you suggest that we progress  at this point = --
=   o There's = CONSENSUS for continuing with draft-ietf-autoconf-adhoc-addr-model as = a
= = BASELINE for future progress.

The key word in the above is = "BASELINE". During the discussions on the list in the past 3 weeks or = so, a couple of issues were raised that need to be duly addressed, by = inclusion in the document or by discussion and consensus to not include. = We're trying to summarize those issues below:

o Link = Local Addresses

- As a reminder, after Stockholm, = consensus was established to NOT have
[autoconf] configure Link Local = Addresses, and to encourage that other
addresses, which [autoconf] = should develop methods for obtaining and
ensure properties of, be = used.

in MANETs, Link Local Addresses = are "discouraged". This phrasing has
on the list been suggested = inappropriate, we should consider alternatives.

Below, an = extract of that which was the essence of that discussion in
= Stockholm.

The objective was to state that = as [autoconf] does not do anything to generate
and = preserve properties of  Link Local addresses, for the network parts = where
= = = = [autoconf] is applicable, it is recommended to in these parts of = the network use
In other words:  "no = guarantees are made by [autoconf] for LL addresses, so 
using = those may break stuff. Use at your own risk. We RECOMMEND using = other
= = = = addresses with properties ensured by [autoconf]"

- Issues = which were brought up include (i) if LL addresses generated from = MAC
= = = = addresses are "unique enough", (ii) compatibility with other = protocols which
o Interface Definition / = Description

As a reminder, prior to our past rechartering, we went = through a large
model for which there's an = existence proof that it works.

In = draft-ietf-autoconf-adhoc-addr-model, this is reflected by = stating
= = = = "undefined connectivity properties". This phrasing has on the = list been
We should = therefore consider alternatives/expansion of the phrasing = hereof
= = = = - but, we insist, avoid going back down the rathole of trying to = produce an
timescale)

The = authors of the (now expired) I-D,

= draft-baccelli-multi-hop-wireless-communication

have = kindly accepted to launch these discussions by a presentation in = Hiroshima.
o Prefix lengths on the interfaces = that [autoconf] is concerned with

- As a reminder, there has (long = ago, even before the rechartering) been
consensus on the use of /32 and = /128 prefix lengths for *these* interfaces.
There are = ways of using shorter prefixes, but again, the re-chartering = had
= = = = as premiss to scope [autoconf] to consider *a* addressing model = for which
In = draft-ietf-autoconf-adhoc-addr-model, this is reflected in section 4 = (the
= = = = justification) and in section 6 (the recommendation - a "should" = for /32 and
We should therefore consider if = there's a need for further explanation (section 4)
for this = recommendation, as well as verify and handle any potential conflicts = with
= = = = RFC4291 (if any).

We plan to discuss these in Hiroshima, = and to issue consensus calls shortly after the [autoconf] session in = Hiroshima has concluded and minutes have been posted. The objective is = closing these issues quickly. We will want to establish consensus on = these issues such that draft-ietf-autoconf-adhoc-addr-model can be = considered "done", come early December.

The meeting agenda is = online at http://= www.ietf.org/proceedings/09nov/agenda/autoconf.txt

See y'all = in the land of Sake and Sushi,

Ryuji & = Thomas


= --Apple-Mail-9-191894252-- From ryuji.wakikawa@gmail.com Sun Nov 8 20:14:03 2009 Return-Path: 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 2DC893A6ABA for ; Sun, 8 Nov 2009 20:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 xlvxQ7-pnwyk for ; Sun, 8 Nov 2009 20:14:02 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 52BEB3A6A99 for ; Sun, 8 Nov 2009 20:14:02 -0800 (PST) Received: by yxe30 with SMTP id 30so2917095yxe.29 for ; Sun, 08 Nov 2009 20:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer; bh=+hIVHEaDqLDzW4/gYGWuid6XIP6lMC8JEoTNAjOia74=; b=YrkJfHgWxw3C2pJyIuBFoEUidwOEq33M2HGR44/RV9rDSOYgJS6pjqn8EcLDmP4BSX ujOG5gby6RM6ab16K1Ha2hpk9fI0lUFoavarA5qCcy1usVzOAKtTamPOVhLTs/u+kBjS 3QXUMAdOWpdALWvxl3yUuNwqJJh1F0UUb2R8I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer; b=EKTSKXf7gr6kiW3HiYE5X5LU6HNRVUjNKf1tQMfw/RTrdYTBC2P7U+i9pWcjQBbRJR ePU9E7FOH22SX+A4JnPwsOF/MXwyH/JgihTp5jGJgZNHhpk43UEGOWM6YegpywDQ6+49 UQ3/YpR3zoD4Ye75rjxb8YUOPAjQI/Mcee2v0= Received: by 10.150.76.6 with SMTP id y6mr12484094yba.60.1257740065516; Sun, 08 Nov 2009 20:14:25 -0800 (PST) Received: from host-24-104.meeting.ietf.org (host-24-104.meeting.ietf.org [133.93.24.104]) by mx.google.com with ESMTPS id 16sm1209772gxk.7.2009.11.08.20.14.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 20:14:24 -0800 (PST) Message-Id: <667FF4E0-90F7-45CA-8B43-91809ECAE2FF@gmail.com> From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 13:14:21 +0900 X-Mailer: Apple Mail (2.936) Subject: [Autoconf] AUTOCONF meeting at Hiroshima X-BeenThere: autoconf@ietf.org 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: Mon, 09 Nov 2009 04:14:03 -0000 Hi all, AUTOCONF meeting will be held today. All the meeting materials can be found on the IETF HP. https://datatracker.ietf.org/meeting/76/materials.html we are still looking for minutes taker... can anyone volunteer this? thanks ryuji From ietf@thomasclausen.org Sun Nov 8 20:17:00 2009 Return-Path: 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 29EDD28C0F5 for ; Sun, 8 Nov 2009 20:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 VlVHArXB7h8y for ; Sun, 8 Nov 2009 20:16:59 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 57D1C28C0EC for ; Sun, 8 Nov 2009 20:16:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 6E534437E53; Sun, 8 Nov 2009 20:17:25 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (host-113-143.meeting.ietf.org [133.93.113.143]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id DDB32438012; Sun, 8 Nov 2009 20:17:24 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Ryuji Wakikawa In-Reply-To: <667FF4E0-90F7-45CA-8B43-91809ECAE2FF@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-2-260168162 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 05:17:22 +0100 References: <667FF4E0-90F7-45CA-8B43-91809ECAE2FF@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] AUTOCONF meeting at Hiroshima X-BeenThere: autoconf@ietf.org 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: Mon, 09 Nov 2009 04:17:00 -0000 --Apple-Mail-2-260168162 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Nov 9, 2009, at 5:14 AM, Ryuji Wakikawa wrote: > Hi all, > > AUTOCONF meeting will be held today. > All the meeting materials can be found on the IETF HP. > > https://datatracker.ietf.org/meeting/76/materials.html > > we are still looking for minutes taker... > can anyone volunteer this? Ulrich volunteered to be either minute-taker or Jabber speaker. We need still 3 volunteers (Jabber scribe, minute takers, ...) Volunteers are *greatly* appreciated. Thanks, Thomas --Apple-Mail-2-260168162 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit
On Nov 9, 2009, at 5:14 AM, Ryuji Wakikawa wrote:

Hi all,

AUTOCONF meeting will be held today.
All the meeting materials can be found on the IETF HP.

https://datatracker.ietf.org/meeting/76/materials.html

we are still looking for minutes taker...
can anyone volunteer this?

Ulrich volunteered to be either minute-taker or Jabber speaker. We need still 3 volunteers (Jabber scribe, minute takers, ...)

Volunteers are *greatly* appreciated.

Thanks,

Thomas
--Apple-Mail-2-260168162-- From ryuji.wakikawa@gmail.com Sun Nov 8 22:56:51 2009 Return-Path: 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 619D33A69A5 for ; Sun, 8 Nov 2009 22:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 OZoMXNPKBKUu for ; Sun, 8 Nov 2009 22:56:50 -0800 (PST) Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 9868A3A6915 for ; Sun, 8 Nov 2009 22:56:50 -0800 (PST) Received: by yxe30 with SMTP id 30so2998179yxe.29 for ; Sun, 08 Nov 2009 22:57:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:subject:mime-version:date :x-mailer; bh=DzRCAY/ZGVSjIyJUdYQA8lisaGJGGLurvCNbqslmJu4=; b=aUqycYnSIiHurzaVQcij5mBHPon9b+eci+2VlDr8MwfwS5SzHnHsfyoaYKY1xiFuEy 2kzLT6VeqpdaKS18bW2H10BoP/ztqq2JAfYBZWeRXW9ZgxTjI9VWbBNv+qxJEgT3dXTC b1a4CC90YPURa7+oZojXfsHcOSyYaKPOBWaDc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding:subject :mime-version:date:x-mailer; b=inS3rGH09oWacEzQ1p1fn7Dcpb6n4WYqz75krx8QXDRd75Pjcdy39txwnOemLOr74z gNIog3P+XE4kjUIpKAMTAKG3Js7QIhMJPnRHemUKQZQ0rIWmulMgsoWesA7GTFC2pDFY dDyJ4eWnF860YtPdzyVs7V4jYINNZ1CrFBa10= Received: by 10.150.250.13 with SMTP id x13mr12639429ybh.230.1257749833071; Sun, 08 Nov 2009 22:57:13 -0800 (PST) Received: from host-24-104.meeting.ietf.org (host-24-104.meeting.ietf.org [133.93.24.104]) by mx.google.com with ESMTPS id 15sm1239023gxk.0.2009.11.08.22.57.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 08 Nov 2009 22:57:12 -0800 (PST) Message-Id: <38D051C4-6E05-4D43-8DB1-BB9CDB7D43C3@gmail.com> From: Ryuji Wakikawa To: autoconf@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 9 Nov 2009 15:57:08 +0900 X-Mailer: Apple Mail (2.936) Subject: [Autoconf] RFID experimentation X-BeenThere: autoconf@ietf.org 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: Mon, 09 Nov 2009 06:56:51 -0000 Hi all, To show loyalty to WIDE project (IETF 76 host) as a WIDE member, I would like to encourage you to use the RFID tag in our AUTOCONF meeting. I expect all of the speakers and folks standing at mic activate RFID and use RFID for showing your name and affiliation on the screen. IF you plan to speak up during the meeting, don't forget activating your tag and touching reader before your speak. You will get a priority pass to ask questions. (kidding) If you have activation problem, there is a help desk at the 3rd floor. thanks ryuji From alexandru.petrescu@gmail.com Mon Nov 9 01:05:33 2009 Return-Path: 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 9E4083A659B for ; Mon, 9 Nov 2009 01:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.149, 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 gEVR15SeRHwg for ; Mon, 9 Nov 2009 01:05:33 -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 B513E3A685D for ; Mon, 9 Nov 2009 01:05:32 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nA995v04025381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Nov 2009 10:05:57 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nA995ub1023769 for ; Mon, 9 Nov 2009 10:05:57 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nA995tCR010988 for ; Mon, 9 Nov 2009 10:05:56 +0100 Message-ID: <4AF7DB73.9030208@gmail.com> Date: Mon, 09 Nov 2009 10:05:55 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] "off-link" prefix solving the contradiction of "/128 prefix" to rfc4291; but LL being "on-link"? X-BeenThere: autoconf@ietf.org 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: Mon, 09 Nov 2009 09:05:33 -0000 About using exclusively "off-link" prefixes (not on-link prefixes) to ensure we can use "/128" prefixes and in agreement with rfc4291. But LL addresses are by definition on-link. Do we forbid them? Do we recommend "off-link" prefixes but still allow LLs _and_ "on-link" prefixes? Or do we simply MUST "/128" and off-link (and implicitely rule out "on-link" and LL). Alex (sorry can't jabber). From alexandru.petrescu@gmail.com Mon Nov 9 01:10:11 2009 Return-Path: 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 306663A6B10 for ; Mon, 9 Nov 2009 01:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.148, 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 R5G3dyU9PvJo for ; Mon, 9 Nov 2009 01:10:10 -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 A4E313A6903 for ; Mon, 9 Nov 2009 01:10:08 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nA99AXup030744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Nov 2009 10:10:33 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nA99AXij025686 for ; Mon, 9 Nov 2009 10:10:33 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nA99AW9m013415 for ; Mon, 9 Nov 2009 10:10:33 +0100 Message-ID: <4AF7DC89.2090603@gmail.com> Date: Mon, 09 Nov 2009 10:10:33 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] eg NBMA links... X-BeenThere: autoconf@ietf.org 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: Mon, 09 Nov 2009 09:10:11 -0000 Eg NBMA links doesn't mean AUTOCONF, so the current text in RFCs excluding DAD in eg NBMA links doesn't apply. In AUTOCONF we don't know what kinds of links we use. (so no NBMA, no not NBMA). Alex From alexandru.petrescu@gmail.com Mon Nov 9 01:39:28 2009 Return-Path: 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 2C10F3A67FB for ; Mon, 9 Nov 2009 01:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[AWL=0.147, 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 aMQT1J92aMal for ; Mon, 9 Nov 2009 01:39:27 -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 D968C3A6885 for ; Mon, 9 Nov 2009 01:39:24 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nA99dn3W006656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Nov 2009 10:39:49 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nA99dn9J004261 for ; Mon, 9 Nov 2009 10:39:49 +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 nA99dnYt004715 for ; Mon, 9 Nov 2009 10:39:49 +0100 Message-ID: <4AF7E365.8010904@gmail.com> Date: Mon, 09 Nov 2009 10:39:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] protocols requiring LLs X-BeenThere: autoconf@ietf.org 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: Mon, 09 Nov 2009 09:39:28 -0000 There are protocols which _require_ use of LLs. OSPF is one. Alex (no need to jabber it) From alexandru.petrescu@gmail.com Mon Nov 9 02:18:06 2009 Return-Path: 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 160D33A6B3F for ; Mon, 9 Nov 2009 02:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.803 X-Spam-Level: X-Spam-Status: No, score=-0.803 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_50=0.001, 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 Wtn0P72ZuE-t for ; Mon, 9 Nov 2009 02:18:05 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 232C83A6B3C for ; Mon, 9 Nov 2009 02:18:04 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nA9AISbG003802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 9 Nov 2009 11:18:28 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nA9AISZB018510 for ; Mon, 9 Nov 2009 11:18:28 +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 nA9AIRos022246 for ; Mon, 9 Nov 2009 11:18:28 +0100 Message-ID: <4AF7EC73.9020506@gmail.com> Date: Mon, 09 Nov 2009 11:18:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Autoconf] Stacks use LLs - don't do surgery removing them X-BeenThere: autoconf@ietf.org 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: Mon, 09 Nov 2009 10:18:06 -0000 LLs are not an illness. I have run IPv6 over many kinds of links. LLs are always there over: serial, ethernet, wifi, bluetooth, 3g, umts - many kinds. This is running code. This is practical. This is implementation. I agree with Ronald about not wanting to go do surgery on the IPv6 stacks to make them stop using using LLs. I don't know what you (the group) are talking about when going against LLs on all fronts. Alex (no need to mike it - it's obvious) From henning.rogge@fkie.fraunhofer.de Mon Nov 9 02:25:02 2009 Return-Path: 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 694463A680D for ; Mon, 9 Nov 2009 02:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.054 X-Spam-Level: X-Spam-Status: No, score=-6.054 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 jab38Dauh9pK for ; Mon, 9 Nov 2009 02:25:01 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 5FBDB3A67B1 for ; Mon, 9 Nov 2009 02:25:01 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7RR8-00011D-CP for autoconf@ietf.org; Mon, 09 Nov 2009 11:25:26 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N7RR8-0003X2-3S for autoconf@ietf.org; Mon, 09 Nov 2009 11:25:26 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Mon, 9 Nov 2009 11:25:17 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-14-generic; KDE/4.3.2; i686; ; ) References: <4AF7EC73.9020506@gmail.com> In-Reply-To: <4AF7EC73.9020506@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4309237.R7tNkRl7Hz"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911091125.23031.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10002/Mon Nov 9 02:05:15 2009) by mailguard.fgan.de X-Scan-Signature: b1467e4067045b82e2ed93aca61069d0 Subject: Re: [Autoconf] Stacks use LLs - don't do surgery removing them X-BeenThere: autoconf@ietf.org 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: Mon, 09 Nov 2009 10:25:02 -0000 --nextPart4309237.R7tNkRl7Hz Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 9 2009 11:18:27 Alexandru Petrescu wrote: > I don't know what you (the group) are talking about when going against > LLs on all fronts. Nobody here want to prevent anyone from using LL... it's just that the normal IPv6 LL mechanisms including DAD will not give yo= u=20 guarantied good result in a mesh network. So either you have to live with the fact that your LL might conflicting or = you=20 need a better algorithm to get them (better than DAD). Henning Rogge =2D- Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart4309237.R7tNkRl7Hz Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkr37g0ACgkQRIfGfFXsz+CheQCgi6uxZCA0ebjJ2q6oQ6r03Cu7 AbMAnA/E5Yj9gHWgUo84+rpGJ8dyidbj =BeXp -----END PGP SIGNATURE----- --nextPart4309237.R7tNkRl7Hz-- From paul@marvell.com Wed Nov 11 11:23:14 2009 Return-Path: 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 2E6B63A6805 for ; Wed, 11 Nov 2009 11:23:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 zn4V6akEuNRY for ; Wed, 11 Nov 2009 11:23:13 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id 6455F3A66B4 for ; Wed, 11 Nov 2009 11:23:13 -0800 (PST) X-ASG-Debug-ID: 1257967421-386b027a0000-tL4nV1 X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id A790A15591D for ; Wed, 11 Nov 2009 11:23:41 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id 53Bs9dz2lju7fKkL for ; Wed, 11 Nov 2009 11:23:41 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 88E537F004 for ; Wed, 11 Nov 2009 11:23:41 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 11:23:40 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Wed, 11 Nov 2009 11:23:41 -0800 From: Paul Lambert To: "autoconf@ietf.org" Date: Wed, 11 Nov 2009 11:23:40 -0800 X-ASG-Orig-Subj: Ad Hoc Wireless Address Assignment Thread-Topic: Ad Hoc Wireless Address Assignment Thread-Index: AcphHIMKFCxhhbBaQsOIY/cN3Li3oQB5oqfw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BC8D@SC-VEXCH2.marvell.com> References: <4AF7DC89.2090603@gmail.com> In-Reply-To: <4AF7DC89.2090603@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2009 19:23:40.0966 (UTC) FILETIME=[79E6AC60:01CA6304] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1257967421 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Subject: [Autoconf] Ad Hoc Wireless Address Assignment X-BeenThere: autoconf@ietf.org 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: Wed, 11 Nov 2009 19:23:14 -0000 Hello, As a occasional lurker ... I'm hoping someone could point me to the most ap= plicable draft document to support a very near term application of this gro= ups work in consumer devices. The basic problem statement is: - environment is 802.11 IBSS with security - multicast is not available to all devies until=20 after they have been "discovered" in some other manner - provide some form of accelerated discover for the L2=20 addresses in the network - Assign unique IPv4 addresses - Optionally assign unique IPv6 addresses Paul PS - I'm only an occasioanl lurker, and in attempting to read the mail list= and drafts I could not get a clear view of an answer ... so please excuse = this post if it's a na=EFve question=20 From alexandru.petrescu@gmail.com Wed Nov 11 11:34:50 2009 Return-Path: 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 1313D3A680C for ; Wed, 11 Nov 2009 11:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.97 X-Spam-Level: X-Spam-Status: No, score=-1.97 tagged_above=-999 required=5 tests=[AWL=0.279, 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 nFj93sDYAeYw for ; Wed, 11 Nov 2009 11:34:49 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id A5E0C3A67B2 for ; Wed, 11 Nov 2009 11:34:47 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 011F2D4807D; Wed, 11 Nov 2009 20:35:11 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id C5790D4804B; Wed, 11 Nov 2009 20:35:08 +0100 (CET) Message-ID: <4AFB11EA.6030001@gmail.com> Date: Wed, 11 Nov 2009 20:35:06 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <4AF7EC73.9020506@gmail.com> <200911091125.23031.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911091125.23031.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091111-0, 11/11/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Stacks use LLs - don't do surgery removing them X-BeenThere: autoconf@ietf.org 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: Wed, 11 Nov 2009 19:34:50 -0000 Henning Rogge a écrit : > On Mon November 9 2009 11:18:27 Alexandru Petrescu wrote: >> I don't know what you (the group) are talking about when going against >> LLs on all fronts. > Nobody here want to prevent anyone from using LL... > > it's just that the normal IPv6 LL mechanisms including DAD will not give you > guarantied good result in a mesh network. Henning, but DAD is not a mechanism specific to LLs. It is a mechanism specific to all current addresses. In this sense - do you also discard all other addresses, like globals? > So either you have to live with the fact that your LL might conflicting or you > need a better algorithm to get them (better than DAD). I want LLs to be treated as first-class citizens. LLs should be used in the first steps towards configuring other addresses. They are very practical - always there, on many types of links, prior to receiving any packet for auto-configuration. Even links which have not specified an IETF-blessed means for forming an Interface Identifier do offer implemented link-local addresses (I mean e.g. USB). Otherwise, if not using LLs, you're going to be using the unspecified addresses "::" in the src field of the initial packets configuring wider-than-local scoped addresses (globals or ULAs). The uniqueness requirements for LLs are easier to satisfy than uniqueness for across-two-hops, or across-MANET: they're supposed unique on the link scope, not wider. That is easier to ensure, with DAD or with any other new detection of duplicated addresses mechanism. That said, I will stay silent for a while. Alex > > Henning Rogge > -- > Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für > Kommunikation, Informationsverarbeitung und Ergonomie FKIE > Kommunikationssysteme (KOM) > Neuenahrer Straße 20, 53343 Wachtberg, Germany > Telefon +49 228 9435-263, Fax +49 228 9435 685 > mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de > GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Wed Nov 11 11:43:07 2009 Return-Path: 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 AA41728C0CF for ; Wed, 11 Nov 2009 11:43:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.974 X-Spam-Level: X-Spam-Status: No, score=-1.974 tagged_above=-999 required=5 tests=[AWL=0.275, 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 bz5G7sPdnrEk for ; Wed, 11 Nov 2009 11:43:06 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id A72B73A68A8 for ; Wed, 11 Nov 2009 11:43:05 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 7BE85D48135; Wed, 11 Nov 2009 20:43:29 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 72C08D4804B; Wed, 11 Nov 2009 20:43:27 +0100 (CET) Message-ID: <4AFB13DC.7060907@gmail.com> Date: Wed, 11 Nov 2009 20:43:24 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Paul Lambert References: <4AF7DC89.2090603@gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BC8D@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BC8D@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091111-0, 11/11/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Ad Hoc Wireless Address Assignment X-BeenThere: autoconf@ietf.org 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: Wed, 11 Nov 2009 19:43:07 -0000 Paul Lambert a écrit : > Hello, > > As a occasional lurker ... I'm hoping someone could point me to the > most applicable draft document to support a very near term > application of this groups work in consumer devices. The basic > problem statement is: > > - environment is 802.11 IBSS with security - multicast is not > available to all devies until after they have been "discovered" in > some other manner You mean link-layer multicast? Or IP multicast? I am asking because if there is no link-layer multicast then IPv6 as it is won't work in no way. I am not sure what you mean by "discovered in other manner". > - provide some form of accelerated discover for the L2 addresses in > the network In IPv6, maybe tweaking the ND timers will do it accelerated. (not sure what you mean by accelerating, what is slow?). > - Assign unique IPv4 addresses If you need IPv4 link-local addresses, they're already there. > - Optionally assign unique IPv6 addresses Well, if you need IPv6 link-local addresses on this setting - they're already there. If you need global addresses then is it feasible to configure them hardcoded on each device? Or adminstratively decide that _one_ of the devices is _the_ Router sending them an RA and being the DHCPv4 Server, and hardcode the prefixes in dhcpd.conf and radvd.conf. Probably the Router is the same machine which connects to the Internet too? What do the others think? Alex > > Paul > > > PS - I'm only an occasioanl lurker, and in attempting to read the > mail list and drafts I could not get a clear view of an answer ... so > please excuse this post if it's a naïve question > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From paul@marvell.com Wed Nov 11 12:13:16 2009 Return-Path: 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 521E93A68E7 for ; Wed, 11 Nov 2009 12:13:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_35=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 95SWMVUfDqRM for ; Wed, 11 Nov 2009 12:13:14 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id AEB8528C0D9 for ; Wed, 11 Nov 2009 12:13:14 -0800 (PST) X-ASG-Debug-ID: 1257970423-027302100000-tL4nV1 X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id 19A9A153B61; Wed, 11 Nov 2009 12:13:43 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id MDvAdijVyOJM1UGE; Wed, 11 Nov 2009 12:13:43 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id DA9317F005; Wed, 11 Nov 2009 12:13:42 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 12:13:42 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Wed, 11 Nov 2009 12:13:42 -0800 From: Paul Lambert To: Alexandru Petrescu Date: Wed, 11 Nov 2009 12:13:41 -0800 X-ASG-Orig-Subj: RE: [Autoconf] Ad Hoc Wireless Address Assignment Thread-Topic: [Autoconf] Ad Hoc Wireless Address Assignment Thread-Index: AcpjB0NjU6TYsgJdTuKd9wSfYN82uAAATgLg Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BCCD@SC-VEXCH2.marvell.com> References: <4AF7DC89.2090603@gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BC8D@SC-VEXCH2.marvell.com> <4AFB13DC.7060907@gmail.com> In-Reply-To: <4AFB13DC.7060907@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2009 20:13:42.0519 (UTC) FILETIME=[76F75070:01CA630B] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1257970423 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Ad Hoc Wireless Address Assignment X-BeenThere: autoconf@ietf.org 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: Wed, 11 Nov 2009 20:13:16 -0000 > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] ... >=20 > Paul Lambert a =E9crit : > > Hello, > > > > As a occasional lurker ... I'm hoping someone could point me to the > > most applicable draft document to support a very near term > > application of this groups work in consumer devices. The basic > > problem statement is: > > > > - environment is 802.11 IBSS with security - multicast is not > > available to all devies until after they have been "discovered" in > > some other manner >=20 > You mean link-layer multicast? Or IP multicast? Link - with encryption, AES-CCMP does not allow a common group key, so broa= dcast/multicast is not available until after a device has been discovered a= nd the per-STA multicast keys are exchanged. Of course - IP layer will als= o not work until have the network has bootstrapped. >=20 > I am asking because if there is no link-layer multicast then IPv6 as it > is won't work in no way. I am not sure what you mean by "discovered in > other manner". >=20 > > - provide some form of accelerated discover for the L2 addresses in > > the network >=20 > In IPv6, maybe tweaking the ND timers will do it accelerated. (not sure > what you mean by accelerating, what is slow?). Accelerated in this context is looking for individual devices to give hints= about possible neighbors. At L2, you could wait for many beacon periods a= nd discover most of the peer devices (except a few hidden or in power save = or temporarily absent). Beacons are not reliable, active probing is not vi= able, we're already starting to use Public Action frames to discover "awake= " or "selected" devices. =20 Basically - every device needs to store what it thinks is the composition o= f the network and share this when requested. At a minimum, this is L2 memb= ership. It could also include L3 addresses explicitly or implicitly. There are some proprietary implementations of the above ... a standard woul= d be nice. I'm currently writing such specifications in L2 organizations (= Wi-Fi Alliance). I'll likely extend it to some L3 discovery if there is no= thing available from this working group. >=20 > > - Assign unique IPv4 addresses >=20 > If you need IPv4 link-local addresses, they're already there. Additional signaling is required to ensure address uniqueness. IPv4 link-lo= cal addresses do not work as defined for multicast challenged networks. So there is not an answer. Note - this is causing Link Local addresses to NOT be used in some BSS appl= ications also. Not all devices will be available at any one time. Mobile = networks are not consistent and prevent multicast based discovery. >=20 > > - Optionally assign unique IPv6 addresses >=20 > Well, if you need IPv6 link-local addresses on this setting - they're > already there. >=20 > If you need global addresses then is it feasible to configure them > hardcoded on each device? Humm ... of course ... Thanks for the reminder :-) I think the groups I'm = working with never consider this ... IPv4 is here now and we never get arou= nd to future proofing by getting IPv6 and IPv6 addresses. These are L2 gro= ups ... so there has not been much in L3 definitions or planning. It looks= like I may need to change this ... I'll take in some IPv6 requirements and= see what happens. =20 I really do appreciate the reminder ... we're right at a point where at lea= st having some L2 negotiation ability to indicate the L3 type will be of va= lue (I believe this in 802.11u or 802.11v). I'll work to get this inserted= . >=20 > Or adminstratively decide that _one_ of the devices is _the_ Router > sending them an RA and being the DHCPv4 Server, and hardcode the > prefixes in dhcpd.conf and radvd.conf. Probably the Router is > the same machine which connects to the Internet too? Wi-Fi Direct is doing something like this and needs to have DHCP. It does = create real pro0blems for fail-over and "real" mobility (i.e. unpredictable= coming and going of devices) IBSS solutions still need a IPv4 link local address mechanism that works ..= . likely by device caching of peer l2 addresses. Regards, Paul >=20 > What do the others think? >=20 > Alex >=20 > > > > Paul > > > > > > PS - I'm only an occasioanl lurker, and in attempting to read the > > mail list and drafts I could not get a clear view of an answer ... so > > please excuse this post if it's a na=EFve question > > _______________________________________________ Autoconf mailing list > > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > > From teco@inf-net.nl Wed Nov 11 14:02:02 2009 Return-Path: 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 DB2623A6AF9 for ; Wed, 11 Nov 2009 14:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.638 X-Spam-Level: X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1] 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 JPlGWcQN6M1W for ; Wed, 11 Nov 2009 14:02:01 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 4EA7A3A69E2 for ; Wed, 11 Nov 2009 14:02:01 -0800 (PST) Received: (qmail 19759 invoked from network); 11 Nov 2009 23:02:26 +0100 Received: from host-194-214.meeting.ietf.org (HELO M90Teco) (133.93.194.214) by server9.hosting2go.nl with SMTP; 11 Nov 2009 23:02:26 +0100 From: "Teco Boot" To: "'Paul Lambert'" References: <4AF7DC89.2090603@gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BC8D@SC-VEXCH2.marvell.com> <4AFB13DC.7060907@gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BCCD@SC-VEXCH2.marvell.com> In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BCCD@SC-VEXCH2.marvell.com> Date: Thu, 12 Nov 2009 07:01:50 +0900 Message-ID: <02bc01ca631a$a6ac9c30$f405d490$@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: AcpjB0NjU6TYsgJdTuKd9wSfYN82uAAATgLgAAQEcMA= Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Ad Hoc Wireless Address Assignment X-BeenThere: autoconf@ietf.org 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: Wed, 11 Nov 2009 22:02:03 -0000 Hello Paul, You could read our workgroup draft. Any comment is appreciated. http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-00.txt With having guaranteed unique MAC addresses, IPv6 addresses are easy to=20 configure. Link-locals should be there, but does not provide multi-hop connectivity. If needed, you could use ULA prefix, this can be generated locally on each node. For globals, this WG does not have a solution yet, = but there are a number of proposals. When running NHDP on P2P link to the beaconing nodes, you will get fast neighbor learning. If all nodes set up such channels, the beaconing nodes are aware of their 2-hop neighbors. And then the next step, the beaconing nodes try to set up NHDP to all their 2-hop neighbors. This will make = the local 2-hop topology tables pretty good populated. Adjustments on NHDP could be needed, to make this work. Teco. >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens >Paul Lambert >Verzonden: donderdag 12 november 2009 5:14 >Aan: Alexandru Petrescu >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] Ad Hoc Wireless Address Assignment > > > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >... > >> >> Paul Lambert a =E9crit : >> > Hello, >> > >> > As a occasional lurker ... I'm hoping someone could point me to the >> > most applicable draft document to support a very near term >> > application of this groups work in consumer devices. The basic >> > problem statement is: >> > >> > - environment is 802.11 IBSS with security - multicast is not >> > available to all devies until after they have been "discovered" in >> > some other manner >> >> You mean link-layer multicast? Or IP multicast? > >Link - with encryption, AES-CCMP does not allow a common group key, so >broadcast/multicast is not available until after a device has been >discovered and the per-STA multicast keys are exchanged. Of course - = IP >layer will also not work until have the network has bootstrapped. > >> >> I am asking because if there is no link-layer multicast then IPv6 as >it >> is won't work in no way. I am not sure what you mean by "discovered >in >> other manner". >> >> > - provide some form of accelerated discover for the L2 addresses in >> > the network >> >> In IPv6, maybe tweaking the ND timers will do it accelerated. (not >sure >> what you mean by accelerating, what is slow?). > >Accelerated in this context is looking for individual devices to give >hints about possible neighbors. At L2, you could wait for many beacon >periods and discover most of the peer devices (except a few hidden or = in >power save or temporarily absent). Beacons are not reliable, active >probing is not viable, we're already starting to use Public Action >frames to discover "awake" or "selected" devices. > >Basically - every device needs to store what it thinks is the >composition of the network and share this when requested. At a = minimum, >this is L2 membership. It could also include L3 addresses explicitly = or >implicitly. > >There are some proprietary implementations of the above ... a standard >would be nice. I'm currently writing such specifications in L2 >organizations (Wi-Fi Alliance). I'll likely extend it to some L3 >discovery if there is nothing available from this working group. > >> >> > - Assign unique IPv4 addresses >> >> If you need IPv4 link-local addresses, they're already there. > >Additional signaling is required to ensure address uniqueness. IPv4 >link-local addresses do not work as defined for multicast challenged >networks. > >So there is not an answer. > >Note - this is causing Link Local addresses to NOT be used in some BSS >applications also. Not all devices will be available at any one time. >Mobile networks are not consistent and prevent multicast based >discovery. > >> >> > - Optionally assign unique IPv6 addresses >> >> Well, if you need IPv6 link-local addresses on this setting - they're >> already there. >> >> If you need global addresses then is it feasible to configure them >> hardcoded on each device? > >Humm ... of course ... Thanks for the reminder :-) I think the groups >I'm working with never consider this ... IPv4 is here now and we never >get around to future proofing by getting IPv6 and IPv6 addresses. = These >are L2 groups ... so there has not been much in L3 definitions or >planning. It looks like I may need to change this ... I'll take in = some >IPv6 requirements and see what happens. > >I really do appreciate the reminder ... we're right at a point where at >least having some L2 negotiation ability to indicate the L3 type will = be >of value (I believe this in 802.11u or 802.11v). I'll work to get this >inserted. > >> >> Or adminstratively decide that _one_ of the devices is _the_ Router >> sending them an RA and being the DHCPv4 Server, and hardcode the >> prefixes in dhcpd.conf and radvd.conf. Probably the Router is >> the same machine which connects to the Internet too? > >Wi-Fi Direct is doing something like this and needs to have DHCP. It >does create real pro0blems for fail-over and "real" mobility (i.e. >unpredictable coming and going of devices) > >IBSS solutions still need a IPv4 link local address mechanism that = works >... likely by device caching of peer l2 addresses. > >Regards, > >Paul > > >> >> What do the others think? >> >> Alex >> >> > >> > Paul >> > >> > >> > PS - I'm only an occasioanl lurker, and in attempting to read the >> > mail list and drafts I could not get a clear view of an answer ... >so >> > please excuse this post if it's a na=EFve question >> > _______________________________________________ Autoconf mailing >list >> > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf >> > > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf From paul@marvell.com Wed Nov 11 17:20:09 2009 Return-Path: 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 A0BC23A6A3E for ; Wed, 11 Nov 2009 17:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_35=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 h0-zXMdDBJ0l for ; Wed, 11 Nov 2009 17:20:08 -0800 (PST) Received: from dakia2.marvell.com (dakia2.marvell.com [65.219.4.35]) by core3.amsl.com (Postfix) with ESMTP id 73E673A63C9 for ; Wed, 11 Nov 2009 17:20:08 -0800 (PST) X-ASG-Debug-ID: 1257988836-7b2901960000-tL4nV1 X-Barracuda-URL: http://10.68.76.222:80/cgi-bin/mark.cgi Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com (Spam & Virus Firewall) with ESMTP id 797B91588BB; Wed, 11 Nov 2009 17:20:36 -0800 (PST) Received: from maili.marvell.com (maili.marvell.com [10.68.76.51]) by dakia2.marvell.com with ESMTP id X3fTFisID1xHyzwu; Wed, 11 Nov 2009 17:20:36 -0800 (PST) Received: from MSI-MTA.marvell.com (msi-mta.marvell.com [10.68.76.91]) by maili.marvell.com (Postfix) with ESMTP id 736D07F03C; Wed, 11 Nov 2009 17:20:36 -0800 (PST) Received: from sc-owa01.marvell.com ([10.93.76.21]) by MSI-MTA.marvell.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Nov 2009 17:20:36 -0800 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by sc-owa01.marvell.com ([10.93.76.21]) with mapi; Wed, 11 Nov 2009 17:20:35 -0800 From: Paul Lambert To: Teco Boot Date: Wed, 11 Nov 2009 17:20:34 -0800 X-ASG-Orig-Subj: RE: [Autoconf] Ad Hoc Wireless Address Assignment Thread-Topic: [Autoconf] Ad Hoc Wireless Address Assignment Thread-Index: AcpjB0NjU6TYsgJdTuKd9wSfYN82uAAATgLgAAQEcMAABikFsA== Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BDB1@SC-VEXCH2.marvell.com> References: <4AF7DC89.2090603@gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BC8D@SC-VEXCH2.marvell.com> <4AFB13DC.7060907@gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D013B5C6BCCD@SC-VEXCH2.marvell.com> <02bc01ca631a$a6ac9c30$f405d490$@nl> In-Reply-To: <02bc01ca631a$a6ac9c30$f405d490$@nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 12 Nov 2009 01:20:36.0088 (UTC) FILETIME=[564EF780:01CA6336] X-Barracuda-Connect: maili.marvell.com[10.68.76.51] X-Barracuda-Start-Time: 1257988836 X-Barracuda-Virus-Scanned: by dakia2.marvell.com at marvell.com X-Barracuda-Spam-Score: -1002.00 X-Barracuda-Spam-Status: No, SCORE=-1002.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=1000.0 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Ad Hoc Wireless Address Assignment X-BeenThere: autoconf@ietf.org 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, 12 Nov 2009 01:20:09 -0000 Thanks Teco, Some good guidelines ... the /32 subnet clearly helps the scenarios I'm des= cribing. Now ... on Link Local, I agree that a locally generated LL addres= s that is subsequently checked solely for uniqueness using multicast techni= ques should be avoided. =20 You may want to glance at: http://www.wi-fi.org/news_articles.php?f=3Dmedia= _news&news_id=3D909 Wi-Fi is evolving rapidly ... the groups that are doing this work are not v= ery fluent in L3 addressing issues. Some odd scenarios might start to appe= ar with these new technologies - like the same L2 address on multiple BSSs.= =20 The guidelines are good, but a specific protocol solution is required to pr= ovide unique IPv4 addresses in a distributed manner. My planned approach will likely be to: Have every device keep track of peers - and share in a distributed manner 1) On first enrollment between two devices the master (registrar) picks it's IP address and gives the list of network MAC addresses and IP addresses to the new enrollee ...=20 2) Network size is limited and addresses are discarded using LRU rule 3) As a STA contacts other STA for the first time (post WPA),=20 the same information is exchanged between the pair of devices. 4) Local table of peers is updated based on this exchange 5) Multicast table validation might be viable (optional) after a=20 STA becomes fully associated with a set of peers and=20 limited multicast is possible. Regards, Paul =20 Paul A. Lambert | Marvell Semiconductor | +1 650-787-9141 =20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: Wednesday, November 11, 2009 2:02 PM > To: Paul Lambert > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Ad Hoc Wireless Address Assignment >=20 > Hello Paul, >=20 > You could read our workgroup draft. Any comment is appreciated. > http://www.ietf.org/id/draft-ietf-autoconf-adhoc-addr-model-00.txt >=20 > With having guaranteed unique MAC addresses, IPv6 addresses are easy to > configure. Link-locals should be there, but does not provide multi-hop > connectivity. If needed, you could use ULA prefix, this can be generated > locally on each node. For globals, this WG does not have a solution yet, > but there are a number of proposals. >=20 > When running NHDP on P2P link to the beaconing nodes, you will get > fast neighbor learning. If all nodes set up such channels, the beaconing > nodes are aware of their 2-hop neighbors. And then the next step, the > beaconing > nodes try to set up NHDP to all their 2-hop neighbors. This will make the > local 2-hop topology tables pretty good populated. Adjustments on NHDP > could be needed, to make this work. >=20 > Teco. >=20 >=20 >=20 > >-----Oorspronkelijk bericht----- > >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens > >Paul Lambert > >Verzonden: donderdag 12 november 2009 5:14 > >Aan: Alexandru Petrescu > >CC: autoconf@ietf.org > >Onderwerp: Re: [Autoconf] Ad Hoc Wireless Address Assignment > > > > > > > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > >... > > > >> > >> Paul Lambert a =E9crit : > >> > Hello, > >> > > >> > As a occasional lurker ... I'm hoping someone could point me to the > >> > most applicable draft document to support a very near term > >> > application of this groups work in consumer devices. The basic > >> > problem statement is: > >> > > >> > - environment is 802.11 IBSS with security - multicast is not > >> > available to all devies until after they have been "discovered" in > >> > some other manner > >> > >> You mean link-layer multicast? Or IP multicast? > > > >Link - with encryption, AES-CCMP does not allow a common group key, so > >broadcast/multicast is not available until after a device has been > >discovered and the per-STA multicast keys are exchanged. Of course - IP > >layer will also not work until have the network has bootstrapped. > > > >> > >> I am asking because if there is no link-layer multicast then IPv6 as > >it > >> is won't work in no way. I am not sure what you mean by "discovered > >in > >> other manner". > >> > >> > - provide some form of accelerated discover for the L2 addresses in > >> > the network > >> > >> In IPv6, maybe tweaking the ND timers will do it accelerated. (not > >sure > >> what you mean by accelerating, what is slow?). > > > >Accelerated in this context is looking for individual devices to give > >hints about possible neighbors. At L2, you could wait for many beacon > >periods and discover most of the peer devices (except a few hidden or in > >power save or temporarily absent). Beacons are not reliable, active > >probing is not viable, we're already starting to use Public Action > >frames to discover "awake" or "selected" devices. > > > >Basically - every device needs to store what it thinks is the > >composition of the network and share this when requested. At a minimum, > >this is L2 membership. It could also include L3 addresses explicitly or > >implicitly. > > > >There are some proprietary implementations of the above ... a standard > >would be nice. I'm currently writing such specifications in L2 > >organizations (Wi-Fi Alliance). I'll likely extend it to some L3 > >discovery if there is nothing available from this working group. > > > >> > >> > - Assign unique IPv4 addresses > >> > >> If you need IPv4 link-local addresses, they're already there. > > > >Additional signaling is required to ensure address uniqueness. IPv4 > >link-local addresses do not work as defined for multicast challenged > >networks. > > > >So there is not an answer. > > > >Note - this is causing Link Local addresses to NOT be used in some BSS > >applications also. Not all devices will be available at any one time. > >Mobile networks are not consistent and prevent multicast based > >discovery. > > > >> > >> > - Optionally assign unique IPv6 addresses > >> > >> Well, if you need IPv6 link-local addresses on this setting - they're > >> already there. > >> > >> If you need global addresses then is it feasible to configure them > >> hardcoded on each device? > > > >Humm ... of course ... Thanks for the reminder :-) I think the groups > >I'm working with never consider this ... IPv4 is here now and we never > >get around to future proofing by getting IPv6 and IPv6 addresses. These > >are L2 groups ... so there has not been much in L3 definitions or > >planning. It looks like I may need to change this ... I'll take in some > >IPv6 requirements and see what happens. > > > >I really do appreciate the reminder ... we're right at a point where at > >least having some L2 negotiation ability to indicate the L3 type will be > >of value (I believe this in 802.11u or 802.11v). I'll work to get this > >inserted. > > > >> > >> Or adminstratively decide that _one_ of the devices is _the_ Router > >> sending them an RA and being the DHCPv4 Server, and hardcode the > >> prefixes in dhcpd.conf and radvd.conf. Probably the Router is > >> the same machine which connects to the Internet too? > > > >Wi-Fi Direct is doing something like this and needs to have DHCP. It > >does create real pro0blems for fail-over and "real" mobility (i.e. > >unpredictable coming and going of devices) > > > >IBSS solutions still need a IPv4 link local address mechanism that works > >... likely by device caching of peer l2 addresses. > > > >Regards, > > > >Paul > > > > > >> > >> What do the others think? > >> > >> Alex > >> > >> > > >> > Paul > >> > > >> > > >> > PS - I'm only an occasioanl lurker, and in attempting to read the > >> > mail list and drafts I could not get a clear view of an answer ... > >so > >> > please excuse this post if it's a na=EFve question > >> > _______________________________________________ Autoconf mailing > >list > >> > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > >> > > > > >_______________________________________________ > >Autoconf mailing list > >Autoconf@ietf.org > >https://www.ietf.org/mailman/listinfo/autoconf From cjbc@it.uc3m.es Fri Nov 13 08:36:46 2009 Return-Path: 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 A14B13A69FA for ; Fri, 13 Nov 2009 08:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 RTHqMknkWyau for ; Fri, 13 Nov 2009 08:36:45 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 9A8253A698E for ; Fri, 13 Nov 2009 08:36:44 -0800 (PST) X-uc3m-safe: yes Received: from [117.130.143.19] (unknown [117.130.143.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id CED2F6C2C43 for ; Fri, 13 Nov 2009 17:37:11 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "autoconf@ietf.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-QOf2fYdbsIyDqlP7vT3p" Organization: Universidad Carlos III de Madrid Date: Fri, 13 Nov 2009 16:33:13 +0100 Message-Id: <1258126393.5035.20.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17008.000 Subject: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:36:46 -0000 --=-QOf2fYdbsIyDqlP7vT3p Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi all, During the last meeting, it was said several times that even if the uniqueness of link-local was not an issue, LLs have other problems that make it reasonable to discourage their use in MANETs. Can anybody please be so kind of summarising those for me? this is not that obvious to me. Thanks in advance. Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-QOf2fYdbsIyDqlP7vT3p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkr9fDMACgkQNdy6TdFwT2fd8QCgjVu5pAPzhEL/ZafNG7p/Cy3u QyAAn27/UnMXfhAnQvr6ccT0Qqx/9o3G =+uU5 -----END PGP SIGNATURE----- --=-QOf2fYdbsIyDqlP7vT3p-- From cjbc@it.uc3m.es Fri Nov 13 08:44:46 2009 Return-Path: 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 A3B7D3A67F4 for ; Fri, 13 Nov 2009 08:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.955 X-Spam-Level: X-Spam-Status: No, score=-4.955 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 HSf-JdtPaCf3 for ; Fri, 13 Nov 2009 08:44:45 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 458523A67CC for ; Fri, 13 Nov 2009 08:44:45 -0800 (PST) X-uc3m-safe: yes Received: from [117.130.143.19] (unknown [117.130.143.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id B443A65A48B for ; Fri, 13 Nov 2009 17:45:12 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "autoconf@ietf.org" Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-daRAu5DBMas3q3cPkAWT" Organization: Universidad Carlos III de Madrid Date: Fri, 13 Nov 2009 16:44:54 +0100 Message-Id: <1258127094.5035.32.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17008.000 Subject: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Nov 2009 16:44:46 -0000 --=-daRAu5DBMas3q3cPkAWT Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, In addition to my fundamental concerns that I've with this document and that I've shared in different ways (I can do it again if considered useful), I have a bunch of other not so fundamental ones: - Section 3: "The configuration proposed by this model is applicable to any router's IP interface" --> I wonder if this should be changed to "The configuration proposed by this model is applicable to any router's IP MANET interface" or something like that. By saying "any router's IP interface" it may seem that the configuration of "non-MANET" interfaces would also follow the guidelines provided by the document (i.e., /128, no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state that the model is for MANET interfaces. - Section 4: "no two such interfaces in the network should be configured with the same subnet prefix" --> this at least conflicts with LLs. (I'm not bringing up __here__ again the LL issue, just pointing out that the document should be revised to avoid this kind of contradictory statements: "Note that while an IPv6 link-local address is assigned to each interface as per [RFC4291]" and "no two such interfaces in the network should be configured with the same subnet prefix". - Section 6.1: "These limitations are further exacerbated by the smaller pool of IPv4 link-local addresses to choose from and thus increased reliance on DAD" --> if link-locals are not considered and "normal" DAD is not considered suitable for MANETs, I think this sentence makes no sense and should just simply be removed. - Section 6.2: "Routers cannot forward any packet with link-local source or destination address to other links..." --> this is rather obvious and not particular of MANETs, why is this described in the document? - Section 6.2: "There is no mechanism to ensure that IPv6 link-local addresses are unique across multiple links, hence they can not be used to reliably identify routers." --> this is not particular of MANETs either, why is in the document? - Appendix A: "MANET Link Model" --> I don't believe in the existence of a "MANET Link", and I don't see its relevance in an __address autoconfiguration__ document. Repeating myself here... I think this document and some discussions in the ML deviate from the charter goal: we need to come up with a practical ____addressing____ architecture. IMHO, we have been discussing instead about "IP over MANET", which to me is a rather different thing (well, to me it doesn't even exist, if we consider L3 MANETs). - Appendix A: "it remains to be determined whether or not the scope of AUTOCONF includes applications other than routing protocols running on the router" --> this is a very important question that we have brought in the meeting. I have my personal opinion, but this is irrelevant, since there seem to be a consensus (I wasn't aware of it, but Thomas stated otherwise). I'd like to ask the chairs to bring this to the ML to close this issue. This is all from my side for the time being. Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-daRAu5DBMas3q3cPkAWT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkr9fvYACgkQNdy6TdFwT2c0QwCfbHDuZ9WReXxvTwrRUXAWCPIi X/IAn2BsUMh5rFZRa8H4VNGaOJr7FI3Y =PSHE -----END PGP SIGNATURE----- --=-daRAu5DBMas3q3cPkAWT-- From alexandru.petrescu@gmail.com Fri Nov 13 12:30:28 2009 Return-Path: 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 76DD93A6783; Fri, 13 Nov 2009 12:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[AWL=0.152, 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 GSU7jG18VPXV; Fri, 13 Nov 2009 12:30:27 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id EC7D73A680A; Fri, 13 Nov 2009 12:30:26 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nADKUtk1032338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 13 Nov 2009 21:30:55 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nADKUttj009791; Fri, 13 Nov 2009 21:30:55 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nADKUsmG023146; Fri, 13 Nov 2009 21:30:55 +0100 Message-ID: <4AFDC1FD.4000108@gmail.com> Date: Fri, 13 Nov 2009 21:30:53 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Zach Shelby References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org> <4AFBE83A.9090408@gmail.com> <25c114b90911120600p28798368x338f10cd2e225072@mail.gmail.com> <4AFC21DA.7030309@gmail.com> <4AFC2ED5.9080101@gmail.com> <3BB19760-A3AF-453F-9177-751D5AA9D5B8@sensinode.com> <4AFC3520.9030208@gmail.com> <8D018E36-6BA3-4616-A527-34D8F4FDE9F2@sensinode.com> <4AFD90D4.80309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [Autoconf] [6lowpan] link-local addresses X-BeenThere: autoconf@ietf.org 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: Fri, 13 Nov 2009 20:30:28 -0000 [frustrated having to post again on AUTOCONF, especially now I don't want to disturb what Carlos has to say in AUTOCONF, but here goes Cc AUTOCONF anyways.] Zach Shelby a écrit : > Alex, > > (added autoconf to CC) > > Now I see what you were concerned about below. Yes I agree, the > wording of how we assign addresses is slightly different. We are > using host-based routes with exact match. As the autoconf document > uses a SHOULD here, 6lowpan-nd can still use a /64 advertised > throughout the LoWPAN to form addresses. It would be nice if autoconf > could update their wording somewhat, so let's see if that is > possible. YEs, let's see. > On Nov 13, 2009, at 19:01 , Alexandru Petrescu wrote: > >> Zach Shelby a écrit : >>> On Nov 12, 2009, at 18:17 , Alexandru Petrescu wrote: >>>>> We do appreciate all the help you gave to polish our model in >>>>> April, thanks for that! >>>> And now you're about to remove the link definitions - thanks >>>> for thanking me. >>> We didn't say that we are going to remove all references to a >>> link. We haven't decided how to use the autoconf model yet. >>> Obviously we would need to build around it. >>>> Additionally to AUTOCONF draft being against the 6lowpan-ND >>>> definition of link, and of its first phrase in the >>>> Bootstrapping section (are you going to remove that too?), >>>> AUTOCONF draft also requires the prefixes to be /128 >>>> exclusively. Are you thus going to require /128 prefixes >>>> exclusively too in the 6lowpan-ND document? >>> As a LoWPAN shares a single prefix, all nodes in a LoWPAN can >>> have is a an address. >> >> YEs - that shared single prefix is a /64 with IPv6 over 802.15.4, >> because that's what rfc4944 suggests. >> >> And yes, each node in a LoWPAN has an address. >> >> Or, AUTOCONF draft-ietf-autoconf-adhoc-addr-model-00 says this: >>> o A subnet prefix configured on this interface should be of >>> length /128. >> >> I think we either have a terminology problem (what's a "subnet >> prefix configured on an interface"?) or a crystalizing incoherency >> between AUTOCONF and 6lowpan-nd. >> >> My suggestion, along the way I understand these WGs landscapes, >> please modify the AUTOCONF document to no longer suggest that /128 >> prefixes assigned to interfaces that way. >> >> If AUTOCONF means "host-based routes" by that "subnet prefix >> configured on an interface should be /128" then AUTOCONF please use >> "host-based routes" instead in the AUTOCONF recommendations. >> >> AUTOCONF please note that 6lowpan-ND document touches briefly on >> these host-based routes aspects when talking "exact match" searches >> in its 6LoWPAN Terminology section, and please don't remove that >> from the 6lowpan-ND document. >> >> The "exact match" method of search in a routing table (as opposed >> to "longest-prefix match") is terminology similar to "Basic Match" >> and "Longest Match" used in rfc1812. Although the rfc is only IPv4 >> it also applies to IPv6. >> >> It is however not quite the same thing. >> >> When you want, we can discuss the definition of "exact match" >> further, as useful to implementer. The 6lowpan-ND definition of >> "exact match" is a good start, IMHO. >> >>> We do not talk about assigning prefixes to nodes in this WG. >> >> YEs, right. >> >> AUTOCONF doesn't talk either: they recommend the assignment of a >> /128 prefix to an _interface_ (not a node). > > I meant interface of course (we usually just have one)... Ok. >> Or, 6lowpan-ND does assign a prefix to an interface when doing the >> IPv6-over-802154 SLAAC stuff. > > Not exactly. We only use the advertised /64 to form the address. > After that we assume everything (except link-local) is off-link. > Therefore we Then you should say so - "off-link". But in 6lowpan-ND draft you mention that "off-link" has no clear meaning on non-transitive links. If "off-link" has no clear meaning, and "on-link" has no meaning either, then we risk big trouble because these terms are heavily used by ND. And you define "non-local". But that word risks coliding with the established "link-local". Another big trouble. Couldn't we just improve that link definition and make it be deterministic (no A-B-C problem and yes multicast support as offered by 802.15.5)? If we did so - then we wouldn't have to say that "off-link" has no clear meaning, and we subsequently wouldn't have to define the terms "non-local"/"local" which risk coliding with the established "link-local". > don't really assign the prefix to the interface. So in practice the > end result is the same as assigning a /128. Right? So this is just a > wording difference. > >> >>> Routers do advertise the prefix used throughout the LoWPAN (using >>> RAs). And nodes may then auto-configure addresses based on that. >>> >> >> YEs, and the auto-configured addresses look like this: >> >> 2001:db8::XXXX:XXXX:XXXX:XXXX/64 >> >> Note the "/64". > > So the autoconf text should say that you can should a /128 or a /64 > when using SLAAC to make that explicitly OK? Well, AUTOCONF should recommend the use of host-based routes if that's their intention. Host-based routes don't break anything if deployed on small scale. An exact-match search in a routing table is easily implementable with current tables and existing "longest-prefix" match searches: just enter "/128" destinations in the destination fields of that table and it works. But AUTOCONF please don't recommend assignment of unique "/128" prefixes on interfaces - that breaks too many things: fe80::/10 is not /128 and worse, it's not unique and its mandatory; using SLAAC with any prefix longer than /64 won't work for IPv6-over-802154 and many other links, and more. If AUTOCONF wants to put a "/128" prefix in an RA L==0 "off-link", then (1) it should acknowledge the link definition of RFC4861 such that "link" makes sense in "off-link" and (2) in no case should it configure that "/128" prefix on any interface (because rfc4861 "off-link" means the address is not assigned to any interface on specified _link_). If AUTOCONF can't agree that "link" is what RFC4861 says it to be, then "off-link" makes no sense, "link-local" makes no sense, and so on. I can't understand "off-link" without first understanding "link". Ignore "link" in any one one paragraph below and you break too many other things: " link - a communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernets (simple or bridged), PPP links, X.25, Frame Relay, or ATM networks as well as Internet-layer (or higher-layer) "tunnels", such as tunnels over IPv4 or IPv6 itself" " Currently, IPv6 continues the IPv4 model in that a subnet prefix is associated with one link." " All interfaces are required to have at least one Link-Local unicast address (see Section 2.8 for additional required addresses)." " off-link - the opposite of "on-link"; an address that is not assigned to any interfaces on the specified link." " The details of forming interface identifiers are defined in the appropriate "IPv6 over " specification, such as "IPv6 over Ethernet" [ETHER], and "IPv6 over FDDI" [FDDI]." " scop is a 4-bit multicast scope value used to limit the scope of the multicast group. The values are as follows: 0 reserved 1 Interface-Local scope 2 Link-Local scope" Or are you about to build a new Internet here in AUTOCONF? Alex From ietf@thomasclausen.org Fri Nov 13 12:42:36 2009 Return-Path: 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 35DE73A6AD0; Fri, 13 Nov 2009 12:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] 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 w1Ryn53-cItv; Fri, 13 Nov 2009 12:42:35 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 03B203A6ACE; Fri, 13 Nov 2009 12:42:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 903EC43060D; Fri, 13 Nov 2009 12:43:05 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (unknown [211.11.148.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 1B7B8430634; Fri, 13 Nov 2009 12:43:03 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Zach Shelby In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 14 Nov 2009 05:43:02 +0900 References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org> <4AFBE83A.9090408@gmail.com> <25c114b90911120600p28798368x338f10cd2e225072@mail.gmail.com> <4AFC21DA.7030309@gmail.com> <4AFC2ED5.9080101@gmail.com> <3BB19760-A3AF-453F-9177-751D5AA9D5B8@sensinode.com> <4AFC3520.9030208@gmail.com> <8D018E36-6BA3-4616-A527-34D8F4FDE9F2@sensinode.com> <4AFD90D4.80309@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [Autoconf] [6lowpan] link-local addresses X-BeenThere: autoconf@ietf.org 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: Fri, 13 Nov 2009 20:42:36 -0000 Zach, Thanks for Cc'ing [autoconf]. We're pleased that the document also is =20= applicable in [6lowpan]. On Nov 14, 2009, at 4:30 AM, Zach Shelby wrote: > Alex, > > (added autoconf to CC) > > Now I see what you were concerned about below. Yes I agree, the =20 > wording of how we assign addresses is slightly different. We are =20 > using host-based routes with exact match. As the autoconf document =20 > uses a SHOULD here, 6lowpan-nd can still use a /64 advertised =20 > throughout the LoWPAN to form addresses. It would be nice if =20 > autoconf could update their wording somewhat, so let's see if that =20 > is possible. One of the comments from [autoconf] this time was to adopt a phrasing =20= of "has no on-link prefix", as suggested by Dave Thaler, Sit tight, I =20= think that an updated I-D should be forthcoming shortly. Zach, if you have any additional comments, please do raise them also =20 on [autoconf]. Thomas > Some comments below. > > On Nov 13, 2009, at 19:01 , Alexandru Petrescu wrote: > >> Zach Shelby a =E9crit : >>> On Nov 12, 2009, at 18:17 , Alexandru Petrescu wrote: >>>>> We do appreciate all the help you gave to polish our model in =20 >>>>> April, thanks for that! >>>> And now you're about to remove the link definitions - thanks for =20= >>>> thanking me. >>> We didn't say that we are going to remove all references to a =20 >>> link. We haven't decided how to use the autoconf model yet. =20 >>> Obviously we would need to build around it. >>>> Additionally to AUTOCONF draft being against the 6lowpan-ND =20 >>>> definition of link, and of its first phrase in the Bootstrapping =20= >>>> section (are you going to remove that too?), AUTOCONF draft also =20= >>>> requires the prefixes to be /128 exclusively. Are you thus going =20= >>>> to require /128 prefixes exclusively too in the 6lowpan-ND =20 >>>> document? >>> As a LoWPAN shares a single prefix, all nodes in a LoWPAN can have =20= >>> is >>> a an address. >> >> YEs - that shared single prefix is a /64 with IPv6 over 802.15.4, >> because that's what rfc4944 suggests. >> >> And yes, each node in a LoWPAN has an address. >> >> Or, AUTOCONF draft-ietf-autoconf-adhoc-addr-model-00 says this: >>> o A subnet prefix configured on this interface should be of =20 >>> length /128. >> >> I think we either have a terminology problem (what's a "subnet prefix >> configured on an interface"?) or a crystalizing incoherency between >> AUTOCONF and 6lowpan-nd. >> >> My suggestion, along the way I understand these WGs landscapes, =20 >> please >> modify the AUTOCONF document to no longer suggest that /128 prefixes >> assigned to interfaces that way. >> >> If AUTOCONF means "host-based routes" by that "subnet prefix =20 >> configured >> on an interface should be /128" then AUTOCONF please use "host-based >> routes" instead in the AUTOCONF recommendations. >> >> AUTOCONF please note that 6lowpan-ND document touches briefly on =20 >> these >> host-based routes aspects when talking "exact match" searches in =20 >> its 6LoWPAN Terminology section, and please don't remove that from =20= >> the 6lowpan-ND document. >> >> The "exact match" method of search in a routing table (as opposed =20 >> to "longest-prefix match") is terminology similar to "Basic Match" =20= >> and "Longest Match" used in rfc1812. Although the rfc is only IPv4 =20= >> it also applies to IPv6. >> >> It is however not quite the same thing. >> >> When you want, we can discuss the definition of "exact match" =20 >> further, as useful to implementer. The 6lowpan-ND definition of =20 >> "exact match" is a good start, IMHO. >> >>> We do not talk about assigning prefixes to nodes in this WG. >> >> YEs, right. >> >> AUTOCONF doesn't talk either: they recommend the assignment of a /128 >> prefix to an _interface_ (not a node). > > I meant interface of course (we usually just have one)... > >> >> Or, 6lowpan-ND does assign a prefix to an interface when doing the >> IPv6-over-802154 SLAAC stuff. > > Not exactly. We only use the advertised /64 to form the address. =20 > After that we assume everything (except link-local) is off-link. =20 > Therefore we don't really assign the prefix to the interface. So in =20= > practice the end result is the same as assigning a /128. Right? So =20 > this is just a wording difference. > >> >>> Routers do advertise the prefix used throughout the LoWPAN (using =20= >>> RAs). And nodes may then auto-configure addresses based on that. >> >> YEs, and the auto-configured addresses look like this: >> >> 2001:db8::XXXX:XXXX:XXXX:XXXX/64 >> >> Note the "/64". > > So the autoconf text should say that you can should a /128 or a /64 =20= > when using SLAAC to make that explicitly OK? > > Zach > >> >> Alex >> >>>> Are you going to modify the 6lowpan-ND bootstrapping because =20 >>>> AUTOCONF draft requires prefixes /128? >>> It already works like this, no changes necessary. As far as I can =20= >>> tell, the autoconf draft requires no functional changes to the =20 >>> base mechanisms of our work. Again, we still need to look at the =20 >>> details. >>> Cheers, Zach >> >> > > --=20 > http://www.sensinode.com > http://zachshelby.org - My blog =93On the Internet of Things=94 > Mobile: +358 40 7796297 > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti, FINLAND > > This e-mail and all attached material are confidential and may =20 > contain legally privileged information. If you are not the intended =20= > recipient, please contact the sender and delete the e-mail from your =20= > system without producing, distributing or retaining copies thereof. > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From zach@sensinode.com Fri Nov 13 11:30:29 2009 Return-Path: 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 C810B3A683E; Fri, 13 Nov 2009 11:30:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 tx2-T-bJfmZq; Fri, 13 Nov 2009 11:30:28 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 5379A3A67E2; Fri, 13 Nov 2009 11:30:27 -0800 (PST) Received: from [192.168.1.5] (line-5076.dyn.kponet.fi [85.29.66.39]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nADJUodW014787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 13 Nov 2009 21:30:51 +0200 Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes From: Zach Shelby In-Reply-To: <4AFD90D4.80309@gmail.com> Date: Fri, 13 Nov 2009 21:30:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org> <4AFBE83A.9090408@gmail.com> <25c114b90911120600p28798368x338f10cd2e225072@mail.gmail.com> <4AFC21DA.7030309@gmail.com> <4AFC2ED5.9080101@gmail.com> <3BB19760-A3AF-453F-9177-751D5AA9D5B8@sensinode.com> <4AFC3520.9030208@gmail.com> <8D018E36-6BA3-4616-A527-34D8F4FDE9F2@sensinode.com> <4AFD90D4.80309@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1076) X-Mailman-Approved-At: Fri, 13 Nov 2009 12:48:16 -0800 Cc: autoconf@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [Autoconf] [6lowpan] link-local addresses X-BeenThere: autoconf@ietf.org 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: Fri, 13 Nov 2009 19:30:29 -0000 Alex, (added autoconf to CC) Now I see what you were concerned about below. Yes I agree, the =20 wording of how we assign addresses is slightly different. We are using =20= host-based routes with exact match. As the autoconf document uses a =20 SHOULD here, 6lowpan-nd can still use a /64 advertised throughout the =20= LoWPAN to form addresses. It would be nice if autoconf could update =20 their wording somewhat, so let's see if that is possible. Some comments below. On Nov 13, 2009, at 19:01 , Alexandru Petrescu wrote: > Zach Shelby a =E9crit : >> On Nov 12, 2009, at 18:17 , Alexandru Petrescu wrote: >>>> We do appreciate all the help you gave to polish our model in =20 >>>> April, thanks for that! >>> And now you're about to remove the link definitions - thanks for =20 >>> thanking me. >> We didn't say that we are going to remove all references to a link. =20= >> We haven't decided how to use the autoconf model yet. Obviously we =20= >> would need to build around it. >>> Additionally to AUTOCONF draft being against the 6lowpan-ND =20 >>> definition of link, and of its first phrase in the Bootstrapping =20 >>> section (are you going to remove that too?), AUTOCONF draft also =20 >>> requires the prefixes to be /128 exclusively. Are you thus going =20= >>> to require /128 prefixes exclusively too in the 6lowpan-ND document? >> As a LoWPAN shares a single prefix, all nodes in a LoWPAN can have is >> a an address. > > YEs - that shared single prefix is a /64 with IPv6 over 802.15.4, > because that's what rfc4944 suggests. > > And yes, each node in a LoWPAN has an address. > > Or, AUTOCONF draft-ietf-autoconf-adhoc-addr-model-00 says this: >> o A subnet prefix configured on this interface should be of =20 >> length /128. > > I think we either have a terminology problem (what's a "subnet prefix > configured on an interface"?) or a crystalizing incoherency between > AUTOCONF and 6lowpan-nd. > > My suggestion, along the way I understand these WGs landscapes, please > modify the AUTOCONF document to no longer suggest that /128 prefixes > assigned to interfaces that way. > > If AUTOCONF means "host-based routes" by that "subnet prefix =20 > configured > on an interface should be /128" then AUTOCONF please use "host-based > routes" instead in the AUTOCONF recommendations. > > AUTOCONF please note that 6lowpan-ND document touches briefly on these > host-based routes aspects when talking "exact match" searches in its =20= > 6LoWPAN Terminology section, and please don't remove that from the =20 > 6lowpan-ND document. > > The "exact match" method of search in a routing table (as opposed to =20= > "longest-prefix match") is terminology similar to "Basic Match" and =20= > "Longest Match" used in rfc1812. Although the rfc is only IPv4 it =20 > also applies to IPv6. > > It is however not quite the same thing. > > When you want, we can discuss the definition of "exact match" =20 > further, as useful to implementer. The 6lowpan-ND definition of =20 > "exact match" is a good start, IMHO. > >> We do not talk about assigning prefixes to nodes in this WG. > > YEs, right. > > AUTOCONF doesn't talk either: they recommend the assignment of a /128 > prefix to an _interface_ (not a node). I meant interface of course (we usually just have one)... > > Or, 6lowpan-ND does assign a prefix to an interface when doing the > IPv6-over-802154 SLAAC stuff. Not exactly. We only use the advertised /64 to form the address. After =20= that we assume everything (except link-local) is off-link. Therefore =20 we don't really assign the prefix to the interface. So in practice the =20= end result is the same as assigning a /128. Right? So this is just a =20 wording difference. > >> Routers do advertise the prefix used throughout the LoWPAN (using =20 >> RAs). And nodes may then auto-configure addresses based on that. > > YEs, and the auto-configured addresses look like this: > > 2001:db8::XXXX:XXXX:XXXX:XXXX/64 > > Note the "/64". So the autoconf text should say that you can should a /128 or a /64 =20 when using SLAAC to make that explicitly OK? Zach > > Alex > >>> Are you going to modify the 6lowpan-ND bootstrapping because =20 >>> AUTOCONF draft requires prefixes /128? >> It already works like this, no changes necessary. As far as I can =20 >> tell, the autoconf draft requires no functional changes to the base =20= >> mechanisms of our work. Again, we still need to look at the details. >> Cheers, Zach > > --=20 http://www.sensinode.com http://zachshelby.org - My blog =93On the Internet of Things=94 Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain =20= legally privileged information. If you are not the intended recipient, =20= please contact the sender and delete the e-mail from your system =20 without producing, distributing or retaining copies thereof. From ietf@thomasclausen.org Fri Nov 13 13:10:09 2009 Return-Path: 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 A1FA03A68B8 for ; Fri, 13 Nov 2009 13:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1] 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 qddsgYa0EsjD for ; Fri, 13 Nov 2009 13:10:08 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 04C733A688B for ; Fri, 13 Nov 2009 13:10:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9BE2443060D; Fri, 13 Nov 2009 13:10:38 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (unknown [211.11.148.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 99209430634; Fri, 13 Nov 2009 13:10:37 -0800 (PST) Message-Id: <6A4751DF-ED0B-4B13-88C6-41FF21D62976@thomasclausen.org> From: Thomas Heide Clausen To: cjbc@it.uc3m.es In-Reply-To: <1258127094.5035.32.camel@acorde.it.uc3m.es> Content-Type: multipart/alternative; boundary=Apple-Mail-42-666561996 Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 14 Nov 2009 06:10:36 +0900 References: <1258127094.5035.32.camel@acorde.it.uc3m.es> X-Mailer: Apple Mail (2.936) Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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: Fri, 13 Nov 2009 21:10:09 -0000 --Apple-Mail-42-666561996 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Carlos, On Nov 14, 2009, at 12:44 AM, Carlos Jes=FAs Bernardos Cano wrote: > Hi, > > In addition to my fundamental concerns that I've with this = document =20 > and > that I've shared in different ways (I can do it again if considered > useful), I have a bunch of other not so fundamental ones: > > - Section 3: "The configuration proposed by this model is =20 > applicable to > any router's IP interface" --> I wonder if this should be changed to > "The configuration proposed by this model is applicable to any =20 > router's > IP MANET interface" or something like that. By saying "any router's IP > interface" it may seem that the configuration of "non-MANET" =20 > interfaces > would also follow the guidelines provided by the document (i.e., /128, > no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state > that the model is for MANET interfaces. The idea is that you actually could configure any IP interface like =20 that - but that it would be silly to do so if one has an interface =20 with "determined connectivity properties". This should be captured in 3: The configuration proposed by this model is applicable to any router's IP interface. It specifies IP addresses and IP subnet prefixes to be configured on network interfaces. When more specific assumptions can be made regarding the =20 connectivity between interfaces, these SHOULD be considered when configuring subnet prefixes. Especially, the last paragraph captures that I think. > - Section 4: "no two such interfaces in the network should be > configured with the same subnet prefix" --> this at least conflicts =20= > with > LLs. (I'm not bringing up __here__ again the LL issue, just pointing =20= > out > that the document should be revised to avoid this kind of =20 > contradictory > statements: "Note that while an IPv6 link-local address is assigned to > each interface as per [RFC4291]" and "no two such interfaces in the > network should be configured with the same subnet prefix". this is a good point. > - Section 6.1: "These limitations are further exacerbated by the > smaller pool of IPv4 link-local addresses to choose from and thus > increased reliance on DAD" --> if link-locals are not considered and > "normal" DAD is not considered suitable for MANETs, I think this > sentence makes no sense and should just simply be removed. I liked Thaler's description of what we needed as ADD (Address =20 Duplication Detection), in order to not confuse with other =20 terminology ;) > > - Section 6.2: "Routers cannot forward any packet with = link-local > source or destination address to other links..." --> this is rather > obvious and not particular of MANETs, why is this described in the > document? This is included as one of the reasons why LLs are of no particular =20 use within a MANET: they can not be used as source IP for a datagram =20 intended to be received by any other interface even within the MANET. > - Section 6.2: "There is no mechanism to ensure that IPv6 = link-local > addresses are unique across multiple links, hence they can not be used > to reliably identify routers." --> this is not particular of MANETs > either, why is in the document? Same reason as above. > - Appendix A: "MANET Link Model" --> I don't believe in the = existence > of a "MANET Link", and I don't see its relevance in an __address > autoconfiguration__ document. Repeating myself here... I think this > document and some discussions in the ML deviate from the charter goal: > we need to come up with a practical ____addressing____ architecture. > IMHO, we have been discussing instead about "IP over MANET", which =20 > to me > is a rather different thing (well, to me it doesn't even exist, if we > consider L3 MANETs). > I think that we agree, this whole appendix is obsolete and should be =20 removed. > - Appendix A: "it remains to be determined whether or not the = scope =20 > of > AUTOCONF includes applications other than routing protocols running on > the router" --> this is a very important question that we have brought > in the meeting. I have my personal opinion, but this is irrelevant, > since there seem to be a consensus (I wasn't aware of it, but Thomas > stated otherwise). Well, I believe that as someone said at the mike, that an addressing =20 model is rather less interesting unless it enables running actual =20 applications. I believe that we had a relatively simple way of putting =20= this discussed at the meting, but we will see shortly (see below). > I'd like to ask the chairs to bring this to the ML to > close this issue. > I believe that was the plan from the [autoconf] meeting to bring a =20 number of things forward. I've gotten the raw notes from our scribes, =20= and will edit those to post meeting minutes on the 'list, then close =20 any issues with everybody being well-informed ;) > This is all from my side for the time being. > Thanks for your time and comments, they're very appreciated. Thomas > Thanks, > > Carlos > > --=20 > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --Apple-Mail-42-666561996 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Carlos,

On = Nov 14, 2009, at 12:44 AM, Carlos Jes=FAs Bernardos Cano wrote:

Hi,

In addition to my fundamental = concerns that I've with this document and
that I've shared in = different ways (I can do it again if considered
useful), I have a = bunch of other not so fundamental ones:

- Section = 3: "The configuration proposed by this model is applicable to
any = router's IP interface" --> I wonder if this should be changed = to
"The configuration proposed by this model is applicable to any = router's
IP MANET interface" or something like that. By saying "any = router's IP
interface" it may seem that the configuration of = "non-MANET" interfaces
would also follow the guidelines provided by = the document (i.e., /128,
no uniqueness ensured for LLs, etc.). I'd = prefer to explicitly state
that the model is for MANET = interfaces.

The idea is that = you actually could configure any IP interface like that - but that it = would be silly to do so if one has an interface with "determined = connectivity properties". This should be captured in = 3:

   The configuration proposed by this model is =
applicable to any
   router's IP interface.  It specifies IP addresses and IP subnet
   prefixes to be configured on network interfaces.

   When more specific assumptions can be made regarding the connectivity
   between interfaces, these SHOULD be considered when configuring
   subnet prefixes.

Especially, = the last paragraph captures that I think.

- Section 4: "no two such = interfaces in the network should be
configured with the same subnet = prefix" --> this at least conflicts with
LLs. (I'm not bringing up = __here__ again the LL issue, just pointing out
that the document = should be revised to avoid this kind of contradictory
statements: = "Note that while an IPv6 link-local address is assigned to
each = interface as per [RFC4291]" and "no two such interfaces in = the
network should be configured with the same subnet = prefix".

this is a good = point.

- Section = 6.1: "These limitations are further exacerbated by the
smaller pool = of IPv4 link-local addresses to choose from and thus
increased = reliance on DAD" --> if link-locals are not considered = and
"normal" DAD is not considered suitable for MANETs, I think = this
sentence makes no sense and should just simply be = removed.


I = liked Thaler's description of what we needed as ADD (Address Duplication = Detection), in order to not confuse with other terminology = ;)



- Section 6.2: "Routers cannot = forward any packet with link-local
source or destination address to = other links..." --> this is rather
obvious and not particular of = MANETs, why is this described in = the
document?

This is included = as one of the reasons why LLs are of no particular use within a MANET: = they can not be used as source IP for a datagram intended to be received = by any other interface even within the MANET.

- Section 6.2: "There is no = mechanism to ensure that IPv6 link-local
addresses are unique across = multiple links, hence they can not be used
to reliably identify = routers." --> this is not particular of MANETs
either, why is in = the document?

Same reason as = above.

- = Appendix A: "MANET Link Model" --> I don't believe in the = existence
of a "MANET Link", and I don't see its relevance in an = __address
autoconfiguration__ document. Repeating myself here... I = think this
document and some discussions in the ML deviate from the = charter goal:
we need to come up with a practical ____addressing____ = architecture.
IMHO, we have been discussing instead about "IP over = MANET", which to me
is a rather different thing (well, to me it = doesn't even exist, if we
consider L3 = MANETs).


I think that we agree, = this whole appendix is obsolete and should be = removed.

- = Appendix A: "it remains to be determined whether or not the scope = of
AUTOCONF includes applications other than routing protocols = running on
the router" --> this is a very important question that = we have brought
in the meeting. I have my personal opinion, but this = is irrelevant,
since there seem to be a consensus (I wasn't aware of = it, but Thomas
stated = otherwise). 

Well, I believe = that as someone said at the mike, that an addressing model is rather = less interesting unless it enables running actual applications. I = believe that we had a relatively simple way of putting this discussed at = the meting, but we will see shortly (see = below).


I'd like = to ask the chairs to bring this to the ML = to
close this = issue.


I believe that was the = plan from the [autoconf] meeting to bring a number of things forward. = I've gotten the raw notes from our scribes, and will edit those to post = meeting minutes on the 'list, then close any issues with everybody being = well-informed ;)


This is all from my side for the = time being.


Thanks for your = time and comments, they're very = appreciated.

Thomas

Thanks,

= Carlos

--
Carlos Jes=FAs Bernardos Cano =     http://www.netcoms.net
GPG FP: = D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 = 4F67
_______________________________________________
Autoconf = mailing list
Autoconf@ietf.org
https://www.iet= f.org/mailman/listinfo/autoconf

= --Apple-Mail-42-666561996-- From charles.perkins@earthlink.net Fri Nov 13 13:40:01 2009 Return-Path: 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 C6FEF3A6830 for ; Fri, 13 Nov 2009 13:40:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 GfbhSAiGf6Zu for ; Fri, 13 Nov 2009 13:40:01 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by core3.amsl.com (Postfix) with ESMTP id 07AEF3A68FB for ; Fri, 13 Nov 2009 13:40:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EyLDj5BSB/o2dsZ0wkjaSoOcu2UN46/ZP2fcAUbBpRxeqyQ8GeHmUPl/4QaPLdZS; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [60.45.238.24] (helo=[10.234.12.188]) by elasmtp-banded.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N93sc-0005mE-9z; Fri, 13 Nov 2009 16:40:30 -0500 Message-ID: <4AFDD24A.5090704@earthlink.net> Date: Fri, 13 Nov 2009 13:40:26 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1258126393.5035.20.camel@acorde.it.uc3m.es> In-Reply-To: <1258126393.5035.20.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f523f23d3653fe40882af67112aafbaee3f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 60.45.238.24 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Fri, 13 Nov 2009 21:40:01 -0000 Hello Carlos, Where is the link on which the link-local is local? Do you want it to be the whole MANET? For any two nodes X and Y, not within range, how does X decide if Y is on-link? Do you require multi-hop signaling for on-link operations? If so, how do you justify forwarding a link-local address? They're not supposed to be forwarded, are they? I'm not saying these questions are impossible to answer. I think they are hard to answer, and that the answers serve only to fragment a solution space that could otherwise usefully be applicable to a much wider class of ad hoc networks. Furthermore, your answer might be quite unlikely to resemble another person's answer. Furthermore, certain popular classes of answers implicitly suppose an unscalable volume of signaling. I really really think there should be a design team to do link-local. Regards, Charlie P. Carlos Jesús Bernardos Cano wrote: > Hi all, > > During the last meeting, it was said several times that even if the > uniqueness of link-local was not an issue, LLs have other problems that > make it reasonable to discourage their use in MANETs. Can anybody please > be so kind of summarising those for me? this is not that obvious to me. > > Thanks in advance. > > Carlos > > > ------------------------------------------------------------------------ > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From charles.perkins@earthlink.net Fri Nov 13 13:48:36 2009 Return-Path: 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 3E62B3A6830 for ; Fri, 13 Nov 2009 13:48:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 SQVZR+IBic9e for ; Fri, 13 Nov 2009 13:48:35 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 48F763A659C for ; Fri, 13 Nov 2009 13:48:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=VGUVcFrhd7hR1faHm9cSs2elWea1Ap8mSekU6jG/GE+vkAAPWhiv82RLLe3Ki4/n; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [60.45.238.24] (helo=[10.234.12.188]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1N940v-0002wv-1A; Fri, 13 Nov 2009 16:49:05 -0500 Message-ID: <4AFDD44F.7080302@earthlink.net> Date: Fri, 13 Nov 2009 13:49:03 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1258127094.5035.32.camel@acorde.it.uc3m.es> In-Reply-To: <1258127094.5035.32.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f522dae38311601352283f27cc9086afa88350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 60.45.238.24 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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: Fri, 13 Nov 2009 21:48:36 -0000 Hello Carlos, An incomplete response: Carlos Jesús Bernardos Cano wrote: > - Section 3: "The configuration proposed by this model is applicable to > any router's IP interface" --> I wonder if this should be changed to > "The configuration proposed by this model is applicable to any router's > IP MANET interface" or something like that. By saying "any router's IP > interface" it may seem that the configuration of "non-MANET" interfaces > would also follow the guidelines provided by the document (i.e., /128, > no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state > that the model is for MANET interfaces. > The point is that you _could_ use the constrained prefix assignment model even for "non-MANET" interfaces. But the constraint would inhibit aggregation which is obviously useful in more non-MANET networks. Nevertheless, except for scalability, networks which COULD have aggregatable addresses would still thereby be made to work without address aggregation. > > - Section 6.2: "Routers cannot forward any packet with link-local > source or destination address to other links..." --> this is rather > obvious and not particular of MANETs, why is this described in the > document? > > - Section 6.2: "There is no mechanism to ensure that IPv6 link-local > addresses are unique across multiple links, hence they can not be used > to reliably identify routers." --> this is not particular of MANETs > either, why is in the document? > I thought the point was to supply justification in case anyone might ask why the prefix constraint was disfavoring the aggregation of addresses into a common link. > - Appendix A: "MANET Link Model" --> I don't believe in the existence > of a "MANET Link", and I don't see its relevance in an __address > autoconfiguration__ document. Repeating myself here... I think this > document and some discussions in the ML deviate from the charter goal: > we need to come up with a practical ____addressing____ architecture. > IMHO, we have been discussing instead about "IP over MANET", which to me > is a rather different thing (well, to me it doesn't even exist, if we > consider L3 MANETs). > This is likely the heart of the problem. A lot of people including me have been running IP over MANET [perforce, layer-3] for years. Then a great deal of controversy has been generated by people who don't believe it can be done. Which seems to suggest that they don't believe the working group is viable in the first place. Regards, Charlie P. From alexandru.petrescu@gmail.com Fri Nov 13 14:24:32 2009 Return-Path: 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 B0CD83A67AE; Fri, 13 Nov 2009 14:24:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=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 2pWO5C7HR4lE; Fri, 13 Nov 2009 14:24:31 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 830023A67AA; Fri, 13 Nov 2009 14:24:28 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 95CA5D480D5; Fri, 13 Nov 2009 23:24:54 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 34CDED480FC; Fri, 13 Nov 2009 23:24:50 +0100 (CET) Message-ID: <4AFDDCAD.8070102@gmail.com> Date: Fri, 13 Nov 2009 23:24:45 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org> <4AFBE83A.9090408@gmail.com> <25c114b90911120600p28798368x338f10cd2e225072@mail.gmail.com> <4AFC21DA.7030309@gmail.com> <4AFC2ED5.9080101@gmail.com> <3BB19760-A3AF-453F-9177-751D5AA9D5B8@sensinode.com> <4AFC3520.9030208@gmail.com> <8D018E36-6BA3-4616-A527-34D8F4FDE9F2@sensinode.com> <4AFD90D4.80309@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091113-1, 13/11/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org, Zach Shelby , 6lowpan <6lowpan@ietf.org> Subject: Re: [Autoconf] [6lowpan] link-local addresses X-BeenThere: autoconf@ietf.org 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: Fri, 13 Nov 2009 22:24:32 -0000 Thomas Heide Clausen a écrit : > Zach, > > Thanks for Cc'ing [autoconf]. We're pleased that the document also is > applicable in [6lowpan]. > > On Nov 14, 2009, at 4:30 AM, Zach Shelby wrote: > >> Alex, >> >> (added autoconf to CC) >> >> Now I see what you were concerned about below. Yes I agree, the >> wording of how we assign addresses is slightly different. We are using >> host-based routes with exact match. As the autoconf document uses a >> SHOULD here, 6lowpan-nd can still use a /64 advertised throughout the >> LoWPAN to form addresses. It would be nice if autoconf could update >> their wording somewhat, so let's see if that is possible. > > One of the comments from [autoconf] this time was to adopt a phrasing of > "has no on-link prefix", as suggested by Dave Thaler, Sit tight, I think > that an updated I-D should be forthcoming shortly. Thomas, Dave - what do you mean by "on-link" prefix? What do you mean by "link"? "on-link" prefix is understood in settings where "link" is understood. Settings where "link" is not understood, "on-link" makes no sense whatsoever, as "off-link" doesn't either. Alex > Zach, if you have any additional comments, please do raise them also on > [autoconf]. > > Thomas > > >> Some comments below. >> >> On Nov 13, 2009, at 19:01 , Alexandru Petrescu wrote: >> >>> Zach Shelby a écrit : >>>> On Nov 12, 2009, at 18:17 , Alexandru Petrescu wrote: >>>>>> We do appreciate all the help you gave to polish our model in >>>>>> April, thanks for that! >>>>> And now you're about to remove the link definitions - thanks for >>>>> thanking me. >>>> We didn't say that we are going to remove all references to a link. >>>> We haven't decided how to use the autoconf model yet. Obviously we >>>> would need to build around it. >>>>> Additionally to AUTOCONF draft being against the 6lowpan-ND >>>>> definition of link, and of its first phrase in the Bootstrapping >>>>> section (are you going to remove that too?), AUTOCONF draft also >>>>> requires the prefixes to be /128 exclusively. Are you thus going >>>>> to require /128 prefixes exclusively too in the 6lowpan-ND document? >>>> As a LoWPAN shares a single prefix, all nodes in a LoWPAN can have is >>>> a an address. >>> >>> YEs - that shared single prefix is a /64 with IPv6 over 802.15.4, >>> because that's what rfc4944 suggests. >>> >>> And yes, each node in a LoWPAN has an address. >>> >>> Or, AUTOCONF draft-ietf-autoconf-adhoc-addr-model-00 says this: >>>> o A subnet prefix configured on this interface should be of length >>>> /128. >>> >>> I think we either have a terminology problem (what's a "subnet prefix >>> configured on an interface"?) or a crystalizing incoherency between >>> AUTOCONF and 6lowpan-nd. >>> >>> My suggestion, along the way I understand these WGs landscapes, please >>> modify the AUTOCONF document to no longer suggest that /128 prefixes >>> assigned to interfaces that way. >>> >>> If AUTOCONF means "host-based routes" by that "subnet prefix configured >>> on an interface should be /128" then AUTOCONF please use "host-based >>> routes" instead in the AUTOCONF recommendations. >>> >>> AUTOCONF please note that 6lowpan-ND document touches briefly on these >>> host-based routes aspects when talking "exact match" searches in its >>> 6LoWPAN Terminology section, and please don't remove that from the >>> 6lowpan-ND document. >>> >>> The "exact match" method of search in a routing table (as opposed to >>> "longest-prefix match") is terminology similar to "Basic Match" and >>> "Longest Match" used in rfc1812. Although the rfc is only IPv4 it >>> also applies to IPv6. >>> >>> It is however not quite the same thing. >>> >>> When you want, we can discuss the definition of "exact match" >>> further, as useful to implementer. The 6lowpan-ND definition of >>> "exact match" is a good start, IMHO. >>> >>>> We do not talk about assigning prefixes to nodes in this WG. >>> >>> YEs, right. >>> >>> AUTOCONF doesn't talk either: they recommend the assignment of a /128 >>> prefix to an _interface_ (not a node). >> >> I meant interface of course (we usually just have one)... >> >>> >>> Or, 6lowpan-ND does assign a prefix to an interface when doing the >>> IPv6-over-802154 SLAAC stuff. >> >> Not exactly. We only use the advertised /64 to form the address. After >> that we assume everything (except link-local) is off-link. Therefore >> we don't really assign the prefix to the interface. So in practice the >> end result is the same as assigning a /128. Right? So this is just a >> wording difference. >> >>> >>>> Routers do advertise the prefix used throughout the LoWPAN (using >>>> RAs). And nodes may then auto-configure addresses based on that. >>> >>> YEs, and the auto-configured addresses look like this: >>> >>> 2001:db8::XXXX:XXXX:XXXX:XXXX/64 >>> >>> Note the "/64". >> >> So the autoconf text should say that you can should a /128 or a /64 >> when using SLAAC to make that explicitly OK? >> >> Zach >> >>> >>> Alex >>> >>>>> Are you going to modify the 6lowpan-ND bootstrapping because >>>>> AUTOCONF draft requires prefixes /128? >>>> It already works like this, no changes necessary. As far as I can >>>> tell, the autoconf draft requires no functional changes to the base >>>> mechanisms of our work. Again, we still need to look at the details. >>>> Cheers, Zach >>> >>> >> >> -- >> http://www.sensinode.com >> http://zachshelby.org - My blog “On the Internet of Things” >> Mobile: +358 40 7796297 >> >> Zach Shelby >> Head of Research >> Sensinode Ltd. >> Kidekuja 2 >> 88610 Vuokatti, FINLAND >> >> This e-mail and all attached material are confidential and may contain >> legally privileged information. If you are not the intended recipient, >> please contact the sender and delete the e-mail from your system >> without producing, distributing or retaining copies thereof. >> >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan > > From ietf@thomasclausen.org Fri Nov 13 14:31:48 2009 Return-Path: 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 34B2B3A67AA; Fri, 13 Nov 2009 14:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1] 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 PrkcB7qWXhJy; Fri, 13 Nov 2009 14:31:46 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id D2CA13A6858; Fri, 13 Nov 2009 14:31:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 7D75F43063E; Fri, 13 Nov 2009 14:32:17 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.190.2] (unknown [211.11.148.2]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 44E1C430628; Fri, 13 Nov 2009 14:32:16 -0800 (PST) Message-Id: <5F24A966-DB24-4CA6-A1FB-33AE64B48899@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4AFDDCAD.8070102@gmail.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 14 Nov 2009 07:32:14 +0900 References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org> <4AFBE83A.9090408@gmail.com> <25c114b90911120600p28798368x338f10cd2e225072@mail.gmail.com> <4AFC21DA.7030309@gmail.com> <4AFC2ED5.9080101@gmail.com> <3BB19760-A3AF-453F-9177-751D5AA9D5B8@sensinode.com> <4AFC3520.9030208@gmail.com> <8D018E36-6BA3-4616-A527-34D8F4FDE9F2@sensinode.com> <4AFD90D4.80309@gmail.com> <4AFDDCAD.8070102@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, Zach Shelby , 6lowpan <6lowpan@ietf.org> Subject: Re: [Autoconf] [6lowpan] link-local addresses X-BeenThere: autoconf@ietf.org 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: Fri, 13 Nov 2009 22:31:48 -0000 On Nov 14, 2009, at 7:24 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> Zach, >> Thanks for Cc'ing [autoconf]. We're pleased that the document also =20= >> is applicable in [6lowpan]. >> On Nov 14, 2009, at 4:30 AM, Zach Shelby wrote: >>> Alex, >>> >>> (added autoconf to CC) >>> >>> Now I see what you were concerned about below. Yes I agree, the =20 >>> wording of how we assign addresses is slightly different. We are =20 >>> using host-based routes with exact match. As the autoconf document =20= >>> uses a SHOULD here, 6lowpan-nd can still use a /64 advertised =20 >>> throughout the LoWPAN to form addresses. It would be nice if =20 >>> autoconf could update their wording somewhat, so let's see if that =20= >>> is possible. >> One of the comments from [autoconf] this time was to adopt a =20 >> phrasing of "has no on-link prefix", as suggested by Dave Thaler, =20 >> Sit tight, I think that an updated I-D should be forthcoming shortly. > > Thomas, Dave - what do you mean by "on-link" prefix? What do you =20 > mean by "link"? > > "on-link" prefix is understood in settings where "link" is =20 > understood. Settings where "link" is not understood, "on-link" makes =20= > no sense whatsoever, as "off-link" doesn't either. > Oh, but it does: it's a prefix which is not configured to be on a link =20= -- which is a good idea as (as you state) the "link is not =20 understood", beyond that we understand it well enough to realize that =20= the connectivity properties are undetermined, and that therefore the =20 use of an on-link prefix is inappropriate. Thomas > Alex > > >> Zach, if you have any additional comments, please do raise them =20 >> also on [autoconf]. >> Thomas >>> Some comments below. >>> >>> On Nov 13, 2009, at 19:01 , Alexandru Petrescu wrote: >>> >>>> Zach Shelby a =E9crit : >>>>> On Nov 12, 2009, at 18:17 , Alexandru Petrescu wrote: >>>>>>> We do appreciate all the help you gave to polish our model in =20= >>>>>>> April, thanks for that! >>>>>> And now you're about to remove the link definitions - thanks =20 >>>>>> for thanking me. >>>>> We didn't say that we are going to remove all references to a =20 >>>>> link. We haven't decided how to use the autoconf model yet. =20 >>>>> Obviously we would need to build around it. >>>>>> Additionally to AUTOCONF draft being against the 6lowpan-ND =20 >>>>>> definition of link, and of its first phrase in the =20 >>>>>> Bootstrapping section (are you going to remove that too?), =20 >>>>>> AUTOCONF draft also requires the prefixes to be /128 =20 >>>>>> exclusively. Are you thus going to require /128 prefixes =20 >>>>>> exclusively too in the 6lowpan-ND document? >>>>> As a LoWPAN shares a single prefix, all nodes in a LoWPAN can =20 >>>>> have is >>>>> a an address. >>>> >>>> YEs - that shared single prefix is a /64 with IPv6 over 802.15.4, >>>> because that's what rfc4944 suggests. >>>> >>>> And yes, each node in a LoWPAN has an address. >>>> >>>> Or, AUTOCONF draft-ietf-autoconf-adhoc-addr-model-00 says this: >>>>> o A subnet prefix configured on this interface should be of =20 >>>>> length /128. >>>> >>>> I think we either have a terminology problem (what's a "subnet =20 >>>> prefix >>>> configured on an interface"?) or a crystalizing incoherency between >>>> AUTOCONF and 6lowpan-nd. >>>> >>>> My suggestion, along the way I understand these WGs landscapes, =20 >>>> please >>>> modify the AUTOCONF document to no longer suggest that /128 =20 >>>> prefixes >>>> assigned to interfaces that way. >>>> >>>> If AUTOCONF means "host-based routes" by that "subnet prefix =20 >>>> configured >>>> on an interface should be /128" then AUTOCONF please use "host-=20 >>>> based >>>> routes" instead in the AUTOCONF recommendations. >>>> >>>> AUTOCONF please note that 6lowpan-ND document touches briefly on =20= >>>> these >>>> host-based routes aspects when talking "exact match" searches in =20= >>>> its 6LoWPAN Terminology section, and please don't remove that =20 >>>> from the 6lowpan-ND document. >>>> >>>> The "exact match" method of search in a routing table (as opposed =20= >>>> to "longest-prefix match") is terminology similar to "Basic =20 >>>> Match" and "Longest Match" used in rfc1812. Although the rfc is =20= >>>> only IPv4 it also applies to IPv6. >>>> >>>> It is however not quite the same thing. >>>> >>>> When you want, we can discuss the definition of "exact match" =20 >>>> further, as useful to implementer. The 6lowpan-ND definition of =20= >>>> "exact match" is a good start, IMHO. >>>> >>>>> We do not talk about assigning prefixes to nodes in this WG. >>>> >>>> YEs, right. >>>> >>>> AUTOCONF doesn't talk either: they recommend the assignment of a /=20= >>>> 128 >>>> prefix to an _interface_ (not a node). >>> >>> I meant interface of course (we usually just have one)... >>> >>>> >>>> Or, 6lowpan-ND does assign a prefix to an interface when doing the >>>> IPv6-over-802154 SLAAC stuff. >>> >>> Not exactly. We only use the advertised /64 to form the address. =20 >>> After that we assume everything (except link-local) is off-link. =20 >>> Therefore we don't really assign the prefix to the interface. So =20 >>> in practice the end result is the same as assigning a /128. Right? =20= >>> So this is just a wording difference. >>> >>>> >>>>> Routers do advertise the prefix used throughout the LoWPAN =20 >>>>> (using RAs). And nodes may then auto-configure addresses based =20 >>>>> on that. >>>> >>>> YEs, and the auto-configured addresses look like this: >>>> >>>> 2001:db8::XXXX:XXXX:XXXX:XXXX/64 >>>> >>>> Note the "/64". >>> >>> So the autoconf text should say that you can should a /128 or a /=20 >>> 64 when using SLAAC to make that explicitly OK? >>> >>> Zach >>> >>>> >>>> Alex >>>> >>>>>> Are you going to modify the 6lowpan-ND bootstrapping because =20 >>>>>> AUTOCONF draft requires prefixes /128? >>>>> It already works like this, no changes necessary. As far as I =20 >>>>> can tell, the autoconf draft requires no functional changes to =20 >>>>> the base mechanisms of our work. Again, we still need to look at =20= >>>>> the details. >>>>> Cheers, Zach >>>> >>>> >>> >>> --=20 >>> http://www.sensinode.com >>> http://zachshelby.org - My blog =93On the Internet of Things=94 >>> Mobile: +358 40 7796297 >>> >>> Zach Shelby >>> Head of Research >>> Sensinode Ltd. >>> Kidekuja 2 >>> 88610 Vuokatti, FINLAND >>> >>> This e-mail and all attached material are confidential and may =20 >>> contain legally privileged information. If you are not the =20 >>> intended recipient, please contact the sender and delete the e-=20 >>> mail from your system without producing, distributing or retaining =20= >>> copies thereof. >>> >>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> 6lowpan@ietf.org >>> https://www.ietf.org/mailman/listinfo/6lowpan > From alexandru.petrescu@gmail.com Fri Nov 13 15:01:13 2009 Return-Path: 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 9ADA13A67AC; Fri, 13 Nov 2009 15:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_23=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 HCASHKnLj6gr; Fri, 13 Nov 2009 15:01:12 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 745563A659C; Fri, 13 Nov 2009 15:01:09 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 0A976D4808A; Sat, 14 Nov 2009 00:01:35 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id C3828D48052; Sat, 14 Nov 2009 00:01:32 +0100 (CET) Message-ID: <4AFDE547.9040101@gmail.com> Date: Sat, 14 Nov 2009 00:01:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <4754A932-3CBD-4E13-9466-96C64D424F56@tzi.org> <4AFBE83A.9090408@gmail.com> <25c114b90911120600p28798368x338f10cd2e225072@mail.gmail.com> <4AFC21DA.7030309@gmail.com> <4AFC2ED5.9080101@gmail.com> <3BB19760-A3AF-453F-9177-751D5AA9D5B8@sensinode.com> <4AFC3520.9030208@gmail.com> <8D018E36-6BA3-4616-A527-34D8F4FDE9F2@sensinode.com> <4AFD90D4.80309@gmail.com> <4AFDDCAD.8070102@gmail.com> <5F24A966-DB24-4CA6-A1FB-33AE64B48899@thomasclausen.org> In-Reply-To: <5F24A966-DB24-4CA6-A1FB-33AE64B48899@thomasclausen.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091113-1, 13/11/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org, Zach Shelby , 6lowpan <6lowpan@ietf.org> Subject: Re: [Autoconf] [6lowpan] link-local addresses X-BeenThere: autoconf@ietf.org 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: Fri, 13 Nov 2009 23:01:13 -0000 Thomas Heide Clausen a écrit : > > On Nov 14, 2009, at 7:24 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> Zach, >>> Thanks for Cc'ing [autoconf]. We're pleased that the document also is >>> applicable in [6lowpan]. >>> On Nov 14, 2009, at 4:30 AM, Zach Shelby wrote: >>>> Alex, >>>> >>>> (added autoconf to CC) >>>> >>>> Now I see what you were concerned about below. Yes I agree, the >>>> wording of how we assign addresses is slightly different. We are >>>> using host-based routes with exact match. As the autoconf document >>>> uses a SHOULD here, 6lowpan-nd can still use a /64 advertised >>>> throughout the LoWPAN to form addresses. It would be nice if >>>> autoconf could update their wording somewhat, so let's see if that >>>> is possible. >>> One of the comments from [autoconf] this time was to adopt a phrasing >>> of "has no on-link prefix", as suggested by Dave Thaler, Sit tight, I >>> think that an updated I-D should be forthcoming shortly. >> >> Thomas, Dave - what do you mean by "on-link" prefix? What do you mean >> by "link"? >> >> "on-link" prefix is understood in settings where "link" is understood. >> Settings where "link" is not understood, "on-link" makes no sense >> whatsoever, as "off-link" doesn't either. >> > > Oh, but it does: it's a prefix which is not configured to be on a link On a "link" as rfc4861 understands it? Or on a "link" which has ABC problem? Is it correct to say AUTOCONF prefix is not configured on a "link having A-B-C problem"? Or is it more correct to say that AUTOCONF prefix is not configured on a "link which does not have the A-B-C problem"? Both are correct? > -- which is a good idea as (as you state) the "link is not understood", > beyond that we understand it well enough to realize that the > connectivity properties are undetermined, and that therefore the use of > an on-link prefix is inappropriate. So you say on-link prefix is inappropriate on links we don't understand. It doesn't imply off-link prefix is appropriate on such links. BEcause "off-link" is already defined: "an address that is not assigned to any interfaces on the specified link", i.e. a link which is understood. If the link is not understood then we can't say whether somethhing is on it or off it. It may be on it, and also off it. Alex > > Thomas > >> Alex >> >> >>> Zach, if you have any additional comments, please do raise them also >>> on [autoconf]. >>> Thomas >>>> Some comments below. >>>> >>>> On Nov 13, 2009, at 19:01 , Alexandru Petrescu wrote: >>>> >>>>> Zach Shelby a écrit : >>>>>> On Nov 12, 2009, at 18:17 , Alexandru Petrescu wrote: >>>>>>>> We do appreciate all the help you gave to polish our model in >>>>>>>> April, thanks for that! >>>>>>> And now you're about to remove the link definitions - thanks for >>>>>>> thanking me. >>>>>> We didn't say that we are going to remove all references to a >>>>>> link. We haven't decided how to use the autoconf model yet. >>>>>> Obviously we would need to build around it. >>>>>>> Additionally to AUTOCONF draft being against the 6lowpan-ND >>>>>>> definition of link, and of its first phrase in the Bootstrapping >>>>>>> section (are you going to remove that too?), AUTOCONF draft also >>>>>>> requires the prefixes to be /128 exclusively. Are you thus going >>>>>>> to require /128 prefixes exclusively too in the 6lowpan-ND document? >>>>>> As a LoWPAN shares a single prefix, all nodes in a LoWPAN can have is >>>>>> a an address. >>>>> >>>>> YEs - that shared single prefix is a /64 with IPv6 over 802.15.4, >>>>> because that's what rfc4944 suggests. >>>>> >>>>> And yes, each node in a LoWPAN has an address. >>>>> >>>>> Or, AUTOCONF draft-ietf-autoconf-adhoc-addr-model-00 says this: >>>>>> o A subnet prefix configured on this interface should be of >>>>>> length /128. >>>>> >>>>> I think we either have a terminology problem (what's a "subnet prefix >>>>> configured on an interface"?) or a crystalizing incoherency between >>>>> AUTOCONF and 6lowpan-nd. >>>>> >>>>> My suggestion, along the way I understand these WGs landscapes, please >>>>> modify the AUTOCONF document to no longer suggest that /128 prefixes >>>>> assigned to interfaces that way. >>>>> >>>>> If AUTOCONF means "host-based routes" by that "subnet prefix >>>>> configured >>>>> on an interface should be /128" then AUTOCONF please use "host-based >>>>> routes" instead in the AUTOCONF recommendations. >>>>> >>>>> AUTOCONF please note that 6lowpan-ND document touches briefly on these >>>>> host-based routes aspects when talking "exact match" searches in >>>>> its 6LoWPAN Terminology section, and please don't remove that from >>>>> the 6lowpan-ND document. >>>>> >>>>> The "exact match" method of search in a routing table (as opposed >>>>> to "longest-prefix match") is terminology similar to "Basic Match" >>>>> and "Longest Match" used in rfc1812. Although the rfc is only IPv4 >>>>> it also applies to IPv6. >>>>> >>>>> It is however not quite the same thing. >>>>> >>>>> When you want, we can discuss the definition of "exact match" >>>>> further, as useful to implementer. The 6lowpan-ND definition of >>>>> "exact match" is a good start, IMHO. >>>>> >>>>>> We do not talk about assigning prefixes to nodes in this WG. >>>>> >>>>> YEs, right. >>>>> >>>>> AUTOCONF doesn't talk either: they recommend the assignment of a /128 >>>>> prefix to an _interface_ (not a node). >>>> >>>> I meant interface of course (we usually just have one)... >>>> >>>>> >>>>> Or, 6lowpan-ND does assign a prefix to an interface when doing the >>>>> IPv6-over-802154 SLAAC stuff. >>>> >>>> Not exactly. We only use the advertised /64 to form the address. >>>> After that we assume everything (except link-local) is off-link. >>>> Therefore we don't really assign the prefix to the interface. So in >>>> practice the end result is the same as assigning a /128. Right? So >>>> this is just a wording difference. >>>> >>>>> >>>>>> Routers do advertise the prefix used throughout the LoWPAN (using >>>>>> RAs). And nodes may then auto-configure addresses based on that. >>>>> >>>>> YEs, and the auto-configured addresses look like this: >>>>> >>>>> 2001:db8::XXXX:XXXX:XXXX:XXXX/64 >>>>> >>>>> Note the "/64". >>>> >>>> So the autoconf text should say that you can should a /128 or a /64 >>>> when using SLAAC to make that explicitly OK? >>>> >>>> Zach >>>> >>>>> >>>>> Alex >>>>> >>>>>>> Are you going to modify the 6lowpan-ND bootstrapping because >>>>>>> AUTOCONF draft requires prefixes /128? >>>>>> It already works like this, no changes necessary. As far as I can >>>>>> tell, the autoconf draft requires no functional changes to the >>>>>> base mechanisms of our work. Again, we still need to look at the >>>>>> details. >>>>>> Cheers, Zach >>>>> >>>>> >>>> >>>> -- >>>> http://www.sensinode.com >>>> http://zachshelby.org - My blog “On the Internet of Things” >>>> Mobile: +358 40 7796297 >>>> >>>> Zach Shelby >>>> Head of Research >>>> Sensinode Ltd. >>>> Kidekuja 2 >>>> 88610 Vuokatti, FINLAND >>>> >>>> This e-mail and all attached material are confidential and may >>>> contain legally privileged information. If you are not the intended >>>> recipient, please contact the sender and delete the e-mail from your >>>> system without producing, distributing or retaining copies thereof. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 6lowpan mailing list >>>> 6lowpan@ietf.org >>>> https://www.ietf.org/mailman/listinfo/6lowpan >> > > From alexandru.petrescu@gmail.com Fri Nov 13 16:15:22 2009 Return-Path: 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 2D7FD3A6814 for ; Fri, 13 Nov 2009 16:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[AWL=0.271, 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 Etvi-MdpYb9l for ; Fri, 13 Nov 2009 16:15:21 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 23E0E3A67B8 for ; Fri, 13 Nov 2009 16:15:19 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 59EA5D4801C; Sat, 14 Nov 2009 01:15:45 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 30AE7D4802A; Sat, 14 Nov 2009 01:15:43 +0100 (CET) Message-ID: <4AFDF6AA.7020102@gmail.com> Date: Sat, 14 Nov 2009 01:15:38 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <4AFDD44F.7080302@earthlink.net> In-Reply-To: <4AFDD44F.7080302@earthlink.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091113-1, 13/11/2009), Outbound message X-Antivirus-Status: Clean Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] confidence , controversy and running MANET for years (was: Comments on draft-ietf-autoconf-adhoc-addr-model-00) X-BeenThere: autoconf@ietf.org 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: Sat, 14 Nov 2009 00:15:22 -0000 This is not generating controversy, this is clarification. Charles E. Perkins a écrit : [...] >> - Appendix A: "MANET Link Model" --> I don't believe in the >> existence of a "MANET Link", and I don't see its relevance in an >> __address autoconfiguration__ document. Repeating myself here... I >> think this document and some discussions in the ML deviate from >> the charter goal: we need to come up with a practical >> ____addressing____ architecture. IMHO, we have been discussing >> instead about "IP over MANET", which to me is a rather different >> thing (well, to me it doesn't even exist, if we consider L3 >> MANETs). >> > > This is likely the heart of the problem. A lot of people including > me have been running IP over MANET [perforce, layer-3] for years. > Then a great deal of controversy has been generated by people who > don't believe it can be done. Which seems to suggest that they don't > believe the working group is viable in the first place. Charles, I do believe IP can run on highly dynamic network topologies. I trust you when you and Thomas say you did it. Just say precisely how you did it. For example, state when the experience was with IPv4 (not IPv6) and don't make extrapolations from one to another. Wireless link problems - yes, then state at least which link technology. Host-based routes? YEs, say it so, say how many nodes in the network, say the number of entries in the routing tables and the prefixlen of the destination field of each entry ("128"); but don't make it into a recommendation of unique "/128" off-link prefix which makes no 4861ish sense to me. Your implementation didn't use IPv6 link-local addresses? Ok, but don't make that a prefered case recommendation. State how DAD was there but overlooked. Is DAD consuming too much bandwidth? How much? State how MLD and MDNS were there too and overlooked. Were _some_ addresses manually configured? - if yes say it so. Was there a topology? Picture it. Were there addresses on interfaces? Were there some entries in some routing table entries? Some connected routes? Were there some default routes? Some ICMP Redirects? They're paramount importance. Some virtual interface? Now - are all and each of these things consensual between people having had MANET experience? I don't believe so. It seems to me it is not a matter of having had the right or wrong experience, just report as it was, and don't claim it to be consensual. We know it is not consensus. I have seen the same statements of having run MANET for years by people with _very_ different oppinions about _how_ these MANETs should run. Just don't make these sound as a consensual recommendation, as the document currently does - they break other things. And don't export these recommendations (avoid LLs, use unique "/128" off-link prefixes) to other WGs, they make no sense there - their current documents already fall outside the core of your recommendations. (when I write "you" it's about the AUTOCONF practical addressing model draft authorship). Alex > > > Regards, Charlie P. > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www.ietf.org/mailman/listinfo/autoconf > From teco@inf-net.nl Sun Nov 15 02:34:46 2009 Return-Path: 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 1A4C53A6917 for ; Sun, 15 Nov 2009 02:34:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, J_CHICKENPOX_45=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 MfNGtXTgX0vk for ; Sun, 15 Nov 2009 02:34:45 -0800 (PST) Received: from CPSMTPM-EML109.kpnxchange.com (Cpsmtpm-eml109.kpnxchange.com [195.121.3.13]) by core3.amsl.com (Postfix) with ESMTP id C93FB3A67DF for ; Sun, 15 Nov 2009 02:34:44 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML109.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sun, 15 Nov 2009 11:35:15 +0100 From: "Teco Boot" To: "'Charles E. Perkins'" , References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4AFDD24A.5090704@earthlink.net> In-Reply-To: <4AFDD24A.5090704@earthlink.net> Date: Sun, 15 Nov 2009 19:35:14 +0900 Message-ID: <006901ca65df$513a5450$f3aefcf0$@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: Acpkqe9ES90bImKTRC+hCFNm62XniQBNDXuw Content-Language: nl X-OriginalArrivalTime: 15 Nov 2009 10:35:15.0299 (UTC) FILETIME=[5180D330:01CA65DF] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Sun, 15 Nov 2009 10:34:46 -0000 I posted LL text for the draft, with explanation of the LL problem. http://www.ietf.org/mail-archive/web/autoconf/current/msg01828.html Here another copy: Routers cannot forward any packets with link-local source or destination addresses to other links (as per [RFC4291]). In general, routers do not forward such packets. This would limit connectivity between MANET nodes. For this reason, link-local addresses shall be=20 used only for protocols that require one-hop limited delivery of = packets. This is the only argument on not using LLs that withstands any = criticism. Even Alex can agree on this text. Alex? Teco. >-----Oorspronkelijk bericht----- >Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] = Namens >Charles E. Perkins >Verzonden: zaterdag 14 november 2009 6:40 >Aan: cjbc@it.uc3m.es >CC: autoconf@ietf.org >Onderwerp: Re: [Autoconf] Question regarding use of LLs > > >Hello Carlos, > >Where is the link on which the link-local is local? >Do you want it to be the whole MANET? For any >two nodes X and Y, not within range, how does >X decide if Y is on-link? Do you require multi-hop >signaling for on-link operations? If so, how do you >justify forwarding a link-local address? They're >not supposed to be forwarded, are they? > >I'm not saying these questions are impossible to >answer. I think they are hard to answer, and that >the answers serve only to fragment a solution space >that could otherwise usefully be applicable to a much>wider class of ad = hoc networks. Furthermore, your >answer might be quite unlikely to resemble another >person's answer. Furthermore, certain popular >classes of answers implicitly suppose an unscalable >volume of signaling. > >I really really think there should be a design team >to do link-local. > >Regards, >Charlie P. > > >Carlos Jes=FAs Bernardos Cano wrote: >> Hi all, >> >> During the last meeting, it was said several times that even if >the >> uniqueness of link-local was not an issue, LLs have other problems >that >> make it reasonable to discourage their use in MANETs. Can anybody >please >> be so kind of summarising those for me? this is not that obvious to >me. >> >> Thanks in advance. >> >> Carlos >> >> >> = ---------------------------------------------------------------------- >-- >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > >_______________________________________________ >Autoconf mailing list >Autoconf@ietf.org >https://www.ietf.org/mailman/listinfo/autoconf From teco@inf-net.nl Sun Nov 15 02:55:12 2009 Return-Path: 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 8510D3A6905 for ; Sun, 15 Nov 2009 02:55:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599] 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 TlN91w84-sz9 for ; Sun, 15 Nov 2009 02:55:11 -0800 (PST) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id 1AD803A67AC for ; Sun, 15 Nov 2009 02:55:10 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Sun, 15 Nov 2009 11:55:41 +0100 From: "Teco Boot" To: , References: <1258127094.5035.32.camel@acorde.it.uc3m.es> In-Reply-To: <1258127094.5035.32.camel@acorde.it.uc3m.es> Date: Sun, 15 Nov 2009 19:55:40 +0900 Message-ID: <006a01ca65e2$2bdc1ba0$839452e0$@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: AcpkgK+1Ak6nkB1RSfaVLfbfuIlZRwBXsAdw Content-Language: nl X-OriginalArrivalTime: 15 Nov 2009 10:55:41.0728 (UTC) FILETIME=[2C830A00:01CA65E2] Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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: Sun, 15 Nov 2009 10:55:12 -0000 Carlos Jes=FAs Bernardos Cano wrote: > - Section 3: "The configuration proposed by this model is >applicable to >any router's IP interface" --> I wonder if this should be changed to >"The configuration proposed by this model is applicable to any router's >IP MANET interface" or something like that. By saying "any router's IP >interface" it may seem that the configuration of "non-MANET" interfaces >would also follow the guidelines provided by the document (i.e., /128, >no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state >that the model is for MANET interfaces. Somewhat agreed. The problem is wording: what is MANET interface? I say: interface with MANET protocol running. Then your suggestion is also not completely correct. Interface to Wireless Link? Also not completely correct, as there are many wireless links that do not=20 have problems with on-link prefixes. > - Section 4: "no two such interfaces in the network should be >configured with the same subnet prefix" --> this at least conflicts = with >LLs. (I'm not bringing up __here__ again the LL issue, just pointing = out >that the document should be revised to avoid this kind of contradictory >statements: "Note that while an IPv6 link-local address is assigned to >each interface as per [RFC4291]" and "no two such interfaces in the >network should be configured with the same subnet prefix". Agreed. > - Section 6.1: "These limitations are further exacerbated by the >smaller pool of IPv4 link-local addresses to choose from and thus >increased reliance on DAD" --> if link-locals are not considered and >"normal" DAD is not considered suitable for MANETs, I think this >sentence makes no sense and should just simply be removed. Yes, we should remove all references to DAD. It is to controversial. > - Section 6.2: "Routers cannot forward any packet with link-local >source or destination address to other links..." --> this is rather >obvious and not particular of MANETs, why is this described in the >document? See my other posting. This is an important argument, as in the normal case the link is expected to be somewhat stable, and there is an interface down trigger to signal the link down. On xxx interfaces, there is no such a trigger. And when nodes get out of range, connections using LLs are affected while connections with non-LLs are not. > - Section 6.2: "There is no mechanism to ensure that IPv6 link- >local >addresses are unique across multiple links, hence they can not be used >to reliably identify routers." --> this is not particular of MANETs >either, why is in the document? We should remove this argument. > - Appendix A: "MANET Link Model" --> I don't believe in the >existence >of a "MANET Link", and I don't see its relevance in an __address >autoconfiguration__ document. Repeating myself here... I think this >document and some discussions in the ML deviate from the charter goal: >we need to come up with a practical ____addressing____ architecture. >IMHO, we have been discussing instead about "IP over MANET", which to = me >is a rather different thing (well, to me it doesn't even exist, if we >consider L3 MANETs). With having the draft-baccelli-autoconf-adhoc-addr-model, we can close this issue. > - Appendix A: "it remains to be determined whether or not the >scope of >AUTOCONF includes applications other than routing protocols running on >the router" --> this is a very important question that we have brought >in the meeting. I have my personal opinion, but this is irrelevant, >since there seem to be a consensus (I wasn't aware of it, but Thomas >stated otherwise). I'd like to ask the chairs to bring this to the ML = to >close this issue. I think the consensus is that there are applications in a MANET. The = MANET=20 is not solely for running MANET protocols... . It is also in the charter: It is required that such models do not cause problems for ad hoc-unaware parts of the system, such as standard applications running on an ad hoc node or regular Internet nodes attached to the ad hoc nodes. Teco. From cjbc@it.uc3m.es Sun Nov 15 23:24:00 2009 Return-Path: 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 715C228C0CE for ; Sun, 15 Nov 2009 23:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.84 X-Spam-Level: X-Spam-Status: No, score=-3.84 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 LKgEJhA+EZHM for ; Sun, 15 Nov 2009 23:23:59 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 14DE53A6A86 for ; Sun, 15 Nov 2009 23:23:58 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id AC53373C702; Mon, 16 Nov 2009 08:23:56 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4AFDD24A.5090704@earthlink.net> References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4AFDD24A.5090704@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ue8ei+FSIirGMKFMzKDl" Organization: Universidad Carlos III de Madrid Date: Mon, 16 Nov 2009 08:23:57 +0100 Message-Id: <1258356237.7116.16.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 07:24:00 -0000 --=-ue8ei+FSIirGMKFMzKDl Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Charlie, On Fri, 2009-11-13 at 13:40 -0800, Charles E. Perkins wrote: > Hello Carlos, >=20 > Where is the link on which the link-local is local? The link is defined by the topological area within a packet with an IPv4 TTL or IPv6 Hop Limit of 1 can be delivered. The area is given by the radio-range coverage of the wireless technology used. > Do you want it to be the whole MANET? For any No, I don't. > two nodes X and Y, not within range, how does > X decide if Y is on-link? Do you require multi-hop > signaling for on-link operations? If so, how do you No, I don't. A link is single-hop. > justify forwarding a link-local address? They're > not supposed to be forwarded, are they? No, link-locals are not forwarded. I think I've already said this, I don't want to change the semantics of link-locals, I just want to be able to keep using them in MANETs. >=20 > I'm not saying these questions are impossible to > answer. I think they are hard to answer, and that well, for me the answers are pretty straightforward :-D > the answers serve only to fragment a solution space > that could otherwise usefully be applicable to a much > wider class of ad hoc networks. Furthermore, your > answer might be quite unlikely to resemble another > person's answer. Furthermore, certain popular This I agree. > classes of answers implicitly suppose an unscalable > volume of signaling. Well, this is solution space and I tend to disagree. Thanks, Carlos >=20 > I really really think there should be a design team > to do link-local. >=20 > Regards, > Charlie P. >=20 >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > Hi all, > > > > During the last meeting, it was said several times that even if the > > uniqueness of link-local was not an issue, LLs have other problems that > > make it reasonable to discourage their use in MANETs. Can anybody pleas= e > > be so kind of summarising those for me? this is not that obvious to me. > > > > Thanks in advance. > > > > Carlos > > > > =20 > > -----------------------------------------------------------------------= - > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > > =20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-ue8ei+FSIirGMKFMzKDl Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksA/g0ACgkQNdy6TdFwT2fZxQCbBdZIZ2uMPw186PuCzhQ3ZyK7 gCQAn0Sq9BKd4otdSTG2OSM9/6oI+ITz =lXzA -----END PGP SIGNATURE----- --=-ue8ei+FSIirGMKFMzKDl-- From cjbc@it.uc3m.es Sun Nov 15 23:31:51 2009 Return-Path: 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 A137B3A6893 for ; Sun, 15 Nov 2009 23:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.77 X-Spam-Level: X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 CgNHDyWGfkAp for ; Sun, 15 Nov 2009 23:31:50 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id 11FBA3A6806 for ; Sun, 15 Nov 2009 23:31:49 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id A60F7BA4ECC; Mon, 16 Nov 2009 08:31:47 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Thomas Heide Clausen In-Reply-To: <6A4751DF-ED0B-4B13-88C6-41FF21D62976@thomasclausen.org> References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <6A4751DF-ED0B-4B13-88C6-41FF21D62976@thomasclausen.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-AKwEQM49aHSCgYzXfCiq" Organization: Universidad Carlos III de Madrid Date: Mon, 16 Nov 2009 08:31:48 +0100 Message-Id: <1258356708.7116.23.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 07:31:51 -0000 --=-AKwEQM49aHSCgYzXfCiq Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Thomas, On Sat, 2009-11-14 at 06:10 +0900, Thomas Heide Clausen wrote: > Carlos, >=20 > On Nov 14, 2009, at 12:44 AM, Carlos Jes=FAs Bernardos Cano wrote: >=20 > > Hi, > >=20 > > In addition to my fundamental concerns that I've with this document > > and > > that I've shared in different ways (I can do it again if considered > > useful), I have a bunch of other not so fundamental ones: > >=20 > > - Section 3: "The configuration proposed by this model is applicable > > to > > any router's IP interface" --> I wonder if this should be changed to > > "The configuration proposed by this model is applicable to any > > router's > > IP MANET interface" or something like that. By saying "any router's > > IP > > interface" it may seem that the configuration of "non-MANET" > > interfaces > > would also follow the guidelines provided by the document > > (i.e., /128, > > no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state > > that the model is for MANET interfaces. > >=20 >=20 >=20 > The idea is that you actually could configure any IP interface like > that - but that it would be silly to do so if one has an interface > with "determined connectivity properties". This should be captured in > 3: >=20 >=20 > The configuration proposed by this model is applicable to any > router's IP interface. It specifies IP addresses and IP subnet > prefixes to be configured on network interfaces. >=20 > When more specific assumptions can be made regarding the connectivity > between interfaces, these SHOULD be considered when configuring > subnet prefixes. >=20 >=20 > Especially, the last paragraph captures that I think. My point is that since some of the recommendations provided by the document may imply modifications to standard protocols (such as "discourage LLs --> modify/not use ND), doing this on regular interfaces may affect regular hosts, and this is not allowed by the charter. I'd prefer a different writing so autoconf addressing model refers only to MANET interfaces (I know this term is not used in the document...). >=20 > > - Section 4: "no two such interfaces in the network should be > > configured with the same subnet prefix" --> this at least conflicts > > with > > LLs. (I'm not bringing up __here__ again the LL issue, just pointing > > out > > that the document should be revised to avoid this kind of > > contradictory > > statements: "Note that while an IPv6 link-local address is assigned > > to > > each interface as per [RFC4291]" and "no two such interfaces in the > > network should be configured with the same subnet prefix". > >=20 >=20 >=20 > this is a good point. >=20 > > - Section 6.1: "These limitations are further exacerbated by the > > smaller pool of IPv4 link-local addresses to choose from and thus > > increased reliance on DAD" --> if link-locals are not considered and > > "normal" DAD is not considered suitable for MANETs, I think this > > sentence makes no sense and should just simply be removed. > >=20 >=20 >=20 >=20 >=20 > I liked Thaler's description of what we needed as ADD (Address > Duplication Detection), in order to not confuse with other > terminology ;) >=20 >=20 Fine, there have been also other terms proposed in the past. Whatever that makes the text clearer. >=20 >=20 > >=20 > > - Section 6.2: "Routers cannot forward any packet with link-local > > source or destination address to other links..." --> this is rather > > obvious and not particular of MANETs, why is this described in the > > document? > >=20 >=20 >=20 > This is included as one of the reasons why LLs are of no particular > use within a MANET: they can not be used as source IP for a datagram > intended to be received by any other interface even within the MANET. This is true for any kind of network. I don't see the value of that text. Nobody is asking, AFAIK, to change the LL semantics (well, but maybe those that discourage their use :-p). >=20 > > - Section 6.2: "There is no mechanism to ensure that IPv6 link-local > > addresses are unique across multiple links, hence they can not be > > used > > to reliably identify routers." --> this is not particular of MANETs > > either, why is in the document? > >=20 >=20 >=20 > Same reason as above. Some comment as above. >=20 > > - Appendix A: "MANET Link Model" --> I don't believe in the > > existence > > of a "MANET Link", and I don't see its relevance in an __address > > autoconfiguration__ document. Repeating myself here... I think this > > document and some discussions in the ML deviate from the charter > > goal: > > we need to come up with a practical ____addressing____ architecture. > > IMHO, we have been discussing instead about "IP over MANET", which > > to me > > is a rather different thing (well, to me it doesn't even exist, if > > we > > consider L3 MANETs). > >=20 > >=20 >=20 >=20 > I think that we agree, this whole appendix is obsolete and should be > removed. OK. >=20 > > - Appendix A: "it remains to be determined whether or not the scope > > of > > AUTOCONF includes applications other than routing protocols running > > on > > the router" --> this is a very important question that we have > > brought > > in the meeting. I have my personal opinion, but this is irrelevant, > > since there seem to be a consensus (I wasn't aware of it, but Thomas > > stated otherwise).=20 >=20 >=20 > Well, I believe that as someone said at the mike, that an addressing > model is rather less interesting unless it enables running actual > applications. I believe that we had a relatively simple way of putting > this discussed at the meting, but we will see shortly (see below). >=20 >=20 >=20 > > I'd like to ask the chairs to bring this to the ML to > > close this issue. > >=20 > >=20 >=20 >=20 > I believe that was the plan from the [autoconf] meeting to bring a > number of things forward. I've gotten the raw notes from our scribes, > and will edit those to post meeting minutes on the 'list, then close > any issues with everybody being well-informed ;) Good. Thanks, Carlos >=20 >=20 >=20 > > This is all from my side for the time being. > >=20 > >=20 >=20 >=20 > Thanks for your time and comments, they're very appreciated. >=20 >=20 > Thomas >=20 > > Thanks, > >=20 > > Carlos > >=20 > > --=20 > > Carlos Jes=FAs Bernardos Cano http://www.netcoms.net > > GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > >=20 >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-AKwEQM49aHSCgYzXfCiq Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksA/+QACgkQNdy6TdFwT2dLPgCfTPHfEPoqqHUGt0KpelahnXDX hCIAoM4GEbQqJGSrHlvbdNip4/JthKVY =/Vap -----END PGP SIGNATURE----- --=-AKwEQM49aHSCgYzXfCiq-- From cjbc@it.uc3m.es Sun Nov 15 23:36:12 2009 Return-Path: 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 8503F3A6A91 for ; Sun, 15 Nov 2009 23:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.234 X-Spam-Level: X-Spam-Status: No, score=-5.234 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 Jc3mpBkKvFSL for ; Sun, 15 Nov 2009 23:36:08 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A58153A6925 for ; Sun, 15 Nov 2009 23:36:07 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 62C5DBA5235; Mon, 16 Nov 2009 08:36:05 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <006a01ca65e2$2bdc1ba0$839452e0$@nl> References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <006a01ca65e2$2bdc1ba0$839452e0$@nl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-XGU3yCdD3c4mR3zghRzO" Organization: Universidad Carlos III de Madrid Date: Mon, 16 Nov 2009 08:36:05 +0100 Message-Id: <1258356965.7116.27.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 07:36:12 -0000 --=-XGU3yCdD3c4mR3zghRzO Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Teco, On Sun, 2009-11-15 at 19:55 +0900, Teco Boot wrote: > Carlos Jes=FAs Bernardos Cano wrote: >=20 > > - Section 3: "The configuration proposed by this model is > >applicable to > >any router's IP interface" --> I wonder if this should be changed to > >"The configuration proposed by this model is applicable to any router's > >IP MANET interface" or something like that. By saying "any router's IP > >interface" it may seem that the configuration of "non-MANET" interfaces > >would also follow the guidelines provided by the document (i.e., /128, > >no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state > >that the model is for MANET interfaces. >=20 > Somewhat agreed. The problem is wording: what is MANET interface? > I say: interface with MANET protocol running. Then your suggestion I agree with that definition. It is actually the one we used in our draft. > is also not completely correct. Interface to Wireless Link? Also Why is it not correct? > not completely correct, as there are many wireless links that do not=20 > have problems with on-link prefixes. >=20 >=20 > > - Section 4: "no two such interfaces in the network should be > >configured with the same subnet prefix" --> this at least conflicts with > >LLs. (I'm not bringing up __here__ again the LL issue, just pointing out > >that the document should be revised to avoid this kind of contradictory > >statements: "Note that while an IPv6 link-local address is assigned to > >each interface as per [RFC4291]" and "no two such interfaces in the > >network should be configured with the same subnet prefix". >=20 > Agreed. >=20 >=20 > > - Section 6.1: "These limitations are further exacerbated by the > >smaller pool of IPv4 link-local addresses to choose from and thus > >increased reliance on DAD" --> if link-locals are not considered and > >"normal" DAD is not considered suitable for MANETs, I think this > >sentence makes no sense and should just simply be removed. >=20 > Yes, we should remove all references to DAD. It is to controversial. >=20 >=20 > > - Section 6.2: "Routers cannot forward any packet with link-local > >source or destination address to other links..." --> this is rather > >obvious and not particular of MANETs, why is this described in the > >document? >=20 > See my other posting. This is an important argument, as in the normal > case the link is expected to be somewhat stable, and there is an > interface down trigger to signal the link down. On xxx interfaces, Protocols should be designed to work without such triggers (actually there are many cases win which these triggers are not available, even in wired networks). > there is no such a trigger. And when nodes get out of range, > connections using LLs are affected while connections with non-LLs > are not. Well, this depends. If your IP one hop neighbour gets out of range, you need to find a new one. If you are talking about TCP-alike connections (connection oriented protocols), I agree, but in this case it is a bad idea to use link-locals anyway, IMHO. Thanks, Carlos >=20 >=20 > > - Section 6.2: "There is no mechanism to ensure that IPv6 link- > >local > >addresses are unique across multiple links, hence they can not be used > >to reliably identify routers." --> this is not particular of MANETs > >either, why is in the document? >=20 > We should remove this argument. >=20 >=20 > > - Appendix A: "MANET Link Model" --> I don't believe in the > >existence > >of a "MANET Link", and I don't see its relevance in an __address > >autoconfiguration__ document. Repeating myself here... I think this > >document and some discussions in the ML deviate from the charter goal: > >we need to come up with a practical ____addressing____ architecture. > >IMHO, we have been discussing instead about "IP over MANET", which to me > >is a rather different thing (well, to me it doesn't even exist, if we > >consider L3 MANETs). >=20 > With having the draft-baccelli-autoconf-adhoc-addr-model, we can close > this issue. >=20 >=20 > > - Appendix A: "it remains to be determined whether or not the > >scope of > >AUTOCONF includes applications other than routing protocols running on > >the router" --> this is a very important question that we have brought > >in the meeting. I have my personal opinion, but this is irrelevant, > >since there seem to be a consensus (I wasn't aware of it, but Thomas > >stated otherwise). I'd like to ask the chairs to bring this to the ML to > >close this issue. >=20 > I think the consensus is that there are applications in a MANET. The MANE= T=20 > is not solely for running MANET protocols... . > It is also in the charter: > It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. >=20 >=20 > Teco. >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-XGU3yCdD3c4mR3zghRzO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksBAOUACgkQNdy6TdFwT2eA6wCfS6h4VtoWL1ru/rX0G94E8eLh ud4AnA4TbPd7Wd/DbtaEF3LUzIqT8mq0 =LCkZ -----END PGP SIGNATURE----- --=-XGU3yCdD3c4mR3zghRzO-- From cjbc@it.uc3m.es Sun Nov 15 23:43:49 2009 Return-Path: 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 23E243A6A91 for ; Sun, 15 Nov 2009 23:43:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.389 X-Spam-Level: X-Spam-Status: No, score=-5.389 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 JE1u3fFIkO42 for ; Sun, 15 Nov 2009 23:43:48 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id A21683A6A6A for ; Sun, 15 Nov 2009 23:43:46 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id DEA926C0F32; Mon, 16 Nov 2009 08:43:44 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4AFDD44F.7080302@earthlink.net> References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <4AFDD44F.7080302@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-ur9hL2gIMCsSIDnKqVQv" Organization: Universidad Carlos III de Madrid Date: Mon, 16 Nov 2009 08:43:45 +0100 Message-Id: <1258357425.7116.35.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17012.003 Cc: "autoconf@ietf.org" Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 07:43:49 -0000 --=-ur9hL2gIMCsSIDnKqVQv Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Charlie, On Fri, 2009-11-13 at 13:49 -0800, Charles E. Perkins wrote: > Hello Carlos, >=20 > An incomplete response: >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > - Section 3: "The configuration proposed by this model is applicable t= o > > any router's IP interface" --> I wonder if this should be changed to > > "The configuration proposed by this model is applicable to any router's > > IP MANET interface" or something like that. By saying "any router's IP > > interface" it may seem that the configuration of "non-MANET" interfaces > > would also follow the guidelines provided by the document (i.e., /128, > > no uniqueness ensured for LLs, etc.). I'd prefer to explicitly state > > that the model is for MANET interfaces. > > =20 > The point is that you _could_ use the constrained prefix assignment model > even for "non-MANET" interfaces. But the constraint would inhibit=20 > aggregation > which is obviously useful in more non-MANET networks. Nevertheless, exce= pt > for scalability, networks which COULD have aggregatable addresses would > still thereby be made to work without address aggregation. Please, see my reply to Thomas's e-mail. > > > > - Section 6.2: "Routers cannot forward any packet with link-local > > source or destination address to other links..." --> this is rather > > obvious and not particular of MANETs, why is this described in the > > document? > > > > - Section 6.2: "There is no mechanism to ensure that IPv6 link-local > > addresses are unique across multiple links, hence they can not be used > > to reliably identify routers." --> this is not particular of MANETs > > either, why is in the document? > > =20 >=20 > I thought the point was to supply justification in case anyone > might ask why the prefix constraint was disfavoring the aggregation > of addresses into a common link. I think the point of aggregation of addresses into a common link is more an architectural issue, than an addressing issue. If we had agreed on using an L2/L2.5 MANET model, then we could talk about this (and we would not need autoconf probably). Once we decided to go for L3 MANETs (which I agree), I think using the same prefix for different links is not very appropriate. That's why I don't see the value in the text I pointed out above. >=20 > > - Appendix A: "MANET Link Model" --> I don't believe in the existence > > of a "MANET Link", and I don't see its relevance in an __address > > autoconfiguration__ document. Repeating myself here... I think this > > document and some discussions in the ML deviate from the charter goal: > > we need to come up with a practical ____addressing____ architecture. > > IMHO, we have been discussing instead about "IP over MANET", which to m= e > > is a rather different thing (well, to me it doesn't even exist, if we > > consider L3 MANETs). > > =20 >=20 > This is likely the heart of the problem. A lot of people including me > have been running IP over MANET [perforce, layer-3] for years. > Then a great deal of controversy has been generated by people who > don't believe it can be done. Which seems to suggest that they don't > believe the working group is viable in the first place. I agree with your comment. Just to avoid misunderstandings, I believe in running IP over MANETs, but I also think it can be done without modifying IP (but only minor parts required for example to avoid IP address duplicates). Another clarification, I've also run IP over MANET for several years, though my experience is much limited than yours and others in this WG. Thanks, Carlos >=20 >=20 > Regards, > Charlie P. >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-ur9hL2gIMCsSIDnKqVQv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksBArEACgkQNdy6TdFwT2dLMwCg1N/S22JEjo0S1KhUd6d5clMk DcAAoITaDSCBsb4D9wD6F3BGmqCd1Bks =wX+x -----END PGP SIGNATURE----- --=-ur9hL2gIMCsSIDnKqVQv-- From teco@inf-net.nl Mon Nov 16 00:13:10 2009 Return-Path: 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 3736A3A6934 for ; Mon, 16 Nov 2009 00:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 ngjHvTHb9PrU for ; Mon, 16 Nov 2009 00:13:09 -0800 (PST) Received: from CPSMTPM-EML108.kpnxchange.com (Cpsmtpm-eml108.kpnxchange.com [195.121.3.12]) by core3.amsl.com (Postfix) with ESMTP id A255D3A692E for ; Mon, 16 Nov 2009 00:13:08 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML108.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Mon, 16 Nov 2009 09:13:03 +0100 From: "Teco Boot" To: References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <006a01ca65e2$2bdc1ba0$839452e0$@nl> <1258356965.7116.27.camel@acorde.it.uc3m.es> In-Reply-To: <1258356965.7116.27.camel@acorde.it.uc3m.es> Date: Mon, 16 Nov 2009 09:12:59 +0100 Message-ID: <00ba01ca6694$9c01b130$d4051390$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acpmj3afMI5szfS1Sj+4+MvNcUGGlAAA/qjA Content-Language: nl X-OriginalArrivalTime: 16 Nov 2009 08:13:03.0353 (UTC) FILETIME=[9E7AEE90:01CA6694] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 08:13:10 -0000 Hi Carlos, >> I say: interface with MANET protocol running. Then your suggestion > >I agree with that definition. It is actually the one we used in our >draft. > >> is also not completely correct. Interface to Wireless Link? Also > >Why is it not correct? > >> not completely correct, as there are many wireless links that do not >> have problems with on-link prefixes. My WLAN in IBSS mode is an example of an exception. We need a term (or repeating long text) for "an interface to other interfaces with undetermined connectivity". >Well, this depends. If your IP one hop neighbour gets out of range, you >need to find a new one. If you are talking about TCP-alike connections >(connection oriented protocols), I agree, but in this case it is a bad >idea to use link-locals anyway, IMHO. So we all agree that non-LLs are needed. And working on that first, with /128 prefixes in the routing protocol. This by configuring /128 on the interface, or override the off-link configured shorter prefix. Teco. From cjbc@it.uc3m.es Mon Nov 16 00:18:52 2009 Return-Path: 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 6539628C0E5 for ; Mon, 16 Nov 2009 00:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.467 X-Spam-Level: X-Spam-Status: No, score=-5.467 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 tgUkSoNGASpK for ; Mon, 16 Nov 2009 00:18:51 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 11F4D3A682E for ; Mon, 16 Nov 2009 00:18:50 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id B9780733ECD; Mon, 16 Nov 2009 09:18:48 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <00ba01ca6694$9c01b130$d4051390$@nl> References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <006a01ca65e2$2bdc1ba0$839452e0$@nl> <1258356965.7116.27.camel@acorde.it.uc3m.es> <00ba01ca6694$9c01b130$d4051390$@nl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-HqaWT4Pkk7fZjM5RqU/j" Organization: Universidad Carlos III de Madrid Date: Mon, 16 Nov 2009 09:18:49 +0100 Message-Id: <1258359529.7116.42.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 08:18:52 -0000 --=-HqaWT4Pkk7fZjM5RqU/j Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Teco, On Mon, 2009-11-16 at 09:12 +0100, Teco Boot wrote: > Hi Carlos, >=20 > >> I say: interface with MANET protocol running. Then your suggestion > > > >I agree with that definition. It is actually the one we used in our > >draft. > > > >> is also not completely correct. Interface to Wireless Link? Also > > > >Why is it not correct? > > > >> not completely correct, as there are many wireless links that do not > >> have problems with on-link prefixes. >=20 > My WLAN in IBSS mode is an example of an exception. An exception of what? I think I'm missing something or getting lost or both :) > We need a term (or repeating long text) for "an interface to > other interfaces with undetermined connectivity". >=20 >=20 > >Well, this depends. If your IP one hop neighbour gets out of range, you > >need to find a new one. If you are talking about TCP-alike connections > >(connection oriented protocols), I agree, but in this case it is a bad > >idea to use link-locals anyway, IMHO. >=20 > So we all agree that non-LLs are needed. Sure. > And working on that first, with /128 prefixes in the routing protocol. > This by configuring /128 on the interface, or override the off-link=20 > configured shorter prefix. Using /128 in the routing protocol does not necessarily imply configuring /128 on the interface, does it? Thanks, Carlos >=20 >=20 > Teco. >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-HqaWT4Pkk7fZjM5RqU/j Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksBCukACgkQNdy6TdFwT2dWMQCg1ZYDWKZpu5VbZW1K8nNMWnvp FC8AnimR/ku6Ms/7gGvf2tWYQ1XGoKQw =Gboz -----END PGP SIGNATURE----- --=-HqaWT4Pkk7fZjM5RqU/j-- From teco@inf-net.nl Mon Nov 16 00:35:29 2009 Return-Path: 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 6F6C128C0E7 for ; Mon, 16 Nov 2009 00:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] 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 OMVVZYHihki9 for ; Mon, 16 Nov 2009 00:35:28 -0800 (PST) Received: from CPSMTPM-EML101.kpnxchange.com (cpsmtpm-eml101.kpnxchange.com [195.121.3.5]) by core3.amsl.com (Postfix) with ESMTP id 2311828C0E6 for ; Mon, 16 Nov 2009 00:35:27 -0800 (PST) Received: from M90Teco ([86.83.9.22]) by CPSMTPM-EML101.kpnxchange.com with Microsoft SMTPSVC(7.0.6001.18000); Mon, 16 Nov 2009 09:35:26 +0100 From: "Teco Boot" To: References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <006a01ca65e2$2bdc1ba0$839452e0$@nl> <1258356965.7116.27.camel@acorde.it.uc3m.es> <00ba01ca6694$9c01b130$d4051390$@nl> <1258359529.7116.42.camel@acorde.it.uc3m.es> In-Reply-To: <1258359529.7116.42.camel@acorde.it.uc3m.es> Date: Mon, 16 Nov 2009 09:35:21 +0100 Message-ID: <00c601ca6697$bc149200$343db600$@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: AcpmlW97oGXR8Y88Rri/6fmTjizYfgAAKWPg Content-Language: nl X-OriginalArrivalTime: 16 Nov 2009 08:35:26.0147 (UTC) FILETIME=[BED90930:01CA6697] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 08:35:29 -0000 Hi Carlos, >-----Oorspronkelijk bericht----- >Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] >Verzonden: maandag 16 november 2009 9:19 >Aan: Teco Boot >CC: autoconf@ietf.org >Onderwerp: RE: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr- >model-00 > >Hi Teco, > >On Mon, 2009-11-16 at 09:12 +0100, Teco Boot wrote: >> Hi Carlos, >> >> >> I say: interface with MANET protocol running. Then your suggestion >> > >> >I agree with that definition. It is actually the one we used in our >> >draft. >> > >> >> is also not completely correct. Interface to Wireless Link? Also >> > >> >Why is it not correct? >> > >> >> not completely correct, as there are many wireless links that do >not >> >> have problems with on-link prefixes. >> >> My WLAN in IBSS mode is an example of an exception. > >An exception of what? I think I'm missing something or getting lost or >both :) It is about misuse of "MANET interface" or "interface to Wireless Link". Both uses are not correct for what we intend to say. MANET interface: interface with MANET running. Could be Ethernet. Interface to Wireless Link. Could be WLAN IBSS. > >> We need a term (or repeating long text) for "an interface to >> other interfaces with undetermined connectivity". >> >> >> >Well, this depends. If your IP one hop neighbour gets out of range, >you >> >need to find a new one. If you are talking about TCP-alike >connections >> >(connection oriented protocols), I agree, but in this case it is a >bad >> >idea to use link-locals anyway, IMHO. >> >> So we all agree that non-LLs are needed. > >Sure. > >> And working on that first, with /128 prefixes in the routing = protocol. >> This by configuring /128 on the interface, or override the off-link >> configured shorter prefix. > >Using /128 in the routing protocol does not necessarily imply >configuring /128 on the interface, does it? OK. But the implication looks obvious to me. I work with implementations that "manipulate" the configured prefix. In my use case with attached hosts (ad hoc L2 radio device), I need the HNA to get the L2 device reachable. Silly configuration, and an example why I don't like the maximum prefix recommendation. It results in implementations that doesn't deal with my use case. Nevertheless, I think is a good idea to support configured maximum=20 prefix lengths. It is also wise to support shorter prefixes as well. =20 Teco. From alexandru.petrescu@gmail.com Mon Nov 16 01:14:08 2009 Return-Path: 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 217253A6813 for ; Mon, 16 Nov 2009 01:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_45=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 mWf7-NcIuSzR for ; Mon, 16 Nov 2009 01:14:06 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 814963A67AF for ; Mon, 16 Nov 2009 01:14:06 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAG9E0RD006632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 10:14:00 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAG9E0UN007435; Mon, 16 Nov 2009 10:14:00 +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 nAG9Dx22012027; Mon, 16 Nov 2009 10:14:00 +0100 Message-ID: <4B0117D7.9090300@gmail.com> Date: Mon, 16 Nov 2009 10:13:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4AFDD24A.5090704@earthlink.net> <006901ca65df$513a5450$f3aefcf0$@nl> In-Reply-To: <006901ca65df$513a5450$f3aefcf0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 09:14:08 -0000 Teco Boot a écrit : > I posted LL text for the draft, with explanation of the LL problem. > http://www.ietf.org/mail-archive/web/autoconf/current/msg01828.html > > Here another copy: > Routers cannot forward any packets with link-local source or > destination addresses to other links (as per [RFC4291]). In general, > routers do not forward such packets. This would limit connectivity > between MANET nodes. For this reason, link-local addresses shall be > used only for protocols that require one-hop limited delivery of packets. > > This is the only argument on not using LLs that withstands any criticism. > Even Alex can agree on this text. Alex? Teco - I agree with your suggested text above about LLs. It does make sense - it reflects the only restriction of LLs - they're valid on a single link. I support inserting it in the draft. If you're interested in improving it... When you say that this would limit connectivity between MANET nodes you practically assume that a MANET is _not_ a single link, but several links. We may need to define what a link is. Up to now we have two supposed definitions of links, which are contradictory: the 4861 link and the ABC-problem link. If the MANET is made of several 4861-links then your statement above is fully true, I fully agree with you. If you put that in the text, like "would limit connectivity between MANET nodes (assuming a MANET is made of several 4861-links)". If OTOH the MANET is made of a single 4861-link then the connectivity between MANET nodes is not restricted by the use of LLs. (for example the 6lowpan "route-over" scenarios consider the network is a single link). Finally, if the MANET is made of 1..n ABC-links then I am not sure the the application of LLs restricts the communication between MANET nodes, because the ABC-links are not understood. Alex > > Teco. > > >> -----Oorspronkelijk bericht----- >> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >> Charles E. Perkins >> Verzonden: zaterdag 14 november 2009 6:40 >> Aan: cjbc@it.uc3m.es >> CC: autoconf@ietf.org >> Onderwerp: Re: [Autoconf] Question regarding use of LLs >> >> >> Hello Carlos, >> >> Where is the link on which the link-local is local? >> Do you want it to be the whole MANET? For any >> two nodes X and Y, not within range, how does >> X decide if Y is on-link? Do you require multi-hop >> signaling for on-link operations? If so, how do you >> justify forwarding a link-local address? They're >> not supposed to be forwarded, are they? >> >> I'm not saying these questions are impossible to >> answer. I think they are hard to answer, and that >> the answers serve only to fragment a solution space >> that could otherwise usefully be applicable to a much>wider class of ad hoc > networks. Furthermore, your >> answer might be quite unlikely to resemble another >> person's answer. Furthermore, certain popular >> classes of answers implicitly suppose an unscalable >> volume of signaling. >> >> I really really think there should be a design team >> to do link-local. >> >> Regards, >> Charlie P. >> >> >> Carlos Jesús Bernardos Cano wrote: >>> Hi all, >>> >>> During the last meeting, it was said several times that even if >> the >>> uniqueness of link-local was not an issue, LLs have other problems >> that >>> make it reasonable to discourage their use in MANETs. Can anybody >> please >>> be so kind of summarising those for me? this is not that obvious to >> me. >>> Thanks in advance. >>> >>> Carlos >>> >>> >>> ---------------------------------------------------------------------- >> -- >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >>> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Mon Nov 16 01:32:57 2009 Return-Path: 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 BB1BE28C0E7 for ; Mon, 16 Nov 2009 01:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_45=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 ua3U7C2SUyyP for ; Mon, 16 Nov 2009 01:32:56 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 8EFBE3A67A3 for ; Mon, 16 Nov 2009 01:32:56 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAG9WpmF028032 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 10:32:51 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAG9Wo7r016981; Mon, 16 Nov 2009 10:32:50 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAG9WnMg008872; Mon, 16 Nov 2009 10:32:50 +0100 Message-ID: <4B011C41.1020404@gmail.com> Date: Mon, 16 Nov 2009 10:32:49 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4AFDD24A.5090704@earthlink.net> <006901ca65df$513a5450$f3aefcf0$@nl> <4B0117D7.9090300@gmail.com> In-Reply-To: <4B0117D7.9090300@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] opinion needed on Teco LL text (was: Question regarding use of LLs) X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 09:32:57 -0000 Alexandru Petrescu a écrit : > Teco Boot a écrit : >> I posted LL text for the draft, with explanation of the LL problem. >> http://www.ietf.org/mail-archive/web/autoconf/current/msg01828.html >> >> Here another copy: >> Routers cannot forward any packets with link-local source or >> destination addresses to other links (as per [RFC4291]). In general, >> routers do not forward such packets. This would limit connectivity >> between MANET nodes. For this reason, link-local addresses shall be >> used only for protocols that require one-hop limited delivery of >> packets. >> >> This is the only argument on not using LLs that withstands any criticism. >> Even Alex can agree on this text. Alex? > > Teco - I agree with your suggested text above about LLs. It does make > sense - it reflects the only restriction of LLs - they're valid on a > single link. I support inserting it in the draft. Following my own post - what do other people think about this Teco LL suggested text? Alex > If you're interested in improving it... > > When you say that this would limit connectivity between MANET nodes you > practically assume that a MANET is _not_ a single link, but several > links. We may need to define what a link is. > > Up to now we have two supposed definitions of links, which are > contradictory: the 4861 link and the ABC-problem link. > > If the MANET is made of several 4861-links then your statement above is > fully true, I fully agree with you. If you put that in the text, like > "would limit connectivity between MANET nodes (assuming a MANET is made > of several 4861-links)". > > If OTOH the MANET is made of a single 4861-link then the connectivity > between MANET nodes is not restricted by the use of LLs. > > (for example the 6lowpan "route-over" scenarios consider the network is > a single link). > > Finally, if the MANET is made of 1..n ABC-links then I am not sure the > the application of LLs restricts the communication between MANET nodes, > because the ABC-links are not understood. > > Alex > >> >> Teco. >> >> >>> -----Oorspronkelijk bericht----- >>> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Namens >>> Charles E. Perkins >>> Verzonden: zaterdag 14 november 2009 6:40 >>> Aan: cjbc@it.uc3m.es >>> CC: autoconf@ietf.org >>> Onderwerp: Re: [Autoconf] Question regarding use of LLs >>> >>> >>> Hello Carlos, >>> >>> Where is the link on which the link-local is local? >>> Do you want it to be the whole MANET? For any >>> two nodes X and Y, not within range, how does >>> X decide if Y is on-link? Do you require multi-hop >>> signaling for on-link operations? If so, how do you >>> justify forwarding a link-local address? They're >>> not supposed to be forwarded, are they? >>> >>> I'm not saying these questions are impossible to >>> answer. I think they are hard to answer, and that >>> the answers serve only to fragment a solution space >>> that could otherwise usefully be applicable to a much>wider class of >>> ad hoc >> networks. Furthermore, your >>> answer might be quite unlikely to resemble another >>> person's answer. Furthermore, certain popular >>> classes of answers implicitly suppose an unscalable >>> volume of signaling. >>> >>> I really really think there should be a design team >>> to do link-local. >>> >>> Regards, >>> Charlie P. >>> >>> >>> Carlos Jesús Bernardos Cano wrote: >>>> Hi all, >>>> >>>> During the last meeting, it was said several times that even if >>> the >>>> uniqueness of link-local was not an issue, LLs have other problems >>> that >>>> make it reasonable to discourage their use in MANETs. Can anybody >>> please >>>> be so kind of summarising those for me? this is not that obvious to >>> me. >>>> Thanks in advance. >>>> >>>> Carlos >>>> >>>> >>>> ---------------------------------------------------------------------- >>> -- >>>> _______________________________________________ >>>> Autoconf mailing list >>>> Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >>>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > > From henning.rogge@fkie.fraunhofer.de Mon Nov 16 01:44:39 2009 Return-Path: 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 8B1903A686C for ; Mon, 16 Nov 2009 01:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 KmcVzBmN7qAs for ; Mon, 16 Nov 2009 01:44:38 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 6C1303A67A3 for ; Mon, 16 Nov 2009 01:44:38 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N9y8R-0003Y6-BQ; Mon, 16 Nov 2009 10:44:35 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N9y8R-0004zW-0Y; Mon, 16 Nov 2009 10:44:35 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Mon, 16 Nov 2009 10:44:25 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <006901ca65df$513a5450$f3aefcf0$@nl> <4B0117D7.9090300@gmail.com> In-Reply-To: <4B0117D7.9090300@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6009338.ZyeRmIbD99"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911161044.31398.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10027/Sun Nov 15 23:35:28 2009) by mailguard.fgan.de X-Scan-Signature: 52e07e0af4405bded81fc5fcc507a670 Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 09:44:39 -0000 --nextPart6009338.ZyeRmIbD99 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 16 2009 10:13:59 Alexandru Petrescu wrote: > Up to now we have two supposed definitions of links, which are > contradictory: the 4861 link and the ABC-problem link. The "ABC-problem" link is the normal case in a MANET. Without this kind of= =20 configuration, you don't have a MANET. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart6009338.ZyeRmIbD99 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksBHvkACgkQRIfGfFXsz+B6rwCcCshctdKnH8EaPYW/hjTtp9vN 3csAn3MXfQTIW7+sradxVTarDIq7OZzr =BFUS -----END PGP SIGNATURE----- --nextPart6009338.ZyeRmIbD99-- From cjbc@it.uc3m.es Mon Nov 16 01:47:46 2009 Return-Path: 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 7D23F3A693C for ; Mon, 16 Nov 2009 01:47:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.513 X-Spam-Level: X-Spam-Status: No, score=-5.513 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 2GFb4wXZnkgX for ; Mon, 16 Nov 2009 01:47:45 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 2658E3A693A for ; Mon, 16 Nov 2009 01:47:44 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id E445373318A; Mon, 16 Nov 2009 10:47:41 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Teco Boot In-Reply-To: <00c601ca6697$bc149200$343db600$@nl> References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <006a01ca65e2$2bdc1ba0$839452e0$@nl> <1258356965.7116.27.camel@acorde.it.uc3m.es> <00ba01ca6694$9c01b130$d4051390$@nl> <1258359529.7116.42.camel@acorde.it.uc3m.es> <00c601ca6697$bc149200$343db600$@nl> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-hJEn3HQgnfApeu20fo7x" Organization: Universidad Carlos III de Madrid Date: Mon, 16 Nov 2009 10:47:42 +0100 Message-Id: <1258364862.7116.52.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 09:47:46 -0000 --=-hJEn3HQgnfApeu20fo7x Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Teco, On Mon, 2009-11-16 at 09:35 +0100, Teco Boot wrote: > Hi Carlos, >=20 > >-----Oorspronkelijk bericht----- > >Van: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es] > >Verzonden: maandag 16 november 2009 9:19 > >Aan: Teco Boot > >CC: autoconf@ietf.org > >Onderwerp: RE: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr- > >model-00 > > > >Hi Teco, > > > >On Mon, 2009-11-16 at 09:12 +0100, Teco Boot wrote: > >> Hi Carlos, > >> > >> >> I say: interface with MANET protocol running. Then your suggestion > >> > > >> >I agree with that definition. It is actually the one we used in our > >> >draft. > >> > > >> >> is also not completely correct. Interface to Wireless Link? Also > >> > > >> >Why is it not correct? > >> > > >> >> not completely correct, as there are many wireless links that do > >not > >> >> have problems with on-link prefixes. > >> > >> My WLAN in IBSS mode is an example of an exception. > > > >An exception of what? I think I'm missing something or getting lost or > >both :) >=20 > It is about misuse of "MANET interface" or "interface to Wireless Link". > Both uses are not correct for what we intend to say. >=20 > MANET interface: interface with MANET running. > Could be Ethernet. >=20 > Interface to Wireless Link. > Could be WLAN IBSS. I see now. In my understanding, we can say that the model is for applicable to MANET interfaces, and then use the same kind of text that is already in the draft to say that for those MANET interfaces with well known characteristics/properties (e.g., wired Ethernet) some restrictions/consideration of the addressing model might not apply or something like this... Thanks, Carlos >=20 >=20 > > > >> We need a term (or repeating long text) for "an interface to > >> other interfaces with undetermined connectivity". > >> > >> > >> >Well, this depends. If your IP one hop neighbour gets out of range, > >you > >> >need to find a new one. If you are talking about TCP-alike > >connections > >> >(connection oriented protocols), I agree, but in this case it is a > >bad > >> >idea to use link-locals anyway, IMHO. > >> > >> So we all agree that non-LLs are needed. > > > >Sure. > > > >> And working on that first, with /128 prefixes in the routing protocol. > >> This by configuring /128 on the interface, or override the off-link > >> configured shorter prefix. > > > >Using /128 in the routing protocol does not necessarily imply > >configuring /128 on the interface, does it? >=20 > OK. But the implication looks obvious to me. > I work with implementations that "manipulate" the configured prefix. > In my use case with attached hosts (ad hoc L2 radio device), > I need the HNA to get the L2 device reachable. Silly configuration, > and an example why I don't like the maximum prefix recommendation. > It results in implementations that doesn't deal with my use case. >=20 > Nevertheless, I think is a good idea to support configured maximum=20 > prefix lengths. It is also wise to support shorter prefixes as well. > =20 >=20 > Teco. >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-hJEn3HQgnfApeu20fo7x Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksBH74ACgkQNdy6TdFwT2ciegCbBQHkYmSwvsdhOYuT/kzl7BOH qOUAoMQWzHnAKzdrE0+PRhjrocQzuwuF =faGP -----END PGP SIGNATURE----- --=-hJEn3HQgnfApeu20fo7x-- From cjbc@it.uc3m.es Mon Nov 16 01:49:27 2009 Return-Path: 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 175A428C0F3 for ; Mon, 16 Nov 2009 01:49:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.546 X-Spam-Level: X-Spam-Status: No, score=-4.546 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 NJorEtqwCsE8 for ; Mon, 16 Nov 2009 01:49:26 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id B40DD3A693A for ; Mon, 16 Nov 2009 01:49:25 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id AD6876C252C; Mon, 16 Nov 2009 10:49:23 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Alexandru Petrescu In-Reply-To: <4B0117D7.9090300@gmail.com> References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4AFDD24A.5090704@earthlink.net> <006901ca65df$513a5450$f3aefcf0$@nl> <4B0117D7.9090300@gmail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-a0PltwE6vXNfkMwzl6NA" Organization: Universidad Carlos III de Madrid Date: Mon, 16 Nov 2009 10:49:24 +0100 Message-Id: <1258364964.7116.53.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17012.006 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2009 09:49:27 -0000 --=-a0PltwE6vXNfkMwzl6NA Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, On Mon, 2009-11-16 at 10:13 +0100, Alexandru Petrescu wrote: > Teco Boot a =E9crit : > > I posted LL text for the draft, with explanation of the LL problem. > > http://www.ietf.org/mail-archive/web/autoconf/current/msg01828.html > >=20 > > Here another copy: > > Routers cannot forward any packets with link-local source or > > destination addresses to other links (as per [RFC4291]). In general, > > routers do not forward such packets. This would limit connectivity > > between MANET nodes. For this reason, link-local addresses shall be=20 > > used only for protocols that require one-hop limited delivery of pac= kets. > >=20 > > This is the only argument on not using LLs that withstands any criticis= m. > > Even Alex can agree on this text. Alex? >=20 > Teco - I agree with your suggested text above about LLs. It does make=20 > sense - it reflects the only restriction of LLs - they're valid on a=20 > single link. I support inserting it in the draft. >=20 > If you're interested in improving it... >=20 > When you say that this would limit connectivity between MANET nodes you=20 > practically assume that a MANET is _not_ a single link, but several=20 > links. We may need to define what a link is. >=20 > Up to now we have two supposed definitions of links, which are=20 > contradictory: the 4861 link and the ABC-problem link. >=20 > If the MANET is made of several 4861-links then your statement above is=20 > fully true, I fully agree with you. If you put that in the text, like=20 > "would limit connectivity between MANET nodes (assuming a MANET is made=20 > of several 4861-links)". I share this view. Carlos >=20 > If OTOH the MANET is made of a single 4861-link then the connectivity=20 > between MANET nodes is not restricted by the use of LLs. >=20 > (for example the 6lowpan "route-over" scenarios consider the network is > a single link). >=20 > Finally, if the MANET is made of 1..n ABC-links then I am not sure the=20 > the application of LLs restricts the communication between MANET nodes,=20 > because the ABC-links are not understood. >=20 > Alex >=20 > >=20 > > Teco. > >=20 > >=20 > >> -----Oorspronkelijk bericht----- > >> Van: autoconf-bounces@ietf.org [mailto:autoconf-bounces@ietf.org] Name= ns > >> Charles E. Perkins > >> Verzonden: zaterdag 14 november 2009 6:40 > >> Aan: cjbc@it.uc3m.es > >> CC: autoconf@ietf.org > >> Onderwerp: Re: [Autoconf] Question regarding use of LLs > >> > >> > >> Hello Carlos, > >> > >> Where is the link on which the link-local is local? > >> Do you want it to be the whole MANET? For any > >> two nodes X and Y, not within range, how does > >> X decide if Y is on-link? Do you require multi-hop > >> signaling for on-link operations? If so, how do you > >> justify forwarding a link-local address? They're > >> not supposed to be forwarded, are they? > >> > >> I'm not saying these questions are impossible to > >> answer. I think they are hard to answer, and that > >> the answers serve only to fragment a solution space > >> that could otherwise usefully be applicable to a much>wider class of a= d hoc > > networks. Furthermore, your > >> answer might be quite unlikely to resemble another > >> person's answer. Furthermore, certain popular > >> classes of answers implicitly suppose an unscalable > >> volume of signaling. > >> > >> I really really think there should be a design team > >> to do link-local. > >> > >> Regards, > >> Charlie P. > >> > >> > >> Carlos Jes=FAs Bernardos Cano wrote: > >>> Hi all, > >>> > >>> During the last meeting, it was said several times that even if > >> the > >>> uniqueness of link-local was not an issue, LLs have other problems > >> that > >>> make it reasonable to discourage their use in MANETs. Can anybody > >> please > >>> be so kind of summarising those for me? this is not that obvious to > >> me. > >>> Thanks in advance. > >>> > >>> Carlos > >>> > >>> > >>> ---------------------------------------------------------------------= - > >> -- > >>> _______________________________________________ > >>> Autoconf mailing list > >>> Autoconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/autoconf > >>> > >> _______________________________________________ > >> Autoconf mailing list > >> Autoconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/autoconf > >=20 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www.ietf.org/mailman/listinfo/autoconf > >=20 >=20 >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-a0PltwE6vXNfkMwzl6NA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksBICQACgkQNdy6TdFwT2d2+ACeN5HbOBHJ7IFyUNucvxyUuMlu /xQAn2bwjjXs8Ad200j4xo8lqdWFJJWn =m/uU -----END PGP SIGNATURE----- --=-a0PltwE6vXNfkMwzl6NA-- From alexandru.petrescu@gmail.com Mon Nov 16 02:02:27 2009 Return-Path: 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 1844428C10E for ; Mon, 16 Nov 2009 02:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 FzNh5UVQiDDe for ; Mon, 16 Nov 2009 02:02:26 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 917DB28C10B for ; Mon, 16 Nov 2009 02:02:21 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAGA2BZV010388 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 11:02:11 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGA2B02029926; Mon, 16 Nov 2009 11:02:11 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAGA2AhX023918; Mon, 16 Nov 2009 11:02:10 +0100 Message-ID: <4B012322.30807@gmail.com> Date: Mon, 16 Nov 2009 11:02:10 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <006901ca65df$513a5450$f3aefcf0$@nl> <4B0117D7.9090300@gmail.com> <200911161044.31398.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911161044.31398.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 10:02:27 -0000 Henning Rogge a écrit : > On Mon November 16 2009 10:13:59 Alexandru Petrescu wrote: >> Up to now we have two supposed definitions of links, which are >> contradictory: the 4861 link and the ABC-problem link. > > The "ABC-problem" link is the normal case in a MANET. Without this kind of > configuration, you don't have a MANET. Well, given that importantce, one would need to define it rather precisely. I understand somehow the ABC problem as it has been presented until now, with respect to the hidden terminal problem, and the C. Perkins Hiroshima presentation. However, it is not clear what it means with respect to the IPv6 concepts such as the link-local scope, link-local addresses. Are there two 4861 links between A, B and C? Each with its own 4861-link semantics and link-local scopes? Alex > > Henning Rogge > From henning.rogge@fkie.fraunhofer.de Mon Nov 16 02:07:24 2009 Return-Path: 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 F3B5828C0E9 for ; Mon, 16 Nov 2009 02:07:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.949 X-Spam-Level: X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ocL0R9MJFwaE for ; Mon, 16 Nov 2009 02:07:22 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id A567428C0F6 for ; Mon, 16 Nov 2009 02:07:22 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N9yUS-0002Kn-Ji; Mon, 16 Nov 2009 11:07:20 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1N9yUS-0005CU-7t; Mon, 16 Nov 2009 11:07:20 +0100 From: Henning Rogge To: Alexandru Petrescu Date: Mon, 16 Nov 2009 11:07:07 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161044.31398.henning.rogge@fkie.fraunhofer.de> <4B012322.30807@gmail.com> In-Reply-To: <4B012322.30807@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1870389.23MDUZlyOv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911161107.12792.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10027/Sun Nov 15 23:35:28 2009) by mailguard.fgan.de X-Scan-Signature: e39b0b635d2099d1d28d84c0f3b7851d Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 10:07:24 -0000 --nextPart1870389.23MDUZlyOv Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 16 2009 11:02:10 Alexandru Petrescu wrote: > > The "ABC-problem" link is the normal case in a MANET. Without this kind > > of configuration, you don't have a MANET. >=20 > Well, given that importantce, one would need to define it rather precisel= y. >=20 > I understand somehow the ABC problem as it has been presented until now, > with respect to the hidden terminal problem, and the C. Perkins > Hiroshima presentation. >=20 > However, it is not clear what it means with respect to the IPv6 concepts > such as the link-local scope, link-local addresses. >=20 > Are there two 4861 links between A, B and C? Each with its own > 4861-link semantics and link-local scopes? As I understand "4861 links" no... 4861 would assume that the two links=20 between A-B and B-C are not connected directly. The typical case in a MANET (especially if every node has only one interfac= e)=20 is that there are LOTS of nodes (in this case B) that can reach two nodes (= in=20 this case A and C) on the same interface which cannot hear each other. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1870389.23MDUZlyOv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksBJEsACgkQRIfGfFXsz+DccACfQs23PTDiAOizsts/xJmhA9Hk xBIAn0uEvd7+W4J36JbCYvuw7iZcCxyj =uKL7 -----END PGP SIGNATURE----- --nextPart1870389.23MDUZlyOv-- From alexandru.petrescu@gmail.com Mon Nov 16 02:13:40 2009 Return-Path: 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 CC91528C125 for ; Mon, 16 Nov 2009 02:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 IiPqH579mqYT for ; Mon, 16 Nov 2009 02:13:39 -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 2D11828C124 for ; Mon, 16 Nov 2009 02:13:39 -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-2.0) with ESMTP id nAGADV4l020490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 11:13:31 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGADVBA002493; Mon, 16 Nov 2009 11:13:31 +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 nAGADUxq012216; Mon, 16 Nov 2009 11:13:31 +0100 Message-ID: <4B0125CA.6080609@gmail.com> Date: Mon, 16 Nov 2009 11:13:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161044.31398.henning.rogge@fkie.fraunhofer.de> <4B012322.30807@gmail.com> <200911161107.12792.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911161107.12792.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 10:13:40 -0000 Henning Rogge a écrit : > On Mon November 16 2009 11:02:10 Alexandru Petrescu wrote: >>> The "ABC-problem" link is the normal case in a MANET. Without this kind >>> of configuration, you don't have a MANET. >> Well, given that importantce, one would need to define it rather precisely. >> >> I understand somehow the ABC problem as it has been presented until now, >> with respect to the hidden terminal problem, and the C. Perkins >> Hiroshima presentation. >> >> However, it is not clear what it means with respect to the IPv6 concepts >> such as the link-local scope, link-local addresses. >> >> Are there two 4861 links between A, B and C? Each with its own >> 4861-link semantics and link-local scopes? > > As I understand "4861 links" no... 4861 would assume that the two links > between A-B and B-C are not connected directly. Yes, I believe 4861 would assume B is a router between the two links. > The typical case in a MANET (especially if every node has only one interface) > is that there are LOTS of nodes (in this case B) that can reach two nodes (in > this case A and C) on the same interface which cannot hear each other. Could we define the ABC links in terms of 4861 links or not? If not, I am afraid we can not use the term "link" in MANET at all. On another hand, people have run "MANET" with links and link-local addresses in the past too. Alex > > Henning Rogge > From teco@inf-net.nl Mon Nov 16 03:15:42 2009 Return-Path: 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 14FB03A6836 for ; Mon, 16 Nov 2009 03:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.015 X-Spam-Level: X-Spam-Status: No, score=-0.015 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] 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 73CO4FdnjBmT for ; Mon, 16 Nov 2009 03:15:41 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id E77B73A684D for ; Mon, 16 Nov 2009 03:15:40 -0800 (PST) Received: (qmail 18815 invoked from network); 16 Nov 2009 12:15:37 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 16 Nov 2009 12:15:37 +0100 From: "Teco Boot" To: References: <1258127094.5035.32.camel@acorde.it.uc3m.es> <006a01ca65e2$2bdc1ba0$839452e0$@nl> <1258356965.7116.27.camel@acorde.it.uc3m.es> <00ba01ca6694$9c01b130$d4051390$@nl> <1258359529.7116.42.camel@acorde.it.uc3m.es> <00c601ca6697$bc149200$343db600$@nl> <1258364862.7116.52.camel@acorde.it.uc3m.es> In-Reply-To: <1258364862.7116.52.camel@acorde.it.uc3m.es> Date: Mon, 16 Nov 2009 12:15:03 +0100 Message-ID: <002501ca66ae$1d3314b0$57993e10$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpmoeDBlTJD9HrDSV6UtukZSTrQsAACNUXQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on draft-ietf-autoconf-adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 11:15:42 -0000 Hi Carlos, >> It is about misuse of "MANET interface" or "interface to Wireless >Link". >> Both uses are not correct for what we intend to say. >> >> MANET interface: interface with MANET running. >> Could be Ethernet. >> >> Interface to Wireless Link. >> Could be WLAN IBSS. > >I see now. In my understanding, we can say that the model is for >applicable to MANET interfaces, and then use the same kind of text that >is already in the draft to say that for those MANET interfaces with well >known characteristics/properties (e.g., wired Ethernet) some >restrictions/consideration of the addressing model might not apply or >something like this... I was sleepy this morning. I meant WLAN BSS for an example of wrong usage. This type of interface connected to a Wireless Link works OK. WLAN in IBSS running MANET protocol is in scope. Teco. From henning.rogge@fkie.fraunhofer.de Mon Nov 16 04:23:40 2009 Return-Path: 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 C038528C0FE for ; Mon, 16 Nov 2009 04:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 GbEB3UVBXJbG for ; Mon, 16 Nov 2009 04:23:39 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id BA8BE3A695F for ; Mon, 16 Nov 2009 04:23:39 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NA0cL-0007EY-A9; Mon, 16 Nov 2009 13:23:37 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NA0cL-0005yW-0W; Mon, 16 Nov 2009 13:23:37 +0100 From: Henning Rogge To: Alexandru Petrescu Date: Mon, 16 Nov 2009 13:23:28 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161107.12792.henning.rogge@fkie.fraunhofer.de> <4B0125CA.6080609@gmail.com> In-Reply-To: <4B0125CA.6080609@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3337374.hDzs4zeCsI"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911161323.33582.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10027/Sun Nov 15 23:35:28 2009) by mailguard.fgan.de X-Scan-Signature: 054ccd22e44c7b570fe3109fd6105c99 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 12:23:40 -0000 --nextPart3337374.hDzs4zeCsI Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 16 2009 11:13:30 Alexandru Petrescu wrote: > > As I understand "4861 links" no... 4861 would assume that the two links > > between A-B and B-C are not connected directly. >=20 > Yes, I believe 4861 would assume B is a router between the two links. In a wireless network it's just a matter of radio range and connectivity,=20 which might change through external influences and movement. =20 > > The typical case in a MANET (especially if every node has only one > > interface) is that there are LOTS of nodes (in this case B) that can > > reach two nodes (in this case A and C) on the same interface which cann= ot > > hear each other. >=20 > Could we define the ABC links in terms of 4861 links or not? In wireless networks links between nodes don't have disjoined groups of=20 interfaces. The 'is connected to' condition is not always transitive in=20 wireless networks. =20 > If not, I am afraid we can not use the term "link" in MANET at all. I disagree. Link is a connection between two devices on layer 2. It's the right term f= or=20 the connection between two wireless devices too. > On another hand, people have run "MANET" with links and link-local > addresses in the past too. MOST times it will work. Just by trying to get a "linklocal unique" IP, you= =20 will get "mesh unique" IPs. Or maybe the same IPs are two far away to troub= le=20 you. But you have no guarantee for this and DAD as described in IPv6 cannot dete= ct=20 some of the problems. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3337374.hDzs4zeCsI Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksBREAACgkQRIfGfFXsz+BLTQCeOwSs7b32q/ZGhCoITKDbASP9 hqoAn2UYIM5026PKbnmZhqqg5GGjjfKw =5RVs -----END PGP SIGNATURE----- --nextPart3337374.hDzs4zeCsI-- From Chris.Dearlove@baesystems.com Mon Nov 16 05:08:02 2009 Return-Path: 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 BC8D33A6AA3 for ; Mon, 16 Nov 2009 05:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 TdSZPrZTUd1A for ; Mon, 16 Nov 2009 05:08:02 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id C58C23A680C for ; Mon, 16 Nov 2009 05:08:01 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,751,1249254000"; d="scan'208";a="33159336" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Nov 2009 13:07:57 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAGD85E4024946; Mon, 16 Nov 2009 13:08:05 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 13:07:56 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Nov 2009 13:07:53 -0000 Message-ID: In-Reply-To: <200911161323.33582.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Question regarding use of LLs thread-index: Acpmt6a+PXpMN3D6Tb+nvxzXVO9+1wABWI7w References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , "Alexandru Petrescu" X-OriginalArrivalTime: 16 Nov 2009 13:07:57.0108 (UTC) FILETIME=[D0C7AF40:01CA66BD] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 13:08:02 -0000 > Link is a connection between two devices on layer 2. It's the right term for > the connection between two wireless devices too. It's also used in "link state" as in link state protocol, as in the middle two letters of OLSR. At that level it's as much a mathematical concept as anything else, but it directly corresponds to the layer 2 link referred to above. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Mon Nov 16 05:53:08 2009 Return-Path: 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 7AD6B3A677E for ; Mon, 16 Nov 2009 05:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, 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 NkJ5kpa6knSr for ; Mon, 16 Nov 2009 05:53:07 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 5548F3A694C for ; Mon, 16 Nov 2009 05:53:07 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAGDqwi2004175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 14:52:58 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGDqvdn002531; Mon, 16 Nov 2009 14:52:58 +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 nAGDqv3l030920; Mon, 16 Nov 2009 14:52:57 +0100 Message-ID: <4B015939.9070503@gmail.com> Date: Mon, 16 Nov 2009 14:52:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161107.12792.henning.rogge@fkie.fraunhofer.de> <4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911161323.33582.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 13:53:08 -0000 Henning Rogge a écrit : > On Mon November 16 2009 11:13:30 Alexandru Petrescu wrote: >>> As I understand "4861 links" no... 4861 would assume that the two links >>> between A-B and B-C are not connected directly. >> >> Yes, I believe 4861 would assume B is a router between the two links. > > In a wireless network it's just a matter of radio range and connectivity, > which might change through external influences and movement. Cables also might change through external influence such as people disconnecting cables. Nothing new in wireless. >>> The typical case in a MANET (especially if every node has only one >>> interface) is that there are LOTS of nodes (in this case B) that can >>> reach two nodes (in this case A and C) on the same interface which cannot >>> hear each other. >> Could we define the ABC links in terms of 4861 links or not? > > In wireless networks links between nodes don't have disjoined groups of > interfaces. Are they point-to-point links? We do have an understanding of point-to-point links, their link-local scope and their link-local addresses, such as the IPv6 PPP RFC. > The 'is connected to' condition is not always transitive in > wireless networks. When is it _not_ transitive? Please give hands-on experience and deterministic behaviour otherwise we can't deal with it. >> If not, I am afraid we can not use the term "link" in MANET at all. > > I disagree. Ok, we're in disagreement about the use of term "link". It is very difficult to write a spec without agreement on terminology. IPv6 link-local addresses are discouraged on 4861-links? Or on ABC-problem links? > Link is a connection between two devices on layer 2. It's the right term for > the connection between two wireless devices too. That sounds to me as a point-to-point link, and maybe as a NBMA link (Non-Broadcast Multiple Access). (although I do question the meaning of NBMA - is "non-broadcast" multicast?) Is an AUTOCONF "link" a point-to-point link and/or a NBMA link, and not an ABC-problem link? >> On another hand, people have run "MANET" with links and link-local >> addresses in the past too. > > MOST times it will work. Just by trying to get a "linklocal unique" IP, you > will get "mesh unique" IPs. Or maybe the same IPs are two far away to trouble > you. > > But you have no guarantee for this and DAD as described in IPv6 cannot detect > some of the problems. HEnning, if my links are properly set up between devices then the IPv6 LLs will work all the times, not just some times. The difference is in understanding "link". Alex > > Henning Rogge > From alexandru.petrescu@gmail.com Mon Nov 16 05:59:53 2009 Return-Path: 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 A861C3A67FA for ; Mon, 16 Nov 2009 05:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.129 X-Spam-Level: X-Spam-Status: No, score=-3.129 tagged_above=-999 required=5 tests=[AWL=1.120, BAYES_00=-2.599, GB_I_LETTER=-2, 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 l--RSwTWqXgg for ; Mon, 16 Nov 2009 05:59:52 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 9DD283A694C for ; Mon, 16 Nov 2009 05:59:52 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAGDxJkn009304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 14:59:19 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGDxIN3004570; Mon, 16 Nov 2009 14:59:19 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAGDxIOn019485; Mon, 16 Nov 2009 14:59:18 +0100 Message-ID: <4B015AB5.7040908@gmail.com> Date: Mon, 16 Nov 2009 14:59:17 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 13:59:53 -0000 Dearlove, Christopher (UK) a écrit : >> Link is a connection between two devices on layer 2. It's the right >> term for the connection between two wireless devices too. > > It's also used in "link state" as in link state protocol, as in the > middle two letters of OLSR. At that level it's as much a mathematical > concept as anything else, but it directly corresponds to the layer 2 > link referred to above. YEs, but OSPF IPv6 spec is clear about the difference between "link state" and "link-local", for example when it says this: " o Link-local scope. LSA is only flooded on the local link and no further. Used for the new link-LSA. See Section 4.4.3.8 for details." Note "LSA" and "local link" - they're clearly different. Whereas here we mix and match "link" and "link" according our various non-consensual tastes depending on a day's mood. I think we should define what we understand by "link" in AUTOCONF: -is it NBMA? Is it point-to-point? -does it support link-layer multicast? -is it transitive? Non-transitive? -does it have ABC problem? Does it _not_ have ABC problems? -is an AUTOCONF network made by several distinctive links or by a single link which has the ABC problem? Can't be all at once. Alex > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > From Chris.Dearlove@baesystems.com Mon Nov 16 06:33:12 2009 Return-Path: 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 BE9083A6AC0 for ; Mon, 16 Nov 2009 06:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599] 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 mMgHaSJY353H for ; Mon, 16 Nov 2009 06:33:12 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id B53483A681D for ; Mon, 16 Nov 2009 06:33:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,751,1249254000"; d="scan'208";a="33188144" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Nov 2009 14:33:10 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAGEXHKs024289; Mon, 16 Nov 2009 14:33:18 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 14:33:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Nov 2009 14:33:08 -0000 Message-ID: In-Reply-To: <4B015AB5.7040908@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Question regarding use of LLs thread-index: AcpmxQ0fQ797ZON8SWyuxE65pBM1vgAAfkNg References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 16 Nov 2009 14:33:10.0127 (UTC) FILETIME=[B86077F0:01CA66C9] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 14:33:12 -0000 > -is it transitive? Non-transitive? > -does it have ABC problem? Does it _not_ have ABC problems? Let's stop having this raised again and again. In the real world, with real radios in real deployments, A and B may be able to hear each other, and B and C may be able to hear each other, but A and C may not. This is what non-transitive means (it's mathematican speak for that). End of story, it comes from physics. We need to solve this problem. You can do it at layer 2, and try to make layer 3 look like an Ethernet. If so, the IEEE is that way ---> It's a perfectly good approach (involving solving most of the same problems, but specialised to particular systems) but it's not what we are doing in the IETF, which is doing it at layer 3. If you want to know why, the IETF answer is in RFC 2501. (The short version is layer 1/2 independence and heterogeneity.) But it's not negotiable, that's what we are doing in the MANET and Autoconf WGs. The rest of everything we do follows from that. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Mon Nov 16 07:14:33 2009 Return-Path: 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 5069D3A6AC2 for ; Mon, 16 Nov 2009 07:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.316 X-Spam-Level: X-Spam-Status: No, score=-2.316 tagged_above=-999 required=5 tests=[AWL=-0.067, 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 J9Qj0-4hBg52 for ; Mon, 16 Nov 2009 07:14:22 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id C54DA3A6876 for ; Mon, 16 Nov 2009 07:14:19 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAGFEBMD003139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 16:14:11 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGFEAQS031149; Mon, 16 Nov 2009 16:14:11 +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 nAGFEA0f002665; Mon, 16 Nov 2009 16:14:10 +0100 Message-ID: <4B016C41.4080804@gmail.com> Date: Mon, 16 Nov 2009 16:14:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 15:14:33 -0000 I disagree. RFC2501 was written when people were not running IPv6 in their MANETs. The today's widely used WiFi was not available at all in 1999. I also disagree fully with the tight connection between the AUTOCONF work and MANET WG work. Alex Dearlove, Christopher (UK) a écrit : >> -is it transitive? Non-transitive? -does it have ABC problem? >> Does it _not_ have ABC problems? > > Let's stop having this raised again and again. In the real world, > with real radios in real deployments, A and B may be able to hear > each other, and B and C may be able to hear each other, but A and C > may not. This is what non-transitive means (it's mathematican speak > for that). End of story, it comes from physics. We need to solve this > problem. You can do it at layer 2, and try to make layer 3 look like > an Ethernet. If so, the IEEE is that way ---> It's a perfectly good > approach (involving solving most of the same problems, but > specialised to particular systems) but it's not what we are doing in > the IETF, which is doing it at layer 3. If you want to know why, the > IETF answer is in RFC 2501. (The short version is layer 1/2 > independence and heterogeneity.) But it's not negotiable, that's what > we are doing in the MANET and Autoconf WGs. The rest of everything we > do follows from that. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > From ulrich@herberg.name Mon Nov 16 07:22:23 2009 Return-Path: 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 337B13A6805 for ; Mon, 16 Nov 2009 07:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 FOFdkCUZG6D6 for ; Mon, 16 Nov 2009 07:22:22 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 3EBD53A677E for ; Mon, 16 Nov 2009 07:22:21 -0800 (PST) Received: by fxm7 with SMTP id 7so5859591fxm.29 for ; Mon, 16 Nov 2009 07:22:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.24.65 with SMTP id u1mr5872613bkb.176.1258384934485; Mon, 16 Nov 2009 07:22:14 -0800 (PST) In-Reply-To: References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161107.12792.henning.rogge@fkie.fraunhofer.de> <4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> Date: Mon, 16 Nov 2009 16:22:13 +0100 Message-ID: <25c114b90911160722i4f0a64d1l33db5b4dc543707d@mail.gmail.com> From: Ulrich Herberg To: "Dearlove, Christopher (UK)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 15:22:23 -0000 On Mon, Nov 16, 2009 at 3:33 PM, Dearlove, Christopher (UK) wrote: >> -is it transitive? =A0Non-transitive? >> -does it have ABC problem? =A0Does it _not_ have ABC problems? > > Let's stop having this raised again and again. In the real world, > with real radios in real deployments, A and B may be able to > hear each other, and B and C may be able to hear each other, > but A and C may not. This is what non-transitive means (it's > mathematican speak for that). End of story, it comes from > physics. We need to solve this problem. You can do it at > layer 2, and try to make layer 3 look like an Ethernet. > If so, the IEEE is that way ---> It's a perfectly good > approach (involving solving most of the same problems, but > specialised to particular systems) but it's not what we are > doing in the IETF, which is doing it at layer 3. If you want > to know why, the IETF answer is in RFC 2501. (The short version > is layer 1/2 independence and heterogeneity.) But it's not > negotiable, that's what we are doing in the MANET and Autoconf > WGs. The rest of everything we do follows from that. I fully agree with this description. Non-transitivity (or "ABC" as sometimes called in this email thread) is a very basic scenario that will appear in most MANETs (with at least three routers, which are not all contained within a single hop). Of course you could pretend a MANET to be an Ethernet on L2 (as in IEEE 802.11s). But this is not what we are doing in the IETF. So we have to deal with that case. Ulrich From alexandru.petrescu@gmail.com Mon Nov 16 07:27:35 2009 Return-Path: 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 5F65E28C11B for ; Mon, 16 Nov 2009 07:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=-0.057, 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 3UekpUa6wfUL for ; Mon, 16 Nov 2009 07:27:34 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 4767D3A68DD for ; Mon, 16 Nov 2009 07:27:34 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAGFRUs7014675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 16:27:30 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGFRT4Z003258; Mon, 16 Nov 2009 16:27:29 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAGFRSSt026139; Mon, 16 Nov 2009 16:27:29 +0100 Message-ID: <4B016F60.4050000@gmail.com> Date: Mon, 16 Nov 2009 16:27:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161107.12792.henning.rogge@fkie.fraunhofer.de> <4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <25c114b90911160722i4f0a64d1l33db5b4dc543707d@mail.gmail.com> In-Reply-To: <25c114b90911160722i4f0a64d1l33db5b4dc543707d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 15:27:35 -0000 Ulrich Herberg a écrit : > On Mon, Nov 16, 2009 at 3:33 PM, Dearlove, Christopher (UK) > wrote: >>> -is it transitive? Non-transitive? -does it have ABC problem? >>> Does it _not_ have ABC problems? >> Let's stop having this raised again and again. In the real world, >> with real radios in real deployments, A and B may be able to hear >> each other, and B and C may be able to hear each other, but A and C >> may not. This is what non-transitive means (it's mathematican speak >> for that). End of story, it comes from physics. We need to solve >> this problem. You can do it at layer 2, and try to make layer 3 >> look like an Ethernet. If so, the IEEE is that way ---> It's a >> perfectly good approach (involving solving most of the same >> problems, but specialised to particular systems) but it's not what >> we are doing in the IETF, which is doing it at layer 3. If you want >> to know why, the IETF answer is in RFC 2501. (The short version is >> layer 1/2 independence and heterogeneity.) But it's not negotiable, >> that's what we are doing in the MANET and Autoconf WGs. The rest of >> everything we do follows from that. > > > I fully agree with this description. Non-transitivity (or "ABC" as > sometimes called in this email thread) is a very basic scenario that > will appear in most MANETs (with at least three routers, which are > not all contained within a single hop). Could we solve that problem by putting two real links instead of a faulty one? Why not? > Of course you could pretend a MANET to be an Ethernet on L2 (as in > IEEE 802.11s). Yes, as in 802.11s, and as in Direct WiFi as a poster often lurker said recently, and as 6lowpan router-over scenario too, and like 802.15.5 too. > But this is not what we are doing in the IETF. So we have to deal > with that case. Actually, here in AUTOCONF of IETF you completely circumvent talking about links. A goal which I sometimes agree with (as I said to Charles - I find that to be ideal), but which I disagree with when one has to do things in practice. I wonder what communication medium will a node use to send a packet to another node - is that a link? Alex > > Ulrich > From Chris.Dearlove@baesystems.com Mon Nov 16 07:35:37 2009 Return-Path: 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 04C7E3A67FA for ; Mon, 16 Nov 2009 07:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] 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 CDbosgSaH6DC for ; Mon, 16 Nov 2009 07:35:36 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id D5EBD3A6767 for ; Mon, 16 Nov 2009 07:35:35 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,751,1249254000"; d="scan'208";a="33209614" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Nov 2009 15:35:34 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAGFZgbA006532; Mon, 16 Nov 2009 15:35:42 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 15:35:34 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Nov 2009 15:35:33 -0000 Message-ID: In-Reply-To: <4B016C41.4080804@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Question regarding use of LLs thread-index: Acpmz3XCZgtCCN2qRWyqat0D4HozwAAAEnEg References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <4B016C41.4080804@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 16 Nov 2009 15:35:34.0214 (UTC) FILETIME=[7006CE60:01CA66D2] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 15:35:37 -0000 It's not open to disagreement. Physics is physics, and the IETF WGs are working on layer 3 solutions. The differences between IPv4 and IPv6 are more detailed issues, that I carefully didn't discuss, and don't affect those two points. The idea that the Autoconf WG shouldn't be linked to the MANET WG is also just not going to fly. Of course that linkage may not be the only linkage, but the whole point of the IETF is to create protocols that all work together. On the specific RFC 2501 point, again the IPv4/IPv6 issues aren't the point, and so what if it predates Wi-Fi? (though I'd have to check that claim). We are not just about 802.11 (another non-negotiable point) and the whole point of RFC 2501 is not to be locked to specific L1/L2 technologies - including ones that hadn't been invented then or even now. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: 16 November 2009 15:14 To: Dearlove, Christopher (UK) Cc: Henning Rogge; autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. I disagree. RFC2501 was written when people were not running IPv6 in their MANETs. The today's widely used WiFi was not available at all in 1999. I also disagree fully with the tight connection between the AUTOCONF work and MANET WG work. Alex Dearlove, Christopher (UK) a =E9crit : >> -is it transitive? Non-transitive? -does it have ABC problem? >> Does it _not_ have ABC problems? >=20 > Let's stop having this raised again and again. In the real world,=20 > with real radios in real deployments, A and B may be able to hear > each other, and B and C may be able to hear each other, but A and C > may not. This is what non-transitive means (it's mathematican speak > for that). End of story, it comes from physics. We need to solve this > problem. You can do it at layer 2, and try to make layer 3 look like > an Ethernet. If so, the IEEE is that way ---> It's a perfectly good=20 > approach (involving solving most of the same problems, but=20 > specialised to particular systems) but it's not what we are doing in > the IETF, which is doing it at layer 3. If you want to know why, the > IETF answer is in RFC 2501. (The short version is layer 1/2 > independence and heterogeneity.) But it's not negotiable, that's what > we are doing in the MANET and Autoconf WGs. The rest of everything we > do follows from that. >=20 > ********************************************************************=20 > This email and any attachments are confidential to the intended=20 > recipient and may also be privileged. If you are not the intended=20 > recipient please delete it from your system and notify the sender.=20 > You should not copy it or use it for any purpose nor disclose or=20 > distribute its contents to any other person.=20 > ******************************************************************** >=20 >=20 From Chris.Dearlove@baesystems.com Mon Nov 16 07:43:19 2009 Return-Path: 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 7BB7A28C172 for ; Mon, 16 Nov 2009 07:43:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599] 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 mpFqw9jQLxp5 for ; Mon, 16 Nov 2009 07:43:18 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 76ACA28C128 for ; Mon, 16 Nov 2009 07:43:18 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,751,1249254000"; d="scan'208";a="33211786" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Nov 2009 15:43:17 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAGFhOaY012112; Mon, 16 Nov 2009 15:43:24 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 15:43:16 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Nov 2009 15:43:15 -0000 Message-ID: In-Reply-To: <4B016F60.4050000@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Question regarding use of LLs thread-index: Acpm0VDNT+x8+t91Qreqnuh8FQPXgwAATxcQ References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161107.12792.henning.rogge@fkie.fraunhofer.de> <4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <25c114b90911160722i4f0a64d1l33db5b4dc543707d@mail.gmail.com> <4B016F60.4050000@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Ulrich Herberg" X-OriginalArrivalTime: 16 Nov 2009 15:43:16.0830 (UTC) FILETIME=[83C467E0:01CA66D3] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 15:43:19 -0000 > Could we solve that problem by putting two real links instead of a > faulty one? Why not? Here's the reality. Deploy users/devices. There are a mixture of good links, bad links, and no links between radios. We try to use the good links, try to use the bad links only where we have to, and where there aren't links we use other routes. Sometimes we have the luxury of moving or otherwise changing our users so that there are more useful good links, but often we don't. (Bit of a problem if where we'd like a relay is where the fire is, or in open ground in a combat situation, or even just on land that belongs to someone else.) But we always have some missing links, except in the highly degenerate case where everyone is all together, and we don't need a MANET. And missing links means non-transitivity. That's the problem that isn't open to being argued away. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Mon Nov 16 07:44:24 2009 Return-Path: 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 5F25D3A6978 for ; Mon, 16 Nov 2009 07:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 SWK-6Yk-Pcxx for ; Mon, 16 Nov 2009 07:44:23 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id 65B6E3A6A86 for ; Mon, 16 Nov 2009 07:44:23 -0800 (PST) Received: by fxm7 with SMTP id 7so5883872fxm.29 for ; Mon, 16 Nov 2009 07:44:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.153.197 with SMTP id l5mr1108398bkw.109.1258386258126; Mon, 16 Nov 2009 07:44:18 -0800 (PST) In-Reply-To: <4B016F60.4050000@gmail.com> References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161107.12792.henning.rogge@fkie.fraunhofer.de> <4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <25c114b90911160722i4f0a64d1l33db5b4dc543707d@mail.gmail.com> <4B016F60.4050000@gmail.com> Date: Mon, 16 Nov 2009 16:44:17 +0100 Message-ID: <25c114b90911160744y51ca2e0bs894451d0eca7dc6b@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 15:44:24 -0000 On Mon, Nov 16, 2009 at 4:27 PM, Alexandru Petrescu wrote: > [...] >> I fully agree with this description. Non-transitivity (or "ABC" as >> sometimes called in this email thread) is a very basic scenario that wil= l >> appear in most MANETs (with at least three routers, which are >> not all contained within a single hop). > > Could we solve that problem by putting two real links instead of a > faulty one? =A0Why not? I am not sure I understand that question... We are dealing with L3, so we cannot easily solve that problem on L2 (such as bridges). >> Of course you could pretend a MANET to be an Ethernet on L2 (as in >> IEEE 802.11s). > > Yes, as in 802.11s, =A0and as in Direct WiFi as a poster often lurker sai= d > recently, and as 6lowpan router-over scenario too, and like 802.15.5 too. That may all be possible. But in AUTOCONF (and MANET) WG of IETF, we deal with multi-hop connectivity on L3 and do not assume any particular L2. As for 6lowpan, I have some doubts about their router-over scenario, but this is not an issue in this mailing list. >> But this is not what we are doing in the IETF. So we have to deal >> with that case. > > Actually, here in AUTOCONF of IETF you completely circumvent talking > about links. =A0A goal which I sometimes agree with (as I said to Charles > - I find that to be ideal), but which I disagree with when one has to do > things in practice. > > I wonder what communication medium will a node use to send a packet to > another node - is that a link? see above ("we deal with multi-hop connectivity on L3 and do not assume any particular L2") Ulrich From alexandru.petrescu@gmail.com Mon Nov 16 07:46:30 2009 Return-Path: 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 6DA4A3A6AA7 for ; Mon, 16 Nov 2009 07:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.050, 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 zYHEu9paf3d4 for ; Mon, 16 Nov 2009 07:46:29 -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 6B6233A6AA1 for ; Mon, 16 Nov 2009 07:46:29 -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-2.0) with ESMTP id nAGFkF7g025103 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 16:46:15 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGFkFl5013537; Mon, 16 Nov 2009 16:46:15 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAGFkEBQ006559; Mon, 16 Nov 2009 16:46:15 +0100 Message-ID: <4B0173C6.9090305@gmail.com> Date: Mon, 16 Nov 2009 16:46:14 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <4B016C41.4080804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 15:46:30 -0000 Dearlove, Christopher (UK) a écrit : > It's not open to disagreement. Don't hope for consensus then. Alex > Physics is physics, and the > IETF WGs are working on layer 3 solutions. The differences > between IPv4 and IPv6 are more detailed issues, that I > carefully didn't discuss, and don't affect those two points. > > The idea that the Autoconf WG shouldn't be linked to the > MANET WG is also just not going to fly. Of course that > linkage may not be the only linkage, but the whole point > of the IETF is to create protocols that all work together. > > On the specific RFC 2501 point, again the IPv4/IPv6 issues > aren't the point, and so what if it predates Wi-Fi? (though > I'd have to check that claim). We are not just about 802.11 > (another non-negotiable point) and the whole point of RFC > 2501 is not to be locked to specific L1/L2 technologies > - including ones that hadn't been invented then or even now. > From alexandru.petrescu@gmail.com Mon Nov 16 07:53:01 2009 Return-Path: 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 4AEA23A691F for ; Mon, 16 Nov 2009 07:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.044, 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 Q+qGV9H9HGRh for ; Mon, 16 Nov 2009 07:53:00 -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 3D3443A67D3 for ; Mon, 16 Nov 2009 07:52:59 -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-2.0) with ESMTP id nAGFqtmY000626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 16:52:55 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGFqtXR018234; Mon, 16 Nov 2009 16:52:55 +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 nAGFqsFw025280; Mon, 16 Nov 2009 16:52:55 +0100 Message-ID: <4B017556.3030508@gmail.com> Date: Mon, 16 Nov 2009 16:52:54 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161107.12792.henning.rogge@fkie.fraunhofer.de> <4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <25c114b90911160722i4f0a64d1l33db5b4dc543707d@mail.gmail.com> <4B016F60.4050000@gmail.com> <25c114b90911160744y51ca2e0bs894451d0eca7dc6b@mail.gmail.com> In-Reply-To: <25c114b90911160744y51ca2e0bs894451d0eca7dc6b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 15:53:01 -0000 Ulrich Herberg a écrit : > On Mon, Nov 16, 2009 at 4:27 PM, Alexandru Petrescu > wrote: >> [...] >>> I fully agree with this description. Non-transitivity (or "ABC" >>> as sometimes called in this email thread) is a very basic >>> scenario that will appear in most MANETs (with at least three >>> routers, which are not all contained within a single hop). >> Could we solve that problem by putting two real links instead of a >> faulty one? Why not? > > I am not sure I understand that question... We are dealing with L3, > so we cannot easily solve that problem on L2 (such as bridges). Ok, no bridges; can we have B to be a router which IP forwards between two pure 4861-links? In this way, instead of calling it one ABC-problem link we call it two no-problem 4861-links. >>> Of course you could pretend a MANET to be an Ethernet on L2 (as >>> in IEEE 802.11s). >> >> Yes, as in 802.11s, and as in Direct WiFi as a poster often lurker >> said recently, and as 6lowpan router-over scenario too, and like >> 802.15.5 too. > > That may all be possible. But in AUTOCONF (and MANET) WG of IETF, we > deal with multi-hop connectivity on L3 and do not assume any > particular L2. As for 6lowpan, I have some doubts about their > router-over scenario, but this is not an issue in this mailing list. Right, 6lowpan route-over could be clarified too. >>> But this is not what we are doing in the IETF. So we have to deal >>> with that case. >> Actually, here in AUTOCONF of IETF you completely circumvent >> talking about links. A goal which I sometimes agree with (as I >> said to Charles - I find that to be ideal), but which I disagree >> with when one has to do things in practice. >> >> I wonder what communication medium will a node use to send a packet >> to another node - is that a link? > > see above ("we deal with multi-hop connectivity on L3 and do not > assume any particular L2") But IPv6 does assume and define a link. Why don't you want to? rfc4861 doesn't assume a particular L2 either, but does go in detail and defines a link. Most of rfc4861 happens on such a link, it's natural to need to define it. Alex From alexandru.petrescu@gmail.com Mon Nov 16 08:24:40 2009 Return-Path: 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 18FE63A68C6 for ; Mon, 16 Nov 2009 08:24:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.040, 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 tMqNwBgmWXHB for ; Mon, 16 Nov 2009 08:24:39 -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 0481B3A6AE3 for ; Mon, 16 Nov 2009 08:24:38 -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-2.0) with ESMTP id nAGGOV7I003694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 17:24:31 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGGOVNB030741; Mon, 16 Nov 2009 17:24:31 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAGGOUZu028669; Mon, 16 Nov 2009 17:24:31 +0100 Message-ID: <4B017CBE.3090506@gmail.com> Date: Mon, 16 Nov 2009 17:24:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <4B016C41.4080804@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 16:24:40 -0000 Dearlove, Christopher (UK) a écrit : > It's not open to disagreement. Physics is physics, and the IETF WGs > are working on layer 3 solutions. The differences between IPv4 and > IPv6 are more detailed issues, that I carefully didn't discuss, and > don't affect those two points. > > The idea that the Autoconf WG shouldn't be linked to the MANET WG is > also just not going to fly. Of course that linkage may not be the > only linkage, but the whole point of the IETF is to create protocols > that all work together. Right, an AUTOCONF protocol will not work if it requires /128 (exclusively!) prefixes configured on interfaces. > On the specific RFC 2501 point, again the IPv4/IPv6 issues aren't the > point, RFC2501 was issued at a time when IPv4 link-local addresses didn't exist either. > and so what if it predates Wi-Fi? If it predates WiFi it means it doesn't know about the WiFi problems and WiFi experience. Moreover, rfc2501 MANETs don't talk ABC (hidden terminal) problem, nor transitivity nor asymmetry problems. > (though I'd have to check that claim). Sure, to be more precise, I think cards tagged "WiFi" appeared on the market in 2000. I think the first widely available 802.11b document was published in 2000. Even if we consider 1999 to be close enough to 2000, it's hard to imagine there was such widespread experience with wifi as it is now, and that rfc2501 benefitted from wide review from wifi users. > We are not just about 802.11 (another non-negotiable point) and the > whole point of RFC 2501 is not to be locked to specific L1/L2 > technologies - including ones that hadn't been invented then or even > now. I agree with this goal, in general. In particular, we should say which links. Alex From hrogge@googlemail.com Mon Nov 16 08:32:57 2009 Return-Path: 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 9A6C328C191 for ; Mon, 16 Nov 2009 08:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 rBAn46kH2gOo for ; Mon, 16 Nov 2009 08:32:56 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.155]) by core3.amsl.com (Postfix) with ESMTP id 7A9333A6903 for ; Mon, 16 Nov 2009 08:32:56 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so2198926fga.13 for ; Mon, 16 Nov 2009 08:32:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=6Xhi7e+bkWgMGopyitlrVVK+gyzO332RNfXDQzaV+fk=; b=NvhwOxbzHcyKAycLGHsnCXa54NP2DikOvT0XYJg0hLwMQ8drpyBBPBrMz4rHRYkHd+ ZL6vyGXGYZ6iR1a0+dpLKtUY5pm9UBZumk3QlyToU9VyfPsZINtJJqkWxWvHJc9AOFKc Sp18EC4VI20D5nfkWbeKI7ei5RFxRZLbdbqA8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=gfXZoXCWukfsl2VwG1ucU8bxI3qOGH9y2f02aCF1MrUGN799ymD31TAuPbOOrTIOyM WcEanjTSYqi6E9v7xIYJUvESqyi1eJDWK8j2MW00kDIzgLHvp5NYrNHmn0Q0VeVmZs84 RqHKDf6Tc45FQidaWdI+ydroGAggrgp+w5qWg= Received: by 10.86.10.4 with SMTP id 4mr1958302fgj.6.1258389171544; Mon, 16 Nov 2009 08:32:51 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id d8sm5069834fga.23.2009.11.16.08.32.50 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 08:32:50 -0800 (PST) From: Henning Rogge To: autoconf@ietf.org Date: Mon, 16 Nov 2009 17:32:45 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B0173C6.9090305@gmail.com> In-Reply-To: <4B0173C6.9090305@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart35956783.Ov2buyHWmo"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911161732.49592.hrogge@googlemail.com> Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 16:32:57 -0000 --nextPart35956783.Ov2buyHWmo Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Montag 16 November 2009 16:46:14 schrieb Alexandru Petrescu: > Dearlove, Christopher (UK) a =E9crit : > > It's not open to disagreement. >=20 > Don't hope for consensus then. We will not even have a discussion about it. The attributes of wireless communication links (especially the non- transitivity of connectivity) is a property of physics. Unless you plan to= =20 rewrite physics there is not much you can do about it I think. IPv6 assumes that if you have someone in linklocal range (unicast or=20 multicast), you have all of his linklocal neighbors (on the same interface)= =20 yourself in linklocal range too. Wireless networks don't work this way, get= =20 over it. The only thing we can do is a) try to ignore it, cross fingers and hope we will never run in a linkloca= l=20 collision at two-hop range b) warn the users that the IPv6 specifications might lead to strange things= in=20 wireless networks c) work on protocolls and algorithms to create linklocal IPs that are a lit= tle=20 bit tighter than necessary, so we can guarantee that they will always be=20 linklocal in our mesh networks. There are sollutions for part c), so I don't worry about it. But they are n= ot=20 "just use RFC 4861 and be done with it". Henning Rogge --nextPart35956783.Ov2buyHWmo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAksBfrEACgkQcenvcwAcHWcmjgCeKxyAokbG5fpAKvxnpfTqSukU mR4AnjqtqkqY+GPuJZpKX/LMHiLJVn87 =JMEu -----END PGP SIGNATURE----- --nextPart35956783.Ov2buyHWmo-- From sratliff@cisco.com Mon Nov 16 08:35:24 2009 Return-Path: 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 6069528C195 for ; Mon, 16 Nov 2009 08:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 RVB6KUEeTtcC for ; Mon, 16 Nov 2009 08:35:23 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 5984628C18F for ; Mon, 16 Nov 2009 08:35:23 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAMcNAUutJV2a/2dsb2JhbACcA6N6lmiCOYIDBIFt X-IronPort-AV: E=Sophos;i="4.44,751,1249257600"; d="scan'208";a="68265885" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 16 Nov 2009 16:35:21 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id nAGGZL2L000531; Mon, 16 Nov 2009 16:35:21 GMT Received: from xmb-rcd-108.cisco.com ([72.163.62.150]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 10:35:21 -0600 Received: from 64.102.54.119 ([64.102.54.119]) by XMB-RCD-108.cisco.com ([72.163.62.150]) with Microsoft Exchange Server HTTP-DAV ; Mon, 16 Nov 2009 16:35:21 +0000 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Mon, 16 Nov 2009 11:35:25 -0500 From: sratliff To: Alexandru Petrescu , "Dearlove, Christopher (UK)" Message-ID: Thread-Topic: [Autoconf] Question regarding use of LLs Thread-Index: Acpm2sxNBA0UdXyTMUWP73yXF61A8w== In-Reply-To: <4B017CBE.3090506@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 16 Nov 2009 16:35:21.0352 (UTC) FILETIME=[CA20A080:01CA66DA] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 16:35:24 -0000 On 11/16/09 11:24 AM, "Alexandru Petrescu" wrote: > Dearlove, Christopher (UK) a =E9crit : >> It's not open to disagreement. Physics is physics, and the IETF WGs >> are working on layer 3 solutions. The differences between IPv4 and >> IPv6 are more detailed issues, that I carefully didn't discuss, and >> don't affect those two points. >>=20 >> The idea that the Autoconf WG shouldn't be linked to the MANET WG is >> also just not going to fly. Of course that linkage may not be the >> only linkage, but the whole point of the IETF is to create protocols >> that all work together. >=20 > Right, an AUTOCONF protocol will not work if it requires /128 > (exclusively!) prefixes configured on interfaces. >=20 Once again, this is utter nonsense. I refer you to section 6.2 of the draft= , second bullet :=20 "A subnet prefix configured on this interface should be of length /128." It says should. Not "must". I fail to understand why you continue to argue that this "exclusively" requires /128 prefixes. It is obviously, patently FALSE.=20 Stan >> On the specific RFC 2501 point, again the IPv4/IPv6 issues aren't the >> point, >=20 > RFC2501 was issued at a time when IPv4 link-local addresses didn't exist > either. >=20 >> and so what if it predates Wi-Fi? >=20 > If it predates WiFi it means it doesn't know about the WiFi problems and > WiFi experience. >=20 > Moreover, rfc2501 MANETs don't talk ABC (hidden terminal) problem, nor > transitivity nor asymmetry problems. >=20 >> (though I'd have to check that claim). >=20 > Sure, to be more precise, I think cards tagged "WiFi" appeared on the > market in 2000. >=20 > I think the first widely available 802.11b document was published in 2000= . >=20 > Even if we consider 1999 to be close enough to 2000, it's hard to > imagine there was such widespread experience with wifi as it is now, and > that rfc2501 benefitted from wide review from wifi users. >=20 >> We are not just about 802.11 (another non-negotiable point) and the >> whole point of RFC 2501 is not to be locked to specific L1/L2 >> technologies - including ones that hadn't been invented then or even >> now. >=20 > I agree with this goal, in general. >=20 > In particular, we should say which links. >=20 > Alex >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Mon Nov 16 08:49:25 2009 Return-Path: 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 449E63A6AC2 for ; Mon, 16 Nov 2009 08:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.036, 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 lptvBgZV2irH for ; Mon, 16 Nov 2009 08:49:24 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 36C5B3A6839 for ; Mon, 16 Nov 2009 08:49:24 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAGGnHeQ011409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 17:49:17 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGGnGqb002901; Mon, 16 Nov 2009 17:49:17 +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 nAGGnF6x016515; Mon, 16 Nov 2009 17:49:16 +0100 Message-ID: <4B01828B.6060907@gmail.com> Date: Mon, 16 Nov 2009 17:49:15 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: sratliff References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 16:49:25 -0000 sratliff a écrit : > > > On 11/16/09 11:24 AM, "Alexandru Petrescu" > wrote: > >> Dearlove, Christopher (UK) a écrit : >>> It's not open to disagreement. Physics is physics, and the IETF >>> WGs are working on layer 3 solutions. The differences between >>> IPv4 and IPv6 are more detailed issues, that I carefully didn't >>> discuss, and don't affect those two points. >>> >>> The idea that the Autoconf WG shouldn't be linked to the MANET WG >>> is also just not going to fly. Of course that linkage may not be >>> the only linkage, but the whole point of the IETF is to create >>> protocols that all work together. >> Right, an AUTOCONF protocol will not work if it requires /128 >> (exclusively!) prefixes configured on interfaces. >> > > Once again, this is utter nonsense. I refer you to section 6.2 of the > draft, second bullet : "A subnet prefix configured on this interface > should be of length /128." > > It says should. Not "must". I fail to understand why you continue to > argue that this "exclusively" requires /128 prefixes. It is > obviously, patently FALSE How does one interpret that "should /128" when all interfaces are configured with the "fe80::/10" prefix out-of-the-box? What does "should prefix length /128" mean with respect to SLAAC: does it mean we have little chance of ever running SLAAC on an AUTOCONF node (SLAAC uses Interface Identifiers of length /64, thus prefix lengths /64)? Moreover - why do you transform the necessity of host-based routes (/128 as prefix length in the routing table, which is ok) into an unnecessary "should" /128 prefix assigned on an interface? Where does this necessity come from? Alex > > Stan > > >>> On the specific RFC 2501 point, again the IPv4/IPv6 issues aren't >>> the point, >> RFC2501 was issued at a time when IPv4 link-local addresses didn't >> exist either. >> >>> and so what if it predates Wi-Fi? >> If it predates WiFi it means it doesn't know about the WiFi >> problems and WiFi experience. >> >> Moreover, rfc2501 MANETs don't talk ABC (hidden terminal) problem, >> nor transitivity nor asymmetry problems. >> >>> (though I'd have to check that claim). >> Sure, to be more precise, I think cards tagged "WiFi" appeared on >> the market in 2000. >> >> I think the first widely available 802.11b document was published >> in 2000. >> >> Even if we consider 1999 to be close enough to 2000, it's hard to >> imagine there was such widespread experience with wifi as it is >> now, and that rfc2501 benefitted from wide review from wifi users. >> >>> We are not just about 802.11 (another non-negotiable point) and >>> the whole point of RFC 2501 is not to be locked to specific L1/L2 >>> technologies - including ones that hadn't been invented then or >>> even now. >> I agree with this goal, in general. >> >> In particular, we should say which links. >> >> Alex >> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From Chris.Dearlove@baesystems.com Mon Nov 16 08:59:46 2009 Return-Path: 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 8048128C15A for ; Mon, 16 Nov 2009 08:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599] 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 bM6lojJdRzID for ; Mon, 16 Nov 2009 08:59:45 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 6A0323A6AE3 for ; Mon, 16 Nov 2009 08:59:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,752,1249254000"; d="scan'208";a="33234498" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Nov 2009 16:59:44 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAGGxpmT001597; Mon, 16 Nov 2009 16:59:51 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 16:59:43 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 16 Nov 2009 16:59:42 -0000 Message-ID: In-Reply-To: <4B0173C6.9090305@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Question regarding use of LLs thread-index: Acpm0/N75p+nJoaeSr+r8SA5nIoAEgAChwEA References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <4B016C41.4080804@gmail.com> <4B0173C6.9090305@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 16 Nov 2009 16:59:43.0762 (UTC) FILETIME=[31CAAF20:01CA66DE] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 16:59:46 -0000 There already is not just broad, but overwhelming consensus for the following points that are the only ones I was making: - MANETs have physical link properties that are non-transitive (or however you want to word it). - The IETF is working on L3 MANET protocols. - The Autoconf and MANET WGs work is directly related. Note that broad consensus is not the same as unanimity, but it's actually pretty close in this case. --=20 Christopher Dearlove Technology Leader, Communications Group Networks, Security and Information Systems Department BAE Systems Advanced Technology Centre West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK Tel: +44 1245 242194 Fax: +44 1245 242124 BAE Systems (Operations) Limited Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered in England & Wales No: 1996687 -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 Sent: 16 November 2009 15:46 To: Dearlove, Christopher (UK) Cc: Alexandru Petrescu; Henning Rogge; autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs *** WARNING *** This message has originated outside your organisation, either from an external partner or the Global Internet.=20 Keep this in mind if you answer this message. Dearlove, Christopher (UK) a =E9crit : > It's not open to disagreement. Don't hope for consensus then. Alex > Physics is physics, and the > IETF WGs are working on layer 3 solutions. The differences > between IPv4 and IPv6 are more detailed issues, that I > carefully didn't discuss, and don't affect those two points. >=20 > The idea that the Autoconf WG shouldn't be linked to the > MANET WG is also just not going to fly. Of course that > linkage may not be the only linkage, but the whole point > of the IETF is to create protocols that all work together. >=20 > On the specific RFC 2501 point, again the IPv4/IPv6 issues > aren't the point, and so what if it predates Wi-Fi? (though > I'd have to check that claim). We are not just about 802.11 > (another non-negotiable point) and the whole point of RFC > 2501 is not to be locked to specific L1/L2 technologies > - including ones that hadn't been invented then or even now. >=20 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Mon Nov 16 09:03:26 2009 Return-Path: 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 A63C028C187 for ; Mon, 16 Nov 2009 09:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=-0.033, 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 G0pAPup3eWWx for ; Mon, 16 Nov 2009 09:03:25 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 7D42828C15A for ; Mon, 16 Nov 2009 09:03:25 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAGH3LHS029132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 18:03:21 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGH3Lmk005265; Mon, 16 Nov 2009 18:03:21 +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 nAGH3KJF020526; Mon, 16 Nov 2009 18:03:20 +0100 Message-ID: <4B0185D8.1030402@gmail.com> Date: Mon, 16 Nov 2009 18:03:20 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B0173C6.9090305@gmail.com> <200911161732.49592.hrogge@googlemail.com> In-Reply-To: <200911161732.49592.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 17:03:26 -0000 Henning Rogge a écrit : > Am Montag 16 November 2009 16:46:14 schrieb Alexandru Petrescu: >> Dearlove, Christopher (UK) a écrit : >>> It's not open to disagreement. >> Don't hope for consensus then. > We will not even have a discussion about it. > > The attributes of wireless communication links (especially the non- > transitivity of connectivity) is a property of physics. Unless you > plan to rewrite physics there is not much you can do about it I > think. I don't plan to rewrite physics laws more than you plan to re-write IPv6 and Internet. > IPv6 assumes that if you have someone in linklocal range (unicast or > multicast), you have all of his linklocal neighbors (on the same > interface) yourself in linklocal range too. Wireless networks don't > work this way, get over it. Well I know some wireless links which work that way: 802.11b, 802.16 (when they are properly set up). > The only thing we can do is a) try to ignore it, cross fingers and > hope we will never run in a linklocal collision at two-hop range Well - if the two-hop range is two 4861-links then the link-local addressed packets do not get forwarded, so no collision risk. > b) warn the users that the IPv6 specifications might lead to strange > things in wireless networks I think your warning will fall on my definitely deaf AUTOCONF ears. > c) work on protocolls and algorithms to create linklocal IPs that are > a little bit tighter than necessary, so we can guarantee that they > will always be linklocal in our mesh networks. This sounds like new contributions to the IPv6 Addressing Architecture RFC, which could easily be qualified as re-writing the Internet rules. > There are sollutions for part c), so I don't worry about it. But they > are not "just use RFC 4861 and be done with it". Right, I don't mean to say that. The current task is to desribe a practical addressing model. "/128" is not practical, discouraging LLs is not practical either. You have all upside down in this document: the main recommendations go against any practical aspects, which are then left as exceptions, corner cases, non-wireless, etc. I want link-local addresses to be first-class citizens in AUTOCONF, not some corner case. I want the "prefix /128 on interface" suggestion to be an exception. Maybe, I say maybe, the "/128" prefixlen in the routing table for host-based routes to be a MAY. I want the AUTOCONF document to define "link". And to name the links on which it run as example. And to list the protocols which require the use link-local addresses. That for my wishlist :-) Alex From alexandru.petrescu@gmail.com Mon Nov 16 09:05:29 2009 Return-Path: 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 CC0FD3A6AEA for ; Mon, 16 Nov 2009 09:05:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=-0.031, 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 bVKbvazDLjUb for ; Mon, 16 Nov 2009 09:05:29 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id D282328C194 for ; Mon, 16 Nov 2009 09:05:28 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAGH5K1h021028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 18:05:20 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGH5K9S005646; Mon, 16 Nov 2009 18:05:20 +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 nAGH5J0V021205; Mon, 16 Nov 2009 18:05:20 +0100 Message-ID: <4B01864F.7020201@gmail.com> Date: Mon, 16 Nov 2009 18:05:19 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <4B016C41.4080804@gmail.com> <4B0173C6.9090305@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 17:05:29 -0000 Dearlove, Christopher (UK) a écrit : > There already is not just broad, but overwhelming consensus > for the following points that are the only ones I was making: > > - MANETs have physical link properties that are non-transitive > (or however you want to word it). > - The IETF is working on L3 MANET protocols. > - The Autoconf and MANET WGs work is directly related. > > Note that broad consensus is not the same as unanimity, but > it's actually pretty close in this case. Well feel free to exclude me from your consensus. I will be happy go working in another WG. Alex From Chris.Dearlove@baesystems.com Mon Nov 16 09:06:16 2009 Return-Path: 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 257AD3A6AD7 for ; Mon, 16 Nov 2009 09:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599] 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 ckO0-GUdEJRT for ; Mon, 16 Nov 2009 09:06:15 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 2B7FE3A6997 for ; Mon, 16 Nov 2009 09:06:15 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,752,1249254000"; d="scan'208";a="33236070" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Nov 2009 17:06:14 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAGH6Lh4005889; Mon, 16 Nov 2009 17:06:21 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 17:06:13 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Nov 2009 17:06:12 -0000 Message-ID: In-Reply-To: <4B017CBE.3090506@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Question regarding use of LLs thread-index: Acpm2UmwyabvrtH6SI+vsPTvjaLdNQABPelQ References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <4B016C41.4080804@gmail.com> <4B017CBE.3090506@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 16 Nov 2009 17:06:13.0485 (UTC) FILETIME=[1A15B1D0:01CA66DF] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 17:06:16 -0000 > RFC2501 was issued at a time when IPv4 link-local addresses didn't exist > either. So what? I wasn't quoting 2501 with regard to LL addresses, but with regard to doing things at L3. > If it predates WiFi it means it doesn't know about the WiFi problems and > WiFi experience. So what? We're not working on 802.11, we're working on L3 routing. > Moreover, rfc2501 MANETs don't talk ABC (hidden terminal) problem, nor > transitivity nor asymmetry problems. It doesn't spell it out in nit-picking detail, but the transmitivity issue is implicit (and pretty close to explicit using the word "random" in Section 3. Not that that matters, it's not why I referenced 2501. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From Chris.Dearlove@baesystems.com Mon Nov 16 09:09:37 2009 Return-Path: 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 6FE2628C1A3 for ; Mon, 16 Nov 2009 09:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599] 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 2HTVKqwqQlTr for ; Mon, 16 Nov 2009 09:09:36 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 864993A699E for ; Mon, 16 Nov 2009 09:09:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,752,1249254000"; d="scan'208";a="33236662" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 16 Nov 2009 17:09:35 +0000 Received: from glkms1102.GREENLNK.NET (glkms1102.greenlnk.net [10.108.36.193]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAGH9gV1007811; Mon, 16 Nov 2009 17:09:43 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1102.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Mon, 16 Nov 2009 17:09:34 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 16 Nov 2009 17:09:33 -0000 Message-ID: In-Reply-To: <4B0185D8.1030402@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Question regarding use of LLs thread-index: Acpm3rcZ/GfvTzQ2TT2uM5TKwJ/7LQAAJWZA References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B0173C6.9090305@gmail.com> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> From: "Dearlove, Christopher (UK)" To: "Alexandru Petrescu" , "Henning Rogge" X-OriginalArrivalTime: 16 Nov 2009 17:09:34.0859 (UTC) FILETIME=[921CEDB0:01CA66DF] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 17:09:37 -0000 >> IPv6 assumes that if you have someone in linklocal range (unicast or >> multicast), you have all of his linklocal neighbors (on the same >> interface) yourself in linklocal range too. Wireless networks don't >> work this way, get over it. > Well I know some wireless links which work that way: 802.11b, 802.16 > (when they are properly set up). Nonsense. And that should be (a resolution I will try to keep) my final word on the subject. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From alexandru.petrescu@gmail.com Mon Nov 16 09:10:53 2009 Return-Path: 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 7DF8D3A6AD5 for ; Mon, 16 Nov 2009 09:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=-0.029, 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 sI6iPGrn5b+m for ; Mon, 16 Nov 2009 09:10:52 -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 1C8193A699E for ; Mon, 16 Nov 2009 09:10:51 -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-2.0) with ESMTP id nAGHAhMb023945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 18:10:43 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGHAhuc006718; Mon, 16 Nov 2009 18:10:43 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAGHAgvE010215; Mon, 16 Nov 2009 18:10:43 +0100 Message-ID: <4B018792.3040604@gmail.com> Date: Mon, 16 Nov 2009 18:10:42 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <1258126393.5035.20.camel@acorde.it.uc3m.es><200911161107.12792.henning.rogge@fkie.fraunhofer.de><4B0125CA.6080609@gmail.com> <200911161323.33582.henning.rogge@fkie.fraunhofer.de> <4B015AB5.7040908@gmail.com> <4B016C41.4080804@gmail.com> <4B017CBE.3090506@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 17:10:53 -0000 Dearlove, Christopher (UK) a écrit : >> RFC2501 was issued at a time when IPv4 link-local addresses didn't >> exist either. > > So what? I wasn't quoting 2501 with regard to LL addresses, but with > regard to doing things at L3. Working at L3? Ok, so says the entire IETF, not just one particular RFC. I wonder why you cite RFC2501 in particular as suggestion to work on L3. >> If it predates WiFi it means it doesn't know about the WiFi >> problems and WiFi experience. > > So what? We're not working on 802.11, we're working on L3 routing. I think putting the "/128" in the prefixlen field of a routing table entry is a good L3 part to recommend. (and not the current /128 prefix per interface). >> Moreover, rfc2501 MANETs don't talk ABC (hidden terminal) problem, >> nor transitivity nor asymmetry problems. > > It doesn't spell it out in nit-picking detail, but the transmitivity > issue is implicit (and pretty close to explicit using the word > "random" in Section 3. Not that that matters, it's not why I > referenced 2501. One can use that use of the word "random" to motivate about anything one would like to. Alex > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > From alexandru.petrescu@gmail.com Mon Nov 16 09:15:19 2009 Return-Path: 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 6715428C1BD for ; Mon, 16 Nov 2009 09:15:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.276 X-Spam-Level: X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=-0.027, 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 YWom6XXAQytD for ; Mon, 16 Nov 2009 09:15:14 -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 386A33A681A for ; Mon, 16 Nov 2009 09:15:14 -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-2.0) with ESMTP id nAGHFAWr004748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2009 18:15:10 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAGHFAKr007401; Mon, 16 Nov 2009 18:15:10 +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 nAGHF9Je023918; Mon, 16 Nov 2009 18:15:10 +0100 Message-ID: <4B01889D.7040702@gmail.com> Date: Mon, 16 Nov 2009 18:15:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Dearlove, Christopher (UK)" References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B0173C6.9090305@gmail.com> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 17:15:19 -0000 Dearlove, Christopher (UK) a écrit : >>> IPv6 assumes that if you have someone in linklocal range (unicast >>> or multicast), you have all of his linklocal neighbors (on the >>> same interface) yourself in linklocal range too. Wireless >>> networks don't work this way, get over it. > >> Well I know some wireless links which work that way: 802.11b, >> 802.16 (when they are properly set up). > > Nonsense. Is this nonsense qualifier also relying on the rfc2501 use of the word random? Or do you have some actual facts about how IPv6 does _not_ work on 802.11b? Because I state the opposite: IPv6 works on 802.11b, link-local addresses _are_ used and shorter than 128 prefixes are the common case of prefix assigned on an interface. This is not a game of words, it's how it is in my view. Alex > > And that should be (a resolution I will try to keep) my final word on > the subject. > > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** > > From thomas@thomasclausen.org Mon Nov 16 09:23:24 2009 Return-Path: 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 E6ACE3A6AE7 for ; Mon, 16 Nov 2009 09:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 FQFKrKahDfeB for ; Mon, 16 Nov 2009 09:23:24 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 312F93A69D5 for ; Mon, 16 Nov 2009 09:23:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 8B9054300D8; Mon, 16 Nov 2009 09:23:23 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.130.3.92] (4.234.241.83.in-addr.dgcsystems.net [83.241.234.4]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id C388C430196; Mon, 16 Nov 2009 09:23:21 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B01889D.7040702@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Nov 2009 18:23:18 +0100 References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B0173C6.9090305@gmail.com> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <4B01889D.7040702@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 17:23:25 -0000 On Nov 16, 2009, at 6:15 PM, Alexandru Petrescu wrote: > Dearlove, Christopher (UK) a =E9crit : >>>> IPv6 assumes that if you have someone in linklocal range (unicast >>>> or multicast), you have all of his linklocal neighbors (on the >>>> same interface) yourself in linklocal range too. Wireless >>>> networks don't work this way, get over it. >>> Well I know some wireless links which work that way: 802.11b, >>> 802.16 (when they are properly set up). >> Nonsense. > > Is this nonsense qualifier also relying on the rfc2501 use of the word > random? > > Or do you have some actual facts about how IPv6 does _not_ work on > 802.11b? Because I state the opposite: IPv6 works on 802.11b, > link-local addresses _are_ used and shorter than 128 prefixes are the > common case of prefix assigned on an interface. > Alex, Without knowing anything about your deployments, what you say above =20 makes me absolutely certain that IEEE 802.11b, in the mode you have =20 been deploying it, is NOT a multihop ad hoc network nor a MANET. Thomas > This is not a game of words, it's how it is in my view. > > Alex > >> And that should be (a resolution I will try to keep) my final word on >> the subject. >> ******************************************************************** = This=20 >> email and any attachments are confidential to the intended =20 >> recipient and may also be privileged. If you are not the intended =20 >> recipient please delete it from your system and notify the sender. =20= >> You should not copy it or use it for any purpose nor disclose or =20 >> distribute its contents to any other person. =20 >> ******************************************************************** > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From hrogge@googlemail.com Mon Nov 16 09:24:45 2009 Return-Path: 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 8C52328C1C8 for ; Mon, 16 Nov 2009 09:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 2uHeEugD0qWI for ; Mon, 16 Nov 2009 09:24:44 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 1026C28C0FF for ; Mon, 16 Nov 2009 09:24:43 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id d23so2219701fga.13 for ; Mon, 16 Nov 2009 09:24:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=p48M3GAOmeUCk6Ed94ERmBVZdmZsouRcaxe9Ya2UfjA=; b=t2f7edITqOShTdJkJ7Wq4vsQ4h6vrrjPCvc3Mw3MgTIyMuURlJpX5qxlJ3elgXTdoH ipQ2uQWbsslOPx4jF3IMfbxqF3HYfb3U5hBQvD6Xc1Z9VzjJDmduFYQwDzdRjqsx+NOv Xp+g2Te12qX/elpF/vYL8M+0gxELOjKQIZPos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=WqMx4KBEs0YipT2RRzCL/KquzCUkZnc0Q22MT7PWYESbxNwNqREfqSdk/+/Q0BZI4C OJtppYpK8jMjQw0LC2cpRjcvv7p1WcaKFZzsx7dF34opacNCQ3ZzjN/OOS/AYCYhe8B+ mss0xwM5DVFEfEfBZg2tt5I2Ceiu/hevHaWzQ= Received: by 10.86.254.17 with SMTP id b17mr2562417fgi.65.1258392278093; Mon, 16 Nov 2009 09:24:38 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id d6sm5167913fga.0.2009.11.16.09.24.36 (version=SSLv3 cipher=RC4-MD5); Mon, 16 Nov 2009 09:24:37 -0800 (PST) From: Henning Rogge To: Alexandru Petrescu Date: Mon, 16 Nov 2009 18:24:31 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> In-Reply-To: <4B0185D8.1030402@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1569920.i7abMVhtNt"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911161824.36424.hrogge@googlemail.com> Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 17:24:45 -0000 --nextPart1569920.i7abMVhtNt Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Am Montag 16 November 2009 18:03:20 schrieb Alexandru Petrescu: > > The attributes of wireless communication links (especially the non- > > transitivity of connectivity) is a property of physics. Unless you > > plan to rewrite physics there is not much you can do about it I > > think. >=20 > I don't plan to rewrite physics laws more than you plan to re-write IPv6 > and Internet. Yes you do, but you don't notice (yes I know you would give me/us the same= =20 answer). =20 > > IPv6 assumes that if you have someone in linklocal range (unicast or > > multicast), you have all of his linklocal neighbors (on the same > > interface) yourself in linklocal range too. Wireless networks don't > > work this way, get over it. >=20 > Well I know some wireless links which work that way: 802.11b, 802.16 > (when they are properly set up). No they don't... especially not in Adhoc mode. You don't setup LINKS in 802.11, you set up a node and get connectivity wit= h=20 everyone else in range. Unless you want to limit 802.11 to directional=20 point-2-point connections, there is no way to avoid the not-transitive=20 connection thing. =20 > > The only thing we can do is a) try to ignore it, cross fingers and > > hope we will never run in a linklocal collision at two-hop range >=20 > Well - if the two-hop range is two 4861-links then the link-local > addressed packets do not get forwarded, so no collision risk. The problem is not forwarding. In the ABC case everything seems to be fine = for=20 A and C, even if they have choosen the same linklocal-IP. Noone in linkloca= l- range of them has the same IP. But B communicates with BOTH OF THEM on the same interface, so he has two=20 linklocal-range neighbors who have chosen the same linklocal-IP for their=20 interface. So B cannot use the IP to communicate with A and C. > > b) warn the users that the IPv6 specifications might lead to strange > > things in wireless networks >=20 > I think your warning will fall on my definitely deaf AUTOCONF ears. So what ? If you come back complaining that one of your 1000 IPv6-Autoconf= =20 networks did behave badly we can say "we warned you". ;) =20 > > c) work on protocolls and algorithms to create linklocal IPs that are > > a little bit tighter than necessary, so we can guarantee that they > > will always be linklocal in our mesh networks. >=20 > This sounds like new contributions to the IPv6 Addressing Architecture > RFC, which could easily be qualified as re-writing the Internet rules. If the whole internet will become a mesh network with only wireless links w= e=20 might do so. The IPv6 ND will work most of the times, because the random part of the=20 linklocal IP is HUGE. So you will have to wait a long time before you get a= =20 collision. But you might get one. Especially in a MOBILE adhoc network. Henning Rogge --nextPart1569920.i7abMVhtNt Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAksBitQACgkQcenvcwAcHWf5sACeJjfh23pghGV6DDuEOTO8KI0u uzYAnRcjC3v9+kxACeRpILu80wdXndTl =gqvK -----END PGP SIGNATURE----- --nextPart1569920.i7abMVhtNt-- From alexandru.petrescu@gmail.com Mon Nov 16 11:28:43 2009 Return-Path: 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 001D128C10D for ; Mon, 16 Nov 2009 11:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 L2wNY20vDGYP for ; Mon, 16 Nov 2009 11:28:42 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id E84263A69F4 for ; Mon, 16 Nov 2009 11:28:40 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id A4748D481B2; Mon, 16 Nov 2009 20:28:34 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 143ACD48220; Mon, 16 Nov 2009 20:28:30 +0100 (CET) Message-ID: <4B01A7DC.7020500@gmail.com> Date: Mon, 16 Nov 2009 20:28:28 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B0173C6.9090305@gmail.com> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <4B01889D.7040702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091116-0, 16/11/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Which MANET? (Was: Question regarding use of LLs) X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 19:28:43 -0000 Thomas Heide Clausen a écrit : > > On Nov 16, 2009, at 6:15 PM, Alexandru Petrescu wrote: > >> Dearlove, Christopher (UK) a écrit : >>>>> IPv6 assumes that if you have someone in linklocal range >>>>> (unicast or multicast), you have all of his linklocal >>>>> neighbors (on the same interface) yourself in linklocal range >>>>> too. Wireless networks don't work this way, get over it. >>>> Well I know some wireless links which work that way: 802.11b, >>>> 802.16 (when they are properly set up). >>> Nonsense. >> >> Is this nonsense qualifier also relying on the rfc2501 use of the >> word random? >> >> Or do you have some actual facts about how IPv6 does _not_ work on >> 802.11b? Because I state the opposite: IPv6 works on 802.11b, >> link-local addresses _are_ used and shorter than 128 prefixes are >> the common case of prefix assigned on an interface. >> > > Alex, > > Without knowing anything about your deployments, what you say above > makes me absolutely certain that IEEE 802.11b, in the mode you have > been deploying it, is NOT a multihop ad hoc network nor a MANET. ThomasC - is that with the Chair hat on or off? I think you should be sure before talking MANETs in general. Because: -RFC2501 MANETs are not OLSR MANETs which are not DYMO MANETs which are not AUTOCONF networks. -the OLSR MANET is _not_ the 6lowpan MANET, and is not the RoLL MANET either. -your MANETs are not personX's MANETs. -Finally, and very importantly: your MANETs are not personY's MANETs. (personX and Y active in this WG). That's why I suppose your hat was not on :-) In this sense - which MANET are we talking about? Can we define what "MANET" means? I think it would be useful. (about the networks I deploy - they are multi-IPhop networks (Hop Limit field gets decremented), with one 802.11b ad-hoc link (has link-local scope, supports link-layer multicast) in between which uses exclusively link-local addresses; the src and dst of the communication ends are not link-local; but the link-local addresses in the ad-hoc link are very important and easy to use, in order to have the entire network work. Don't discourage that. Also, I don't use /128 prefixes on the interfaces, and I don't use /128 host-based routes but aggregated routes into /64 prefixes. Don't discourage that either.) Alex > > Thomas > > >> This is not a game of words, it's how it is in my view. >> >> Alex >> >>> And that should be (a resolution I will try to keep) my final >>> word on the subject. >>> ******************************************************************** >>> This email and any attachments are confidential to the intended >>> recipient and may also be privileged. If you are not the intended >>> recipient please delete it from your system and notify the >>> sender. You should not copy it or use it for any purpose nor >>> disclose or distribute its contents to any other person. >>> ******************************************************************** >>> >>> >> >> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Mon Nov 16 12:05:19 2009 Return-Path: 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 1669728C187 for ; Mon, 16 Nov 2009 12:05:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[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 Y52kKp7F7sgD for ; Mon, 16 Nov 2009 12:05:18 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id C213228C0E2 for ; Mon, 16 Nov 2009 12:05:16 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 122D1D48118; Mon, 16 Nov 2009 21:05:10 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 90807D4805A; Mon, 16 Nov 2009 21:05:07 +0100 (CET) Message-ID: <4B01B071.6090702@gmail.com> Date: Mon, 16 Nov 2009 21:05:05 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <200911161824.36424.hrogge@googlemail.com> In-Reply-To: <200911161824.36424.hrogge@googlemail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091116-0, 16/11/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 20:05:19 -0000 Henning Rogge a écrit : > Am Montag 16 November 2009 18:03:20 schrieb Alexandru Petrescu: >>> The attributes of wireless communication links (especially the >>> non- transitivity of connectivity) is a property of physics. >>> Unless you plan to rewrite physics there is not much you can do >>> about it I think. >> I don't plan to rewrite physics laws more than you plan to re-write >> IPv6 and Internet. > > Yes you do, but you don't notice (yes I know you would give me/us the > same answer). Let's say I place my view higher above the physics laws (PHY) than you do. >>> IPv6 assumes that if you have someone in linklocal range (unicast >>> or multicast), you have all of his linklocal neighbors (on the >>> same interface) yourself in linklocal range too. Wireless >>> networks don't work this way, get over it. >> >> Well I know some wireless links which work that way: 802.11b, >> 802.16 (when they are properly set up). > > No they don't... especially not in Adhoc mode. > > You don't setup LINKS in 802.11, you set up a node and get > connectivity with everyone else in range. That's right - it becomes a link. Everyone in range of my device and my device form a link. That's fully deterministic. The size of that range is specified. That link supports link-layer multicast, has link-local scope, doesn't have ABC problem, is transitive. > Unless you want to limit 802.11 to directional point-2-point > connections, there is no way to avoid the not-transitive connection > thing. Well, I disagree - a link formed by devices within a certain precise range from my device is not a ptp link, supports link-layer multicast and is transitive. >>> The only thing we can do is a) try to ignore it, cross fingers >>> and hope we will never run in a linklocal collision at two-hop >>> range >> Well - if the two-hop range is two 4861-links then the link-local >> addressed packets do not get forwarded, so no collision risk. > > The problem is not forwarding. In the ABC case everything seems to be > fine for A and C, even if they have choosen the same linklocal-IP. > Noone in linklocal- range of them has the same IP. I see what you mean. But look at it otherwise: If the maximum distance (range) between any two pairs of A, B and C is the standardized 802.11b limit then there is no ABC problem and no non-transitive issue. Right? If the distance between any of the two is larger than the 802.11b standardized limit then don't presume you have a normally behaving link. > But B communicates with BOTH OF THEM on the same interface, I don't understand this restriction - why a single interface on B? If having a single interface creates problems then add another one. If you had two 50m Ethernet Category5 cables and three machines - wouldn't you create the same problem (Ethernet length is also standardized) - yet nobody tells IP doesn't run on Ethernet. > so he has two linklocal-range neighbors who have chosen the same > linklocal-IP for their interface. So B cannot use the IP to > communicate with A and C. Well, I wouldn't expect A, B and C to consider they have a working link between them if any of the two is outside the specified range. You were saying A and C were not in range, right? So why would A and C consider they had a link between them? I think your problem of connecting two remote machines through an intermediary close to both is really nothing new and we shouldn't spend any cycle on it. I mean two IP machines with a router in between does that. >>> b) warn the users that the IPv6 specifications might lead to >>> strange things in wireless networks >> I think your warning will fall on my definitely deaf AUTOCONF ears. >> > > So what ? If you come back complaining that one of your 1000 > IPv6-Autoconf networks did behave badly we can say "we warned you". > ;) No no, I am deaf :-) I tell you why. Whenever considering a 1000somethings bigger something one has to structure them. And the first setp in structuring is to use deterministic links. Also, whenever considering 1000nodes, there surely will exist _some_ nodes which are given little more functionalities. I expect these to have several interfaces. Besides, there's no one single human who could deploy alone a working 1000node IP network. >>> c) work on protocolls and algorithms to create linklocal IPs that >>> are a little bit tighter than necessary, so we can guarantee that >>> they will always be linklocal in our mesh networks. >> >> This sounds like new contributions to the IPv6 Addressing >> Architecture RFC, which could easily be qualified as re-writing the >> Internet rules. > > If the whole internet will become a mesh network with only wireless > links we might do so. I think I am very much scared to hear you expect the Internet to become a mesh network. I am scared because I believe it already is a mesh network and thus I don't know what you want to do. > The IPv6 ND will work most of the times, because the random part of > the linklocal IP is HUGE. So you will have to wait a long time before > you get a collision. But you might get one. Especially in a MOBILE > adhoc network. Hmmm, I am not afraid, DAD will help me detect the duplicates n 100% cases. There are literally milions of MOBILE devices connected to the Internet. Sometimes they are also literally ad-hoc, i.e. unplanned. Recently an unplanned connection of a MOBILE device generated a huge euro bill. Imagine the easiness of using that MOBILE device that its owner didn't even realize it's on a different (more expensive) network. The IP connection setup worked ok, the IP address changed, etc. yet the owner didn't even notice. Is that unplanned (i.e. adhoc) and MOBILE enough? Alex From ulrich@herberg.name Mon Nov 16 12:23:12 2009 Return-Path: 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 0F3ED3A690E for ; Mon, 16 Nov 2009 12:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 TGbl30Cnryxg for ; Mon, 16 Nov 2009 12:23:11 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 107AF3A67A1 for ; Mon, 16 Nov 2009 12:23:10 -0800 (PST) Received: by bwz23 with SMTP id 23so6184469bwz.29 for ; Mon, 16 Nov 2009 12:23:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.25.71 with SMTP id y7mr4486965bkb.67.1258402986629; Mon, 16 Nov 2009 12:23:06 -0800 (PST) In-Reply-To: <4B01B071.6090702@gmail.com> References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <200911161824.36424.hrogge@googlemail.com> <4B01B071.6090702@gmail.com> Date: Mon, 16 Nov 2009 21:23:06 +0100 Message-ID: <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> From: Ulrich Herberg To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 20:23:12 -0000 Alex, On Mon, Nov 16, 2009 at 9:05 PM, Alexandru Petrescu wrote: >[...] > I see what you mean. > > But look at it otherwise: > > If the maximum distance (range) between any two pairs of A, B and C is > the standardized 802.11b limit then there is no ABC problem and no > non-transitive issue. =A0Right? But why do you need a MANET for that case? I would call that IBSS mode, you don't need any routing then. > If the distance between any of the two is larger than the 802.11b > standardized limit then don't presume you have a normally behaving link. This is called MANET (i.e. multi-hop communicaiton). Do you seriously suggest to limit a MANET to the size of your living room? How would you deploy a MANET like the one from FunkFeuer? (several hundreds of routers in Vienna, over a huge area)? Or a military network? > >> But B communicates with BOTH OF THEM on the same interface, > > I don't understand this restriction - why a single interface on B? =A0If > having a single interface creates problems then add another one. So you suggest to add an interface for every neighbor in the worst case? How many interfaces would you suggest to have on every router then? > [...] Ulrich From alexandru.petrescu@gmail.com Mon Nov 16 13:11:15 2009 Return-Path: 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 C2A9328C1F0 for ; Mon, 16 Nov 2009 13:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.042 X-Spam-Level: X-Spam-Status: No, score=-1.042 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, 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 dt8m5z4zkz-A for ; Mon, 16 Nov 2009 13:11:14 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 9D57E28C1FF for ; Mon, 16 Nov 2009 13:11:13 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4D729D481B6; Mon, 16 Nov 2009 22:11:06 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 04E03D480A3; Mon, 16 Nov 2009 22:11:03 +0100 (CET) Message-ID: <4B01BFE5.6080300@gmail.com> Date: Mon, 16 Nov 2009 22:11:01 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <200911161824.36424.hrogge@googlemail.com> <4B01B071.6090702@gmail.com> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> In-Reply-To: <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091116-0, 16/11/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 21:11:15 -0000 Ulrich Herberg a écrit : > Alex, > > On Mon, Nov 16, 2009 at 9:05 PM, Alexandru Petrescu > wrote: >> [...] I see what you mean. >> >> But look at it otherwise: >> >> If the maximum distance (range) between any two pairs of A, B and C >> is the standardized 802.11b limit then there is no ABC problem and >> no non-transitive issue. Right? > > But why do you need a MANET for that case? I would call that IBSS > mode, you don't need any routing then. Right, that forms a single deterministic 4861-link, no IP routing within it. It's already great to have it. Its only disadvantage may be its relatively small 50m range; but knowing that a single 50m cable could connect only two machines, a 50m wifi range connecting tens of computers is much more advantageous. >> If the distance between any of the two is larger than the 802.11b >> standardized limit then don't presume you have a normally behaving >> link. > > This is called MANET (i.e. multi-hop communicaiton). Are you saying a MANET is a network which presumes it doesn't have normally behaving links? DO you mean a MANET never works ok? About MANET being "multi-hop communications" - let's agree that multi-hop communications happened and continue to happen completely independent of what MANET is or becomes. First, multi-hop is what 6lowpan and RoLL call too, yet avoiding the word MANET. Second, multi-hop is what happens in the Internet at-large. Internet is a huge mesh of wired and wireless links all stitched together by IP. Why do you want to call multi-hop communications "MANET"? > Do you seriously suggest to limit a MANET to the size of your living > room? Well, no, my living room size is smaller than 50m :-) I don't see a MANET larger than 50m using exclusively 1-interface routers. That doesn't scale IMHO. Of course, you could have independent overlapping islands of wifi unknown links, but a fully connected network doesn't scale very large when only 1-interface routers are used, for sure. Do you know how many interfaces a DFZ router has? > How would you deploy a MANET like the one from FunkFeuer? (several > hundreds of routers in Vienna, over a huge area)? "FunkFeuer"(?) Did FunkFeuer ever claim each of their hundreds Vienna routers is a one-interface router? > Or a military network? Military? Secret. Not IETF. >>> But B communicates with BOTH OF THEM on the same interface, >> I don't understand this restriction - why a single interface on B? >> If having a single interface creates problems then add another one. >> >> >> > > So you suggest to add an interface for every neighbor in the worst > case? How many interfaces would you suggest to have on every router > then? It's not necessary for a router to have a distinct interface for every neighbor. It is necessary to have at least two interfaces on wifi routers placed at the 50m borders. In terms of number of interfaces overall, one worst wifi case would be a linear deployment with each node within 50m from the next, no closer. That would require 2 interfaces on each router except the first and last. But that's a particular case I don't see happening. The types of physically linear deployments I know of are half wired half wireless and are currently dealt with with mostly star topologies (e.g. networks of IP speedcams along highways, or bus stop IP displays, IP Access Points in metro/bus stations, IP Access Points in public parks). Alex > > >> [...] > > Ulrich > From teco@inf-net.nl Mon Nov 16 13:44:53 2009 Return-Path: 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 177963A688B for ; Mon, 16 Nov 2009 13:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.025 X-Spam-Level: *** X-Spam-Status: No, score=3.025 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 G3LWrIIl69f6 for ; Mon, 16 Nov 2009 13:44:52 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id EBEFF3A6964 for ; Mon, 16 Nov 2009 13:44:51 -0800 (PST) Received: (qmail 13707 invoked from network); 16 Nov 2009 22:44:46 +0100 Received: from unknown (HELO M90Teco) (62.140.137.97) by server9.hosting2go.nl with SMTP; 16 Nov 2009 22:44:46 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <200911161824.36424.hrogge@googlemail.com> <4B01B071.6090702@gmail.com> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> In-Reply-To: <4B01BFE5.6080300@gmail.com> Date: Mon, 16 Nov 2009 22:44:07 +0100 Message-ID: <009601ca6706$014d0550$03e70ff0$@nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcpnAVao3wanMUdqQti5jeuH2RZ/nAAA1eGg Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 21:44:53 -0000 >>> If the maximum distance (range) between any two pairs of A, B and C >>> is the standardized 802.11b limit then there is no ABC problem and >>> no non-transitive issue. Right? >Right, that forms a single deterministic 4861-link, no IP routing within >it. It's already great to have it. Its only disadvantage may be its > relatively small 50m range; but knowing that a single 50m cable could >connect only two machines, a 50m wifi range connecting tens of computers >is much more advantageous. >>> If the distance between any of the two is larger than the 802.11b >>> standardized limit then don't presume you have a normally behaving >>> link. I preferred not take part of this discussion. But reading so much opinions that are beside facts, I encourage everybody reading the bloody specs. E.g. 802.11-2007 page 27: For wireless PHYs, well-defined coverage areas simply do not exist. Propagation characteristics are dynamic and unpredictable. Small changes in position or direction may result in dramatic differences in signal strength. Similar effects occur whether a STA is stationary or mobile (as moving objects may impact station-to-station propagation). We could introduce moving teapots again :-) Teco. From alexandru.petrescu@gmail.com Mon Nov 16 15:14:05 2009 Return-Path: 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 2DA313A6878 for ; Mon, 16 Nov 2009 15:14:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_50=0.001, 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 d2AqXDxM1Nj7 for ; Mon, 16 Nov 2009 15:14:04 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 214493A67D7 for ; Mon, 16 Nov 2009 15:14:02 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id D4923D4803E; Tue, 17 Nov 2009 00:13:57 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id AF9F1D4808E; Tue, 17 Nov 2009 00:13:54 +0100 (CET) Message-ID: <4B01DCB0.4070703@gmail.com> Date: Tue, 17 Nov 2009 00:13:52 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Teco Boot References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <200911161824.36424.hrogge@googlemail.com> <4B01B071.6090702@gmail.com> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <009601ca6706$014d0550$03e70ff0$@nl> In-Reply-To: <009601ca6706$014d0550$03e70ff0$@nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091116-1, 16/11/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] practical coverage areas, PHY unknowns and user manuals (was: Question regarding use of LLs) X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 23:14:05 -0000 Teco Boot a écrit : >>>> If the maximum distance (range) between any two pairs of A, B >>>> and C is the standardized 802.11b limit then there is no ABC >>>> problem and no non-transitive issue. Right? > >> Right, that forms a single deterministic 4861-link, no IP routing >> within it. It's already great to have it. Its only disadvantage >> may be its relatively small 50m range; but knowing that a single >> 50m cable could connect only two machines, a 50m wifi range >> connecting tens of computers is much more advantageous. > >>>> If the distance between any of the two is larger than the >>>> 802.11b standardized limit then don't presume you have a >>>> normally behaving link. > > I preferred not take part of this discussion. But reading so much > opinions that are beside facts, I encourage everybody reading the > bloody specs. E.g. 802.11-2007 page 27: For wireless PHYs, > well-defined coverage areas simply do not exist. Propagation > characteristics are dynamic and unpredictable. Small changes in > position or direction may result in dramatic differences in signal > strength. Similar effects occur whether a STA is stationary or mobile > (as moving objects may impact station-to-station propagation). Hmmm... Teco, I agree the wireless PHYs are full of surprises to... PHY layer. But take me the average wifi user, with a wifi manual on my laps and here's what I see: "radio range (approximately 60 metres)". That's my hands-on experience of wifi adhoc mode. Moreover, I believe it is regulated worldwide. Of course, add to that some millimeter-wave kitchen ovens, de-ionized atmosphere and obstacles and PHY becomes suddenly unstable. I believe kitchen ovens will affect the "/128 prefix on interface" recommendation too. When a very badly tuned oven is running near an AUTOCONF router the use of "/128 prefix on the interface" will not improve the communication. Only turning that oven off will improve it. Add to it a range-extension antenna, a clear sunny day, turn the power knob to max, break the regulation laws, and all of a sudden we have huge PHY coverage in the order of kilometers, as reported in the O'Reilly 802.11 book, 2002 - practical experience. Totally independent of /128 prefixes or /64 prefixes on interface, or of LL recommendations, and of any routing protocol. It's just a bigger and stronger PHY layer. PHY or not PHY... IP or not IP. > We could introduce moving teapots again :-) :-) sounds interesting but what's it refering to? Alex > > Teco. > > > > From clint.chaplin@gmail.com Mon Nov 16 15:34:01 2009 Return-Path: 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 CE6B83A6B47 for ; Mon, 16 Nov 2009 15:34:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 IzWKlasTg9zj for ; Mon, 16 Nov 2009 15:34:00 -0800 (PST) Received: from mail-pw0-f50.google.com (mail-pw0-f50.google.com [209.85.160.50]) by core3.amsl.com (Postfix) with ESMTP id BBC523A6A01 for ; Mon, 16 Nov 2009 15:34:00 -0800 (PST) Received: by pwi6 with SMTP id 6so3859814pwi.29 for ; Mon, 16 Nov 2009 15:33:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DKS7mqdqYbQCSzD/uzy4BuKCsJZ+WHGyYOuQxAXP1bw=; b=omhJlDmPR0P92xy9gvWMW2Upr5VAXD/8mP3RXDPQS9BCgwAkQUvNOgTKFXWqKlQR2y OQ4C2zfRCF/11+VD0qvHIIQ5gxZ8m2P3ifqkX8gOFasE+SFsBOOtWm1CUWQxsDpfV+0F V1iWHZUWfwIdSRGnXm8+8a6+yIGNB8WO5Vol8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Ky5yJC4HU9itzE7tt/1k+FceRxvVSk20uGxOQ5jIcgNoAGqhbw9gbc2cO8vVp/E8rU edYF17uYMmupe+8VGTDB5vsPLcgwPRfbMoavYZq18qNyOST0Cw+xN0h1U9MaRKgvd8f/ UxZib473WZ92Gj+6XUFn2Wl0ocow475fFu2og= MIME-Version: 1.0 Received: by 10.142.55.11 with SMTP id d11mr779442wfa.334.1258414436594; Mon, 16 Nov 2009 15:33:56 -0800 (PST) In-Reply-To: <4B01B071.6090702@gmail.com> References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <200911161824.36424.hrogge@googlemail.com> <4B01B071.6090702@gmail.com> Date: Mon, 16 Nov 2009 15:33:55 -0800 Message-ID: From: Clint Chaplin To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Mon, 16 Nov 2009 23:34:01 -0000 "standardized IEEE 802.11b limit"? I don't believe that IEEE 802.11b has a limit in the standard. If you can hear each other, you go for it. And, different geos allow different maximum output power. On Mon, Nov 16, 2009 at 12:05 PM, Alexandru Petrescu wrote: > Henning Rogge a =E9crit : >> >> Am Montag 16 November 2009 18:03:20 schrieb Alexandru Petrescu: >>>> >>>> The attributes of wireless communication links (especially the >>>> non- transitivity of connectivity) is a property of physics. >>>> Unless you plan to rewrite physics there is not much you can do >>>> about it I think. >>> >>> I don't plan to rewrite physics laws more than you plan to re-write >>> IPv6 and Internet. >> >> Yes you do, but you don't notice (yes I know you would give me/us the >> same answer). > > Let's say I place my view higher above the physics laws (PHY) than you do= . > >>>> IPv6 assumes that if you have someone in linklocal range (unicast >>>> or multicast), you have all of his linklocal neighbors (on the >>>> same interface) yourself in linklocal range too. Wireless >>>> networks don't work this way, get over it. >>> >>> Well I know some wireless links which work that way: 802.11b, >>> 802.16 (when they are properly set up). >> >> No they don't... especially not in Adhoc mode. >> >> You don't setup LINKS in 802.11, you set up a node and get >> connectivity with everyone else in range. > > That's right - it becomes a link. =A0Everyone in range of my device and m= y > device form a link. =A0That's fully deterministic. =A0The size of that ra= nge > is specified. =A0That link supports link-layer multicast, has link-local > scope, doesn't have ABC problem, is transitive. > >> Unless you want to limit 802.11 to directional point-2-point >> connections, there is no way to avoid the not-transitive connection >> thing. > > Well, I disagree - a link formed by devices within a certain precise > range from my device is not a ptp link, supports link-layer multicast > and is transitive. > >>>> The only thing we can do is a) try to ignore it, cross fingers >>>> and hope we will never run in a linklocal collision at two-hop >>>> range >>> >>> Well - if the two-hop range is two 4861-links then the link-local >>> addressed packets do not get forwarded, so no collision risk. >> >> The problem is not forwarding. In the ABC case everything seems to be >> fine for A and C, even if they have choosen the same linklocal-IP. >> Noone in linklocal- range of them has the same IP. > > I see what you mean. > > But look at it otherwise: > > If the maximum distance (range) between any two pairs of A, B and C is > the standardized 802.11b limit then there is no ABC problem and no > non-transitive issue. =A0Right? > > If the distance between any of the two is larger than the 802.11b > standardized limit then don't presume you have a normally behaving link. > >> But B communicates with BOTH OF THEM on the same interface, > > I don't understand this restriction - why a single interface on B? =A0If > having a single interface creates problems then add another one. > > If you had two 50m Ethernet Category5 cables and three machines - > wouldn't you create the same problem (Ethernet length is also > standardized) - yet nobody tells IP doesn't run on Ethernet. > >> so he has two linklocal-range neighbors who have chosen the same >> linklocal-IP for their interface. So B cannot use the IP to >> communicate with A and C. > > Well, I wouldn't expect A, B and C to consider they have a working link > between them if any of the two is outside the specified range. =A0You > were saying A and C were not in range, right? =A0So why would A and C > consider they had a link between them? > > I think your problem of connecting two remote machines through an > intermediary close to both is really nothing new and we shouldn't spend > any cycle on it. =A0I mean two IP machines with a router in between does = that. > >>>> b) warn the users that the IPv6 specifications might lead to >>>> strange things in wireless networks >>> >>> I think your warning will fall on my definitely deaf AUTOCONF ears. >>> >> >> So what ? If you come back complaining that one of your 1000 >> IPv6-Autoconf networks did behave badly we can say "we warned you". >> ;) > > No no, I am deaf :-) > > I tell you why. > > Whenever considering a 1000somethings bigger something one has to > structure them. =A0And the first setp in structuring is to use > deterministic links. > > Also, whenever considering 1000nodes, there surely will exist _some_ node= s > which are given little more functionalities. =A0I expect these to have se= veral > interfaces. > > Besides, there's no one single human who could deploy alone a working > 1000node IP network. > >>>> c) work on protocolls and algorithms to create linklocal IPs that >>>> are a little bit tighter than necessary, so we can guarantee that >>>> they will always be linklocal in our mesh networks. >>> >>> This sounds like new contributions to the IPv6 Addressing >>> Architecture RFC, which could easily be qualified as re-writing the >>> Internet rules. >> >> If the whole internet will become a mesh network with only wireless >> links we might do so. > > I think I am very much scared to hear you expect the Internet to become > a mesh network. =A0I am scared because I believe it already is a mesh > network and thus I don't know what you want to do. > >> The IPv6 ND will work most of the times, because the random part of >> the linklocal IP is HUGE. So you will have to wait a long time before >> you get a collision. But you might get one. Especially in a MOBILE >> adhoc network. > > Hmmm, I am not afraid, DAD will help me detect the duplicates n 100% case= s. > > There are literally milions of MOBILE devices connected to the Internet. > > Sometimes they are also literally ad-hoc, i.e. unplanned. =A0Recently an > unplanned connection of a MOBILE device generated a huge euro bill. > Imagine the easiness of using that MOBILE device that its owner didn't > even realize it's on a different (more expensive) network. =A0The IP > connection setup worked ok, the IP address changed, etc. yet the owner > didn't even notice. =A0Is that unplanned (i.e. adhoc) and MOBILE enough? > > Alex > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > --=20 Clint (JOATMON) Chaplin Principal Engineer Corporate Standardization (US) SISA From henning.rogge@fkie.fraunhofer.de Mon Nov 16 22:31:40 2009 Return-Path: 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 587393A6784 for ; Mon, 16 Nov 2009 22:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 Sg2HOt6Pfco0 for ; Mon, 16 Nov 2009 22:31:39 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 9FF333A6928 for ; Mon, 16 Nov 2009 22:31:38 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAHbB-0000TL-Gj; Tue, 17 Nov 2009 07:31:33 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAHbB-00021X-7H; Tue, 17 Nov 2009 07:31:33 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 17 Nov 2009 07:31:24 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> In-Reply-To: <4B01BFE5.6080300@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1271609.KyqQi2jT6u"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911170731.29359.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10030/Tue Nov 17 03:38:41 2009) by mailguard.fgan.de X-Scan-Signature: 03aa31d695fb3eb984fab57667d62e5a Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 06:31:40 -0000 --nextPart1271609.KyqQi2jT6u Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mon November 16 2009 22:11:01 Alexandru Petrescu wrote: > > How would you deploy a MANET like the one from FunkFeuer? (several > > hundreds of routers in Vienna, over a huge area)? >=20 > "FunkFeuer"(?) Did FunkFeuer ever claim each of their hundreds Vienna > routers is a one-interface router? Most of them are one-hop routers. I would say more than 70%, Maybe even mor= e. Berlin had even a higher percentage of 1-interface routers in their 700+ no= de=20 network for years. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1271609.KyqQi2jT6u Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksCQzwACgkQRIfGfFXsz+DBPwCeN3iIcgf7izH9fHJwr27pLaTM 0mcAnRrnRvFhJ0eesg+qILJ3kHyL85EW =uhF7 -----END PGP SIGNATURE----- --nextPart1271609.KyqQi2jT6u-- From teco@inf-net.nl Mon Nov 16 23:38:56 2009 Return-Path: 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 F1FF33A6A83 for ; Mon, 16 Nov 2009 23:38:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.075 X-Spam-Level: X-Spam-Status: No, score=0.075 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_40=-0.185, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_LOW=-1] 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 FqQZuXyb+jLi for ; Mon, 16 Nov 2009 23:38:56 -0800 (PST) Received: from server9.hosting2go.nl (server9.hosting2go.nl [83.137.194.84]) by core3.amsl.com (Postfix) with ESMTP id 9985D3A6820 for ; Mon, 16 Nov 2009 23:38:55 -0800 (PST) Received: (qmail 12805 invoked from network); 17 Nov 2009 08:38:52 +0100 Received: from static.kpn.net (HELO M90Teco) (77.61.241.196) by server9.hosting2go.nl with SMTP; 17 Nov 2009 08:38:52 +0100 From: "Teco Boot" To: "'Alexandru Petrescu'" References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <200911161824.36424.hrogge@googlemail.com> <4B01B071.6090702@gmail.com> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <009601ca6706$014d0550$03e70ff0$@nl> <4B01DCB0.4070703@gmail.com> In-Reply-To: <4B01DCB0.4070703@gmail.com> Date: Tue, 17 Nov 2009 08:38:17 +0100 Message-ID: <003001ca6758$ffa07810$fee16830$@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: AcpnEn5U9INwu0LSQ6aKlmogWXdFcgAQzmMQ Content-Language: nl Cc: autoconf@ietf.org Subject: Re: [Autoconf] practical coverage areas, PHY unknowns and user manuals (was: Question regarding use of LLs) X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 07:38:57 -0000 Alex, We IETF work on standards. We cooperate with the IEEE 802 communities,=20 including 802.11. This WLAN specification is evolving and nowadays it support range extension in the spec (section 17.1, the 10MHz and=20 5MHz channels). With high gain antennas, 300km links were set up. I expect they did not reduce TXpower, so it may be illegal. But by reducing the TXpower, a set up with two high gain antennas enlarges the link range without breaking laws. 5km should not be a problem. Moreover, there are plenty of communities that have their own licensed or protected spectrum. I am involved in those communities, and 20km = links=20 or more is no problem, using 802.11 based equipment. But at the same time, I experience connectivity problems due to foliage, teapots or=20 whatever. 50meters can be two teapots too far. Am I right you admit we shall stay away from PHY details in Autoconf? To fresh up your memory, read postings of exactly 2 years ago, e.g.: http://www.ietf.org/mail-archive/web/autoconf/current/msg00746.html Your text: It appears too exhausting to describe each and every scenario,=20 right :-) They look as easily mapped from one to another.=20 They're all networks in the end :-) Regards, Teco >-----Oorspronkelijk bericht----- >Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] >Verzonden: dinsdag 17 november 2009 0:14 >Aan: Teco Boot >CC: 'Alexandru Petrescu'; autoconf@ietf.org >Onderwerp: Re: practical coverage areas, PHY unknowns and user manuals >(was: [Autoconf] Question regarding use of LLs) > >Teco Boot a =E9crit : >>>>> If the maximum distance (range) between any two pairs of A, B >>>>> and C is the standardized 802.11b limit then there is no ABC >>>>> problem and no non-transitive issue. Right? >> >>> Right, that forms a single deterministic 4861-link, no IP routing >>> within it. It's already great to have it. Its only disadvantage >>> may be its relatively small 50m range; but knowing that a single >>> 50m cable could connect only two machines, a 50m wifi range >>> connecting tens of computers is much more advantageous. >> >>>>> If the distance between any of the two is larger than the >>>>> 802.11b standardized limit then don't presume you have a >>>>> normally behaving link. >> >> I preferred not take part of this discussion. But reading so much >> opinions that are beside facts, I encourage everybody reading the >> bloody specs. E.g. 802.11-2007 page 27: For wireless PHYs, >> well-defined coverage areas simply do not exist. Propagation >> characteristics are dynamic and unpredictable. Small changes in >> position or direction may result in dramatic differences in signal >> strength. Similar effects occur whether a STA is stationary or mobile >> (as moving objects may impact station-to-station propagation). > >Hmmm... Teco, I agree the wireless PHYs are full of surprises to... PHY >layer. > >But take me the average wifi user, with a wifi manual on my laps and >here's what I see: "radio range (approximately 60 metres)". That's my >hands-on experience of wifi adhoc mode. Moreover, I believe it is >regulated worldwide. > >Of course, add to that some millimeter-wave kitchen ovens, de-ionized >atmosphere and obstacles and PHY becomes suddenly unstable. > >I believe kitchen ovens will affect the "/128 prefix on >interface" recommendation too. When a very badly tuned oven is running >near an AUTOCONF router the use of "/128 prefix on the interface" will >not improve the communication. Only turning that oven off will improve >it. > >Add to it a range-extension antenna, a clear sunny day, turn the power >knob to max, break the regulation laws, and all of a sudden we have = huge >PHY coverage in the order of kilometers, as reported in the O'Reilly >802.11 book, 2002 - practical experience. Totally independent of /128 >prefixes or /64 prefixes on interface, or of LL recommendations, and of >any routing protocol. It's just a bigger and stronger PHY layer. > >PHY or not PHY... IP or not IP. > >> We could introduce moving teapots again :-) > >:-) sounds interesting but what's it refering to? > >Alex > >> >> Teco. >> >> >> >> From henning.rogge@fkie.fraunhofer.de Mon Nov 16 23:43:40 2009 Return-Path: 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 61C373A6B8A for ; Mon, 16 Nov 2009 23:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.924 X-Spam-Level: X-Spam-Status: No, score=-5.924 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 2AT+332CfEad for ; Mon, 16 Nov 2009 23:43:39 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 523403A6820 for ; Mon, 16 Nov 2009 23:43:39 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAIiu-0003T2-Nj; Tue, 17 Nov 2009 08:43:36 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAIiu-0002Jm-Ee; Tue, 17 Nov 2009 08:43:36 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 17 Nov 2009 08:43:23 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B01DCB0.4070703@gmail.com> <003001ca6758$ffa07810$fee16830$@nl> In-Reply-To: <003001ca6758$ffa07810$fee16830$@nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3724947.KZNy1QfF3H"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911170843.29059.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10030/Tue Nov 17 03:38:41 2009) by mailguard.fgan.de X-Scan-Signature: 9cb3f381a8845856dbdf3f2e90234067 Subject: Re: [Autoconf] practical coverage areas, PHY unknowns and user manuals (was: Question regarding use of LLs) X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 07:43:40 -0000 --nextPart3724947.KZNy1QfF3H Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 17 2009 08:38:17 Teco Boot wrote: > Alex, >=20 > We IETF work on standards. We cooperate with the IEEE 802 communities, > including 802.11. This WLAN specification is evolving and nowadays > it support range extension in the spec (section 17.1, the 10MHz and > 5MHz channels). >=20 > With high gain antennas, 300km links were set up. I expect they did > not reduce TXpower, so it may be illegal. But by reducing the TXpower, > a set up with two high gain antennas enlarges the link range without > breaking laws. 5km should not be a problem. Vienna has a legal 20+ km link with 802.11 and directional antennas. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart3724947.KZNy1QfF3H Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksCVBsACgkQRIfGfFXsz+CenACgqiUw7z6VRY0KEZHgV/TLa5R8 E+4Amwev8xc6VHYt0Lt4LIN2lVEJAzlL =wfin -----END PGP SIGNATURE----- --nextPart3724947.KZNy1QfF3H-- From alexandru.petrescu@gmail.com Tue Nov 17 02:08:17 2009 Return-Path: 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 3D54D28C1C9 for ; Tue, 17 Nov 2009 02:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.025, 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 yY5F6LTVQT50 for ; Tue, 17 Nov 2009 02:08:16 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id AE5DD28C0E7 for ; Tue, 17 Nov 2009 02:08:15 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAHA8AL2027007 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 11:08:10 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAHA89GA005403; Tue, 17 Nov 2009 11:08:10 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAHA89ro026679; Tue, 17 Nov 2009 11:08:09 +0100 Message-ID: <4B027608.6020903@gmail.com> Date: Tue, 17 Nov 2009 11:08:08 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Clint Chaplin References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911161732.49592.hrogge@googlemail.com> <4B0185D8.1030402@gmail.com> <200911161824.36424.hrogge@googlemail.com> <4B01B071.6090702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:08:17 -0000 Clint Chaplin a écrit : > "standardized IEEE 802.11b limit"? I don't believe that IEEE 802.11b > has a limit in the standard. Why do the 802.11b user manuals say 50m (150ft) then? Are they wrong? Alex > If you can hear each other, you go for > it. And, different geos allow different maximum output power. > > On Mon, Nov 16, 2009 at 12:05 PM, Alexandru Petrescu > wrote: >> Henning Rogge a écrit : >>> Am Montag 16 November 2009 18:03:20 schrieb Alexandru Petrescu: >>>>> The attributes of wireless communication links (especially the >>>>> non- transitivity of connectivity) is a property of physics. >>>>> Unless you plan to rewrite physics there is not much you can do >>>>> about it I think. >>>> I don't plan to rewrite physics laws more than you plan to re-write >>>> IPv6 and Internet. >>> Yes you do, but you don't notice (yes I know you would give me/us the >>> same answer). >> Let's say I place my view higher above the physics laws (PHY) than you do. >> >>>>> IPv6 assumes that if you have someone in linklocal range (unicast >>>>> or multicast), you have all of his linklocal neighbors (on the >>>>> same interface) yourself in linklocal range too. Wireless >>>>> networks don't work this way, get over it. >>>> Well I know some wireless links which work that way: 802.11b, >>>> 802.16 (when they are properly set up). >>> No they don't... especially not in Adhoc mode. >>> >>> You don't setup LINKS in 802.11, you set up a node and get >>> connectivity with everyone else in range. >> That's right - it becomes a link. Everyone in range of my device and my >> device form a link. That's fully deterministic. The size of that range >> is specified. That link supports link-layer multicast, has link-local >> scope, doesn't have ABC problem, is transitive. >> >>> Unless you want to limit 802.11 to directional point-2-point >>> connections, there is no way to avoid the not-transitive connection >>> thing. >> Well, I disagree - a link formed by devices within a certain precise >> range from my device is not a ptp link, supports link-layer multicast >> and is transitive. >> >>>>> The only thing we can do is a) try to ignore it, cross fingers >>>>> and hope we will never run in a linklocal collision at two-hop >>>>> range >>>> Well - if the two-hop range is two 4861-links then the link-local >>>> addressed packets do not get forwarded, so no collision risk. >>> The problem is not forwarding. In the ABC case everything seems to be >>> fine for A and C, even if they have choosen the same linklocal-IP. >>> Noone in linklocal- range of them has the same IP. >> I see what you mean. >> >> But look at it otherwise: >> >> If the maximum distance (range) between any two pairs of A, B and C is >> the standardized 802.11b limit then there is no ABC problem and no >> non-transitive issue. Right? >> >> If the distance between any of the two is larger than the 802.11b >> standardized limit then don't presume you have a normally behaving link. >> >>> But B communicates with BOTH OF THEM on the same interface, >> I don't understand this restriction - why a single interface on B? If >> having a single interface creates problems then add another one. >> >> If you had two 50m Ethernet Category5 cables and three machines - >> wouldn't you create the same problem (Ethernet length is also >> standardized) - yet nobody tells IP doesn't run on Ethernet. >> >>> so he has two linklocal-range neighbors who have chosen the same >>> linklocal-IP for their interface. So B cannot use the IP to >>> communicate with A and C. >> Well, I wouldn't expect A, B and C to consider they have a working link >> between them if any of the two is outside the specified range. You >> were saying A and C were not in range, right? So why would A and C >> consider they had a link between them? >> >> I think your problem of connecting two remote machines through an >> intermediary close to both is really nothing new and we shouldn't spend >> any cycle on it. I mean two IP machines with a router in between does that. >> >>>>> b) warn the users that the IPv6 specifications might lead to >>>>> strange things in wireless networks >>>> I think your warning will fall on my definitely deaf AUTOCONF ears. >>>> >>> So what ? If you come back complaining that one of your 1000 >>> IPv6-Autoconf networks did behave badly we can say "we warned you". >>> ;) >> No no, I am deaf :-) >> >> I tell you why. >> >> Whenever considering a 1000somethings bigger something one has to >> structure them. And the first setp in structuring is to use >> deterministic links. >> >> Also, whenever considering 1000nodes, there surely will exist _some_ nodes >> which are given little more functionalities. I expect these to have several >> interfaces. >> >> Besides, there's no one single human who could deploy alone a working >> 1000node IP network. >> >>>>> c) work on protocolls and algorithms to create linklocal IPs that >>>>> are a little bit tighter than necessary, so we can guarantee that >>>>> they will always be linklocal in our mesh networks. >>>> This sounds like new contributions to the IPv6 Addressing >>>> Architecture RFC, which could easily be qualified as re-writing the >>>> Internet rules. >>> If the whole internet will become a mesh network with only wireless >>> links we might do so. >> I think I am very much scared to hear you expect the Internet to become >> a mesh network. I am scared because I believe it already is a mesh >> network and thus I don't know what you want to do. >> >>> The IPv6 ND will work most of the times, because the random part of >>> the linklocal IP is HUGE. So you will have to wait a long time before >>> you get a collision. But you might get one. Especially in a MOBILE >>> adhoc network. >> Hmmm, I am not afraid, DAD will help me detect the duplicates n 100% cases. >> >> There are literally milions of MOBILE devices connected to the Internet. >> >> Sometimes they are also literally ad-hoc, i.e. unplanned. Recently an >> unplanned connection of a MOBILE device generated a huge euro bill. >> Imagine the easiness of using that MOBILE device that its owner didn't >> even realize it's on a different (more expensive) network. The IP >> connection setup worked ok, the IP address changed, etc. yet the owner >> didn't even notice. Is that unplanned (i.e. adhoc) and MOBILE enough? >> >> Alex >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> > > > From alexandru.petrescu@gmail.com Tue Nov 17 02:09:09 2009 Return-Path: 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 6729928C212 for ; Tue, 17 Nov 2009 02:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=-0.024, 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 nItsfSw3TA0x for ; Tue, 17 Nov 2009 02:09:08 -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 7484928C205 for ; Tue, 17 Nov 2009 02:09:08 -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-2.0) with ESMTP id nAHA8x9N028358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 11:08:59 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAHA8xSn005627; Tue, 17 Nov 2009 11:08:59 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAHA8wDc027047; Tue, 17 Nov 2009 11:08:59 +0100 Message-ID: <4B027639.6070406@gmail.com> Date: Tue, 17 Nov 2009 11:08:57 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911170731.29359.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:09:09 -0000 Henning Rogge a écrit : > On Mon November 16 2009 22:11:01 Alexandru Petrescu wrote: >>> How would you deploy a MANET like the one from FunkFeuer? (several >>> hundreds of routers in Vienna, over a huge area)? >> "FunkFeuer"(?) Did FunkFeuer ever claim each of their hundreds Vienna >> routers is a one-interface router? > > Most of them are one-hop routers. I would say more than 70%, Maybe even more. I believe you mean one-interface routers. Well I think we should leave place in the specs for the 30% or less routers which have more than one interface then. Alex > > Berlin had even a higher percentage of 1-interface routers in their 700+ node > network for years. > > Henning Rogge > From henning.rogge@fkie.fraunhofer.de Tue Nov 17 02:15:18 2009 Return-Path: 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 0B8F928C105 for ; Tue, 17 Nov 2009 02:15:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.032 X-Spam-Level: X-Spam-Status: No, score=-6.032 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 xyRHxMIyQ2sx for ; Tue, 17 Nov 2009 02:15:17 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id EFF7728C0F7 for ; Tue, 17 Nov 2009 02:15:16 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAL5e-0004OH-8t; Tue, 17 Nov 2009 11:15:14 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAL5d-0003IQ-Va; Tue, 17 Nov 2009 11:15:14 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Tue, 17 Nov 2009 11:15:03 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B027608.6020903@gmail.com> In-Reply-To: <4B027608.6020903@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8226926.kAqRKME90G"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911171115.08128.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10030/Tue Nov 17 03:38:41 2009) by mailguard.fgan.de X-Scan-Signature: 6014c1396d65ef16b120fa0e45ef4f11 Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:15:18 -0000 --nextPart8226926.kAqRKME90G Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 17 2009 11:08:08 Alexandru Petrescu wrote: > Clint Chaplin a =E9crit : > > "standardized IEEE 802.11b limit"? I don't believe that IEEE 802.11b > > has a limit in the standard. >=20 > Why do the 802.11b user manuals say 50m (150ft) then? Are they wrong? It's not a "802.11b user manual" but a manual for a card you can buy. And t= he=20 manufacturer just states a typical distance you can use together with an=20 access point in urban terrain. Because that's (from most manufacturers poin= t=20 of view) is the typical usecase for their cards. The 50m has NOTHING to do with the 802.11 specification. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart8226926.kAqRKME90G Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksCd6cACgkQRIfGfFXsz+Ba2gCfbm5SS7yRDESsOKyGMl29vVGv L7IAnj5ITLUZ2fg2HEcgsVnO5eQ3nm4u =NJfA -----END PGP SIGNATURE----- --nextPart8226926.kAqRKME90G-- From thomas@thomasclausen.org Tue Nov 17 02:16:57 2009 Return-Path: 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 1AEEA28C212 for ; Tue, 17 Nov 2009 02:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 iVGJLdbn7IO8 for ; Tue, 17 Nov 2009 02:16:56 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 2DE8F28C0F8 for ; Tue, 17 Nov 2009 02:16:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 52656430521; Tue, 17 Nov 2009 02:16:41 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.133.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 5AD5D430519; Tue, 17 Nov 2009 02:16:40 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B027639.6070406@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 11:16:38 +0100 References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> <4B027639.6070406@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:16:57 -0000 On Nov 17, 2009, at 11:08 AM, Alexandru Petrescu wrote: > Henning Rogge a =E9crit : >> On Mon November 16 2009 22:11:01 Alexandru Petrescu wrote: >>>> How would you deploy a MANET like the one from FunkFeuer? (several >>>> hundreds of routers in Vienna, over a huge area)? >>> "FunkFeuer"(?) Did FunkFeuer ever claim each of their hundreds =20 >>> Vienna >>> routers is a one-interface router? > > >> Most of them are one-hop routers. I would say more than 70%, Maybe =20= >> even more. > > I believe you mean one-interface routers. > > Well I think we should leave place in the specs for the 30% or less =20= > routers which have more than one interface then. Fortunately, such do not necessitate special treatment at all. Thomas > Alex > >> Berlin had even a higher percentage of 1-interface routers in their =20= >> 700+ node network for years. >> Henning Rogge From henning.rogge@fkie.fraunhofer.de Tue Nov 17 02:16:58 2009 Return-Path: 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 7D10528C216 for ; Tue, 17 Nov 2009 02:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 lXdrGqO27cD6 for ; Tue, 17 Nov 2009 02:16:57 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id CF15728C20F for ; Tue, 17 Nov 2009 02:16:55 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAL7F-0005iS-EE; Tue, 17 Nov 2009 11:16:53 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAL7F-0003JC-3d; Tue, 17 Nov 2009 11:16:53 +0100 From: Henning Rogge To: Alexandru Petrescu Date: Tue, 17 Nov 2009 11:16:43 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> <4B027639.6070406@gmail.com> In-Reply-To: <4B027639.6070406@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1417326.3Cf3aVm1Pl"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911171116.43173.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10030/Tue Nov 17 03:38:41 2009) by mailguard.fgan.de X-Scan-Signature: 6014c1396d65ef16b120fa0e45ef4f11 Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:16:58 -0000 --nextPart1417326.3Cf3aVm1Pl Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 17 2009 11:08:57 Alexandru Petrescu wrote: > > Most of them are one-hop routers. I would say more than 70%, Maybe even > > more. >=20 > I believe you mean one-interface routers. Yes. =20 > Well I think we should leave place in the specs for the 30% or less > routers which have more than one interface then. I would have to ask what's the exact split. Most routers have only one interface because they are typical DSL-WLAN- routers, so they are very cheap. That's a good argument for large scale=20 community networks. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1417326.3Cf3aVm1Pl Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksCeAsACgkQRIfGfFXsz+COPACdEiiZlSKKtl/9Vm1ZauT3v2rc dfgAn2IURXh9jvt39YY8CJCu9VR4u4q2 =KHx3 -----END PGP SIGNATURE----- --nextPart1417326.3Cf3aVm1Pl-- From alexandru.petrescu@gmail.com Tue Nov 17 02:22:50 2009 Return-Path: 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 25DF93A691D for ; Tue, 17 Nov 2009 02:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.271 X-Spam-Level: X-Spam-Status: No, score=-2.271 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 0bum0e3KyqEE for ; Tue, 17 Nov 2009 02:22:49 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 22C843A686D for ; Tue, 17 Nov 2009 02:22:48 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAHAMX5p011560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 11:22:33 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAHAMWQe011539; Tue, 17 Nov 2009 11:22:33 +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 nAHAMWBF010410; Tue, 17 Nov 2009 11:22:32 +0100 Message-ID: <4B027968.2070705@gmail.com> Date: Tue, 17 Nov 2009 11:22:32 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> <4B027639.6070406@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:22:50 -0000 Thomas Heide Clausen a écrit : > > On Nov 17, 2009, at 11:08 AM, Alexandru Petrescu wrote: > >> Henning Rogge a écrit : >>> On Mon November 16 2009 22:11:01 Alexandru Petrescu wrote: >>>>> How would you deploy a MANET like the one from FunkFeuer? (several >>>>> hundreds of routers in Vienna, over a huge area)? >>>> "FunkFeuer"(?) Did FunkFeuer ever claim each of their hundreds Vienna >>>> routers is a one-interface router? >> > >>> Most of them are one-hop routers. I would say more than 70%, Maybe >>> even more. >> >> I believe you mean one-interface routers. >> >> Well I think we should leave place in the specs for the 30% or less >> routers which have more than one interface then. > > Fortunately, such do not necessitate special treatment at all. Well we should ack a MANET can use routers with more than one interface. On these routers the ABC link problems are less valid. Alex > > Thomas > >> Alex >> >>> Berlin had even a higher percentage of 1-interface routers in their >>> 700+ node network for years. >>> Henning Rogge > From thomas@thomasclausen.org Tue Nov 17 02:23:40 2009 Return-Path: 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 94A223A691D for ; Tue, 17 Nov 2009 02:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 d1BNVzqfazyi for ; Tue, 17 Nov 2009 02:23:39 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E68163A686D for ; Tue, 17 Nov 2009 02:23:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1F223430521; Tue, 17 Nov 2009 02:23:39 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.133.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 4C496430519; Tue, 17 Nov 2009 02:23:38 -0800 (PST) Message-Id: <4150144E-524F-480A-9F4E-D594DDDAA2D4@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B027968.2070705@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 11:23:36 +0100 References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> <4B027639.6070406@gmail.com> <4B027968.2070705@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:23:40 -0000 On Nov 17, 2009, at 11:22 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Nov 17, 2009, at 11:08 AM, Alexandru Petrescu wrote: >>> Henning Rogge a =E9crit : >>>> On Mon November 16 2009 22:11:01 Alexandru Petrescu wrote: >>>>>> How would you deploy a MANET like the one from FunkFeuer? =20 >>>>>> (several >>>>>> hundreds of routers in Vienna, over a huge area)? >>>>> "FunkFeuer"(?) Did FunkFeuer ever claim each of their hundreds =20= >>>>> Vienna >>>>> routers is a one-interface router? >>> > >>>> Most of them are one-hop routers. I would say more than 70%, =20 >>>> Maybe even more. >>> >>> I believe you mean one-interface routers. >>> >>> Well I think we should leave place in the specs for the 30% or =20 >>> less routers which have more than one interface then. >> Fortunately, such do not necessitate special treatment at all. > > Well we should ack a MANET can use routers with more than one =20 > interface. On these routers the ABC link problems are less valid. > No, they are not. Thomas > Alex > >> Thomas >>> Alex >>> >>>> Berlin had even a higher percentage of 1-interface routers in =20 >>>> their 700+ node network for years. >>>> Henning Rogge > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From alexandru.petrescu@gmail.com Tue Nov 17 02:24:47 2009 Return-Path: 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 062D03A69DA for ; Tue, 17 Nov 2009 02:24:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=-0.021, 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 5VDAqgukdOA3 for ; Tue, 17 Nov 2009 02:24:46 -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 1BF573A691D for ; Tue, 17 Nov 2009 02:24:45 -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-2.0) with ESMTP id nAHAOcLc016842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 11:24:38 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAHAObrA012364; Tue, 17 Nov 2009 11:24:37 +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 nAHAObWe011473; Tue, 17 Nov 2009 11:24:37 +0100 Message-ID: <4B0279E5.9050700@gmail.com> Date: Tue, 17 Nov 2009 11:24:37 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> <4B027639.6070406@gmail.com> <200911171116.43173.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911171116.43173.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:24:47 -0000 Henning Rogge a écrit : > On Tue November 17 2009 11:08:57 Alexandru Petrescu wrote: >>> Most of them are one-hop routers. I would say more than 70%, Maybe even >>> more. >> I believe you mean one-interface routers. > > Yes. > >> Well I think we should leave place in the specs for the 30% or less >> routers which have more than one interface then. > > I would have to ask what's the exact split. Well, a router with two interfaces will have less ABC link problems. > Most routers have only one interface because they are typical DSL-WLAN- > routers, so they are very cheap. Er? A typical DSL-WLAN router has two interfaces: a WLAN interface and a DSL interface. > That's a good argument for large scale > community networks. Yes, large scale networks are supposed to use several interfaces on their routers. Alex > > Henning Rogge > From henning.rogge@fkie.fraunhofer.de Tue Nov 17 02:25:06 2009 Return-Path: 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 7D50C3A69D8 for ; Tue, 17 Nov 2009 02:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.087 X-Spam-Level: X-Spam-Status: No, score=-6.087 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 SwTSCGzNeo5M for ; Tue, 17 Nov 2009 02:25:05 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 7B8FE3A686D for ; Tue, 17 Nov 2009 02:25:05 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NALF9-0007Dx-9d; Tue, 17 Nov 2009 11:25:03 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NALF8-0003MQ-UA; Tue, 17 Nov 2009 11:25:02 +0100 From: Henning Rogge To: Alexandru Petrescu Date: Tue, 17 Nov 2009 11:24:58 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B027968.2070705@gmail.com> In-Reply-To: <4B027968.2070705@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1454923.neXXfC1LnK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911171124.58247.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10030/Tue Nov 17 03:38:41 2009) by mailguard.fgan.de X-Scan-Signature: 79d7b6077a350f15a7dbed5e80640ffc Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:25:06 -0000 --nextPart1454923.neXXfC1LnK Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 17 2009 11:22:32 Alexandru Petrescu wrote: > Well we should ack a MANET can use routers with more than one interface. > On these routers the ABC link problems are less valid. That's not true. You don't seem to know anything about adhoc networks, sorr= y. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1454923.neXXfC1LnK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksCefoACgkQRIfGfFXsz+AfngCfVQYA1CZXcDrO+W90DdyWx6se HzsAn02apGUVaPRDfcH1kzdheboBQcdH =CyqN -----END PGP SIGNATURE----- --nextPart1454923.neXXfC1LnK-- From alexandru.petrescu@gmail.com Tue Nov 17 02:27:11 2009 Return-Path: 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 A7BAB3A693A for ; Tue, 17 Nov 2009 02:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 k2Dug2Xdjfy5 for ; Tue, 17 Nov 2009 02:27:11 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 9328E28C0F3 for ; Tue, 17 Nov 2009 02:26:44 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAHAQeUs015390 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 11:26:40 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAHAQebo013184; Tue, 17 Nov 2009 11:26:40 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAHAQeAS004829; Tue, 17 Nov 2009 11:26:40 +0100 Message-ID: <4B027A5F.5010101@gmail.com> Date: Tue, 17 Nov 2009 11:26:39 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> <4B027639.6070406@gmail.com> <4B027968.2070705@gmail.com> <4150144E-524F-480A-9F4E-D594DDDAA2D4@thomasclausen.org> In-Reply-To: <4150144E-524F-480A-9F4E-D594DDDAA2D4@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:27:11 -0000 Thomas Heide Clausen a écrit : > > On Nov 17, 2009, at 11:22 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Nov 17, 2009, at 11:08 AM, Alexandru Petrescu wrote: >>>> Henning Rogge a écrit : >>>>> On Mon November 16 2009 22:11:01 Alexandru Petrescu wrote: >>>>>>> How would you deploy a MANET like the one from FunkFeuer? (several >>>>>>> hundreds of routers in Vienna, over a huge area)? >>>>>> "FunkFeuer"(?) Did FunkFeuer ever claim each of their hundreds >>>>>> Vienna >>>>>> routers is a one-interface router? >>>> > >>>>> Most of them are one-hop routers. I would say more than 70%, Maybe >>>>> even more. >>>> >>>> I believe you mean one-interface routers. >>>> >>>> Well I think we should leave place in the specs for the 30% or less >>>> routers which have more than one interface then. >>> Fortunately, such do not necessitate special treatment at all. >> >> Well we should ack a MANET can use routers with more than one >> interface. On these routers the ABC link problems are less valid. >> > > No, they are not. Depends how you configure them. If you configure them such that A and C are too remote and B in between - yes ABC problems. If you configure B to have two interfaces each on a distinct 4861 link then there are no ABC problem links. It depends on how you set the links up. Alex > > Thomas > >> Alex >> >>> Thomas >>>> Alex >>>> >>>>> Berlin had even a higher percentage of 1-interface routers in their >>>>> 700+ node network for years. >>>>> Henning Rogge >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Tue Nov 17 02:28:15 2009 Return-Path: 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 1F88A28C0D7 for ; Tue, 17 Nov 2009 02:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=-0.019, 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 6aPERe2pTLom for ; Tue, 17 Nov 2009 02:28:14 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 28C723A6BAE for ; Tue, 17 Nov 2009 02:28:14 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAHAS4oD016459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 11:28:04 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAHAS3FG013583; Tue, 17 Nov 2009 11:28:03 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAHAS3Uf005442; Tue, 17 Nov 2009 11:28:03 +0100 Message-ID: <4B027AB3.9060709@gmail.com> Date: Tue, 17 Nov 2009 11:28:03 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <4B027968.2070705@gmail.com> <200911171124.58247.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911171124.58247.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:28:15 -0000 Henning Rogge a écrit : > On Tue November 17 2009 11:22:32 Alexandru Petrescu wrote: >> Well we should ack a MANET can use routers with more than one interface. >> On these routers the ABC link problems are less valid. > > That's not true. You don't seem to know anything about adhoc networks, sorry. Hmmm... is this the way you make people go away from your consensus? Alex > > Henning Rogge > From thomas@thomasclausen.org Tue Nov 17 02:29:33 2009 Return-Path: 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 2D0283A6BBE for ; Tue, 17 Nov 2009 02:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 Kxv2ZRPOIPRB for ; Tue, 17 Nov 2009 02:29:32 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 724653A6BB6 for ; Tue, 17 Nov 2009 02:29:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9D231430524; Tue, 17 Nov 2009 02:29:31 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.133.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 44B7E430523; Tue, 17 Nov 2009 02:29:30 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B027A5F.5010101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 11:29:28 +0100 References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> <4B027639.6070406@gmail.com> <4B027968.2070705@gmail.com> <4150144E-524F-480A-9F4E-D594DDDAA2D4@thomasclausen.org> <4B027A5F.5010101@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:29:33 -0000 On Nov 17, 2009, at 11:26 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Nov 17, 2009, at 11:22 AM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Nov 17, 2009, at 11:08 AM, Alexandru Petrescu wrote: >>>>> Henning Rogge a =E9crit : >>>>>> On Mon November 16 2009 22:11:01 Alexandru Petrescu wrote: >>>>>>>> How would you deploy a MANET like the one from FunkFeuer? =20 >>>>>>>> (several >>>>>>>> hundreds of routers in Vienna, over a huge area)? >>>>>>> "FunkFeuer"(?) Did FunkFeuer ever claim each of their =20 >>>>>>> hundreds Vienna >>>>>>> routers is a one-interface router? >>>>> > >>>>>> Most of them are one-hop routers. I would say more than 70%, =20 >>>>>> Maybe even more. >>>>> >>>>> I believe you mean one-interface routers. >>>>> >>>>> Well I think we should leave place in the specs for the 30% or =20 >>>>> less routers which have more than one interface then. >>>> Fortunately, such do not necessitate special treatment at all. >>> >>> Well we should ack a MANET can use routers with more than one =20 >>> interface. On these routers the ABC link problems are less valid. >>> >> No, they are not. > > Depends how you configure them. If you configure them such that A =20 > and C are too remote and B in between - yes ABC problems. > > If you configure B to have two interfaces each on a distinct 4861 =20 > link then there are no ABC problem links. > > It depends on how you set the links up. > If you configure the devices and enforce behavior such that they are =20 not part of a MANET, then you are not within scope of [autoconf]. Thomas > Alex > >> Thomas >>> Alex >>> >>>> Thomas >>>>> Alex >>>>> >>>>>> Berlin had even a higher percentage of 1-interface routers in =20 >>>>>> their 700+ node network for years. >>>>>> Henning Rogge >>> >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf > > From alexandru.petrescu@gmail.com Tue Nov 17 02:34:15 2009 Return-Path: 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 E353D28C21D for ; Tue, 17 Nov 2009 02:34:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[AWL=-0.018, 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 xkDeg5kHiAlq for ; Tue, 17 Nov 2009 02:34:15 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id D13DD28C0EF for ; Tue, 17 Nov 2009 02:34:14 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAHAY9c7012725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 11:34:09 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAHAY98U015793; Tue, 17 Nov 2009 11:34:09 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAHAY9wm008346; Tue, 17 Nov 2009 11:34:09 +0100 Message-ID: <4B027C21.3010704@gmail.com> Date: Tue, 17 Nov 2009 11:34:09 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> <4B027639.6070406@gmail.com> <4B027968.2070705@gmail.com> <4150144E-524F-480A-9F4E-D594DDDAA2D4@thomasclausen.org> <4B027A5F.5010101@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:34:16 -0000 Thomas Heide Clausen a écrit : > > On Nov 17, 2009, at 11:26 AM, Alexandru Petrescu wrote: > >> Thomas Heide Clausen a écrit : >>> On Nov 17, 2009, at 11:22 AM, Alexandru Petrescu wrote: >>>> Thomas Heide Clausen a écrit : >>>>> On Nov 17, 2009, at 11:08 AM, Alexandru Petrescu wrote: >>>>>> Henning Rogge a écrit : >>>>>>> On Mon November 16 2009 22:11:01 Alexandru Petrescu >>>>>>> wrote: >>>>>>>>> How would you deploy a MANET like the one from >>>>>>>>> FunkFeuer? (several hundreds of routers in Vienna, >>>>>>>>> over a huge area)? >>>>>>>> "FunkFeuer"(?) Did FunkFeuer ever claim each of their >>>>>>>> hundreds Vienna routers is a one-interface router? >>>>>>> >>>>>>> Most of them are one-hop routers. I would say more than >>>>>>> 70%, Maybe even more. >>>>>> >>>>>> I believe you mean one-interface routers. >>>>>> >>>>>> Well I think we should leave place in the specs for the 30% >>>>>> or less routers which have more than one interface then. >>>>> Fortunately, such do not necessitate special treatment at >>>>> all. >>>> >>>> Well we should ack a MANET can use routers with more than one >>>> interface. On these routers the ABC link problems are less >>>> valid. >>>> >>> No, they are not. >> >> Depends how you configure them. If you configure them such that A >> and C are too remote and B in between - yes ABC problems. >> >> If you configure B to have two interfaces each on a distinct 4861 >> link then there are no ABC problem links. >> >> It depends on how you set the links up. >> > > If you configure the devices and enforce behavior such that they are > not part of a MANET, then you are not within scope of [autoconf]. Thomas, Again, you seem to make AUTOCONF too much related to MANET. AUTOCONF Charter doesn't say MANET. Are we sure Chairs and WG members are inline with respect to MANET vs AUTOCONF? I personally don't think AUTOCONF should do MANET exclusively. With the above phrase you (as Chair?) clearly rule out everything else than MANET from AUTOCONF. I think this is a very wrong situation to be in. Alex > > Thomas > > >> Alex >> >>> Thomas >>>> Alex >>>> >>>>> Thomas >>>>>> Alex >>>>>> >>>>>>> Berlin had even a higher percentage of 1-interface >>>>>>> routers in their 700+ node network for years. Henning >>>>>>> Rogge >>>> >>>> >>>> _______________________________________________ Autoconf >>>> mailing list Autoconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/autoconf >> >> > > From thomas@thomasclausen.org Tue Nov 17 02:38:11 2009 Return-Path: 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 724E828C21E for ; Tue, 17 Nov 2009 02:38:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 SQIK+m69A8Vw for ; Tue, 17 Nov 2009 02:38:10 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 74C5328C0E9 for ; Tue, 17 Nov 2009 02:38:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 9BEF7430523; Tue, 17 Nov 2009 02:38:09 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.133.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 3BBF5430521; Tue, 17 Nov 2009 02:38:08 -0800 (PST) Message-Id: <87662A6E-6E43-494D-A0E2-7286A0CF2F0E@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B027C21.3010704@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-3-974211913 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Nov 2009 11:38:06 +0100 References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <25c114b90911161223j37990bfas10f95a3aa440ea6c@mail.gmail.com> <4B01BFE5.6080300@gmail.com> <200911170731.29359.henning.rogge@fkie.fraunhofer.de> <4B027639.6070406@gmail.com> <4B027968.2070705@gmail.com> <4150144E-524F-480A-9F4E-D594DDDAA2D4@thomasclausen.org> <4B027A5F.5010101@gmail.com> <4B027C21.3010704@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:38:11 -0000 --Apple-Mail-3-974211913 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Nov 17, 2009, at 11:34 AM, Alexandru Petrescu wrote: > Thomas Heide Clausen a =E9crit : >> On Nov 17, 2009, at 11:26 AM, Alexandru Petrescu wrote: >>> Thomas Heide Clausen a =E9crit : >>>> On Nov 17, 2009, at 11:22 AM, Alexandru Petrescu wrote: >>>>> Thomas Heide Clausen a =E9crit : >>>>>> On Nov 17, 2009, at 11:08 AM, Alexandru Petrescu wrote: >>>>>>> Henning Rogge a =E9crit : >>>>>>>> On Mon November 16 2009 22:11:01 Alexandru Petrescu wrote: >>>>>>>>>> How would you deploy a MANET like the one from FunkFeuer? =20 >>>>>>>>>> (several hundreds of routers in Vienna, over a huge area)? >>>>>>>>> "FunkFeuer"(?) Did FunkFeuer ever claim each of their =20 >>>>>>>>> hundreds Vienna routers is a one-interface router? >>>>>>>> Most of them are one-hop routers. I would say more than 70%, =20= >>>>>>>> Maybe even more. >>>>>>> I believe you mean one-interface routers. >>>>>>> Well I think we should leave place in the specs for the 30% >>>>>>> or less routers which have more than one interface then. >>>>>> Fortunately, such do not necessitate special treatment at all. >>>>> Well we should ack a MANET can use routers with more than one =20 >>>>> interface. On these routers the ABC link problems are less valid. >>>> No, they are not. >>> Depends how you configure them. If you configure them such that A =20= >>> and C are too remote and B in between - yes ABC problems. >>> If you configure B to have two interfaces each on a distinct 4861 =20= >>> link then there are no ABC problem links. >>> It depends on how you set the links up. >> If you configure the devices and enforce behavior such that they =20 >> are not part of a MANET, then you are not within scope of [autoconf]. > > Thomas, > > Again, you seem to make AUTOCONF too much related to MANET. > > AUTOCONF Charter doesn't say MANET. > > Are we sure Chairs and WG members are inline with respect to MANET vs > AUTOCONF? > > I personally don't think AUTOCONF should do MANET exclusively. With =20= > the > above phrase you (as Chair?) clearly rule out everything else than =20 > MANET > from AUTOCONF. > > I think this is a very wrong situation to be in. I believe that the charter is quite clear when it starts: In order to communicate among themselves, ad hoc nodes (refer to = RFC 2501) that we are addressing MANETs. Thomas > Alex > >> Thomas >>> Alex >>>> Thomas >>>>> Alex >>>>>> Thomas >>>>>>> Alex >>>>>>>> Berlin had even a higher percentage of 1-interface routers in =20= >>>>>>>> their 700+ node network for years. Henning Rogge >>>>> _______________________________________________ Autoconf mailing =20= >>>>> list Autoconf@ietf.org = https://www.ietf.org/mailman/listinfo/autoconf > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --Apple-Mail-3-974211913 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Nov 17, 2009, = at 11:34 AM, Alexandru Petrescu wrote:

Thomas = Heide Clausen a =E9crit :
On Nov 17, 2009, = at 11:26 AM, Alexandru Petrescu wrote:
Thomas Heide Clausen a =E9crit = :
On Nov 17, 2009, at 11:22 AM, = Alexandru Petrescu = wrote:
Thomas Heide Clausen a =E9crit = :
On Nov = 17, 2009, at 11:08 AM, Alexandru Petrescu = wrote:
Henning Rogge a =E9crit = :
On Mon = November 16 2009 22:11:01 Alexandru Petrescu = wrote:
How would you deploy a MANET = like the one from FunkFeuer? (several hundreds of routers in Vienna, = over a huge = area)?
"FunkFeuer"(?)  Did = FunkFeuer ever claim each of their hundreds Vienna routers is a = one-interface = router?
Most = of them are one-hop routers. I would say more than 70%, Maybe even = more.
=
I = believe you mean one-interface = routers.
Well I = think we should leave place in the specs for the = 30%
or less routers which have more = than one interface = then.
=
Fortunately, such do not = necessitate special treatment at = all.
<= blockquote type=3D"cite">
Well we should ack a MANET can = use routers with more than one interface. On these routers the ABC link = problems are less = valid.
No, = they are not.
Depends how you configure them. =  If you configure them such that A and C are too remote and B in = between - yes ABC problems.
If you configure B to have two = interfaces each on a distinct 4861 link then there are no ABC problem = links.
It depends on how you set the links = up.
If you = configure the devices and enforce behavior such that they are not part = of a MANET, then you are not within scope of = [autoconf].

Thomas,

Again, you seem to make = AUTOCONF too much related to MANET.

AUTOCONF Charter doesn't say = MANET.

Are we sure Chairs and WG members are inline with respect = to MANET vs
AUTOCONF?

I personally don't think AUTOCONF should = do MANET exclusively.  With the
above phrase you (as Chair?) = clearly rule out everything else than MANET
from AUTOCONF.

I = think this is a very wrong situation to be = in.

I believe that the charter is = quite clear when it starts:

In order to communicate among = themselves, ad hoc nodes (refer to RFC
= 2501) 

that we are addressing = MANETs.

Thomas

Alex

Thomas
Alex
Thomas
Alex
=
Thomas
Alex
=
Berlin had even a higher = percentage of 1-interface routers in their 700+ node network for years. = Henning = Rogge
=
_______________________________________________ Autoconf = mailing list Autoconf@ietf.org https://www.ietf.o= rg/mailman/listinfo/autoconf


_______________________________________________
A= utoconf mailing list
Autoconf@ietf.org
https://www.iet= f.org/mailman/listinfo/autoconf

= --Apple-Mail-3-974211913-- From henning.rogge@fkie.fraunhofer.de Tue Nov 17 02:38:26 2009 Return-Path: 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 56B3F28C225 for ; Tue, 17 Nov 2009 02:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.105 X-Spam-Level: X-Spam-Status: No, score=-6.105 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 Aq+5nvDBawDv for ; Tue, 17 Nov 2009 02:38:25 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 3C02428C226 for ; Tue, 17 Nov 2009 02:38:25 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NALS2-00035p-St; Tue, 17 Nov 2009 11:38:22 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NALS2-0003TD-JO; Tue, 17 Nov 2009 11:38:22 +0100 From: Henning Rogge To: Alexandru Petrescu Date: Tue, 17 Nov 2009 11:38:08 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911171124.58247.henning.rogge@fkie.fraunhofer.de> <4B027AB3.9060709@gmail.com> In-Reply-To: <4B027AB3.9060709@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1316743.VEMgu81G05"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911171138.13770.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10030/Tue Nov 17 03:38:41 2009) by mailguard.fgan.de X-Scan-Signature: deed7c2e435cc94a15d698e07c10212e Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 10:38:26 -0000 --nextPart1316743.VEMgu81G05 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Tue November 17 2009 11:28:03 Alexandru Petrescu wrote: > Henning Rogge a =E9crit : > > On Tue November 17 2009 11:22:32 Alexandru Petrescu wrote: > >> Well we should ack a MANET can use routers with more than one interfac= e. > >> On these routers the ABC link problems are less valid. > > > > That's not true. You don't seem to know anything about adhoc networks, > > sorry. >=20 > Hmmm... is this the way you make people go away from your consensus? At the moment you are wasting time for everyone because you don't seem to=20 grasp what this WG and MANETs in general are about. You try to press the=20 working of this group into a concept that was generated mostly for wired=20 network world (and highly structured networks as mobile phone ones). MANETs work differently. They have additional problems and they are not jus= t a=20 "bunch of well behaving links". > Thomas, >=20 > Again, you seem to make AUTOCONF too much related to MANET. >=20 > AUTOCONF Charter doesn't say MANET. =46rom the charter of the AUTOCONF group: > Description of Working Group: > In order to communicate among themselves, ad hoc nodes (refer to RFC > 2501) need to configure their network interface(s) with local addresses > that are valid within an ad hoc network. Ad hoc nodes may also need to > configure globally routable addresses, in order to communicate with > devices on the Internet. From the IP layer perspective, an ad hoc > network presents itself as a L3 multi-hop network formed over a > collection of links. > The main purpose of the AUTOCONF WG is to describe the addressing model > for ad hoc networks and how nodes in these networks configure their > addresses. It is required that such models do not cause problems for ad > hoc-unaware parts of the system, such as standard applications running > on an ad hoc node or regular Internet nodes attached to the ad hoc > nodes. This group's effort may include the development of new protocol > mechanisms, should the existing IP autoconfiguration mechanisms be found > inadequate. However, the first task of the working group is to describe > one practical addressing model for ad hoc networks. Please count how often this text says "ad hoc network" or "ad hoc nodes". MANET is an acronym for "mobile AD HOC NETWORK". Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart1316743.VEMgu81G05 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksCfRAACgkQRIfGfFXsz+BpqwCgoGgzBvQw+4WAASvIU0alvvTt 0KsAnjHpxmgEvcdVhVqp7xzIcpkrQ4ix =P3Ts -----END PGP SIGNATURE----- --nextPart1316743.VEMgu81G05-- From cjbc@it.uc3m.es Tue Nov 17 02:56:05 2009 Return-Path: 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 BB2A13A6949 for ; Tue, 17 Nov 2009 02:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 er5WftEPTtrD for ; Tue, 17 Nov 2009 02:56:04 -0800 (PST) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id A46EC28C10E for ; Tue, 17 Nov 2009 02:56:04 -0800 (PST) X-uc3m-safe: yes Received: from [192.168.1.87] (20.Red-79-150-13.dynamicIP.rima-tde.net [79.150.13.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id B274EBA523A for ; Tue, 17 Nov 2009 11:56:01 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-99Xtwql6vM/60RwDJoNT" Organization: Universidad Carlos III de Madrid Date: Tue, 17 Nov 2009 11:56:01 +0100 Message-Id: <1258455361.4335.39.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Subject: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 10:56:05 -0000 --=-99Xtwql6vM/60RwDJoNT Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, Quite a few e-mails have been sent lately and I'm not sure we are making any progress, again we have different views and I think we need to reach a common understanding. I think it's good that everybody provides their view, because I think that after 5 years we don't have still a clear and well accepted view of what a MANET is and -- more important -- what is the scope of AUTOCONF. Trying to summarize some issues next, to help driving the discussion to more concrete points... - LLs usage in MANETs. I see and understand (personal view) that "links" in wireless MANETs do not exactly behave as wired (Ethernet-alike) links. However, I don't agree that LLs cannot be used in MANETs (in case a protocol/application wants to use it). These "links" in MANETs are more dynamic, short-lived and transitivity is not granted, but we still have a "link". - Related to the previous item, IPv6 assumes the existence of "links", so I agree with Alex that we need to have some better understanding of what we understand by "link" in autoconf. For me, I see it as a wireless link (with all its properties) which is very dynamic and non-transitive. This implies that special care has to be taken when designing some mechanisms (DAD is one of the most representative ones), but it does not necessarily preclude the use of link-locals. IP relies on the existence of a link and therefore, if we don't want to change many core IP mechanisms, we need to understand what kind of link IP "sees" in a MANET. - From the last e-mails I see again that the scope of autoconf is not clear. I always thought that autoconf was dealing with __IP address autoconfiguration in MANETs__, but I see (I've already raised this question/comment) that many people is rather working on "IP over MANET" and here is where most of the controversy appears. I think the charter should be more explicit about what changes are allowed to IP standards in order to allow MANETs get IP address autoconfiguration, otherwise this is not gonna converge (we may get "rough" consensus, but a non-negligible set of wg members would likely never agree). If people feel it is impossible to come up with a practical address autoconfiguration mechanism without modifying some IPv6 core standards, then we should go for a "6MANET" working group or something like this. There address autoconfiguration would be part of the charter (as in 6lowpan). My two cents, hope it helps instead of creates more confusion and endless discussions... Thanks, Carlos --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-99Xtwql6vM/60RwDJoNT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEUEABECAAYFAksCgUEACgkQNdy6TdFwT2c+LQCWLBtwHNL5wfjt2fRPJjd3NDsP 4QCfdB8jnYfLksTivVR3ZzwOFDY9aa4= =1XLG -----END PGP SIGNATURE----- --=-99Xtwql6vM/60RwDJoNT-- From alexandru.petrescu@gmail.com Tue Nov 17 03:34:38 2009 Return-Path: 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 4AF953A68E3 for ; Tue, 17 Nov 2009 03:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.017, 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 w5R5w+aEHzuI for ; Tue, 17 Nov 2009 03:34:37 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6C43A67EB for ; Tue, 17 Nov 2009 03:34:36 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAHBYPRx011985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 12:34:26 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAHBYPNa032429; Tue, 17 Nov 2009 12:34:25 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAHBYPOR032622; Tue, 17 Nov 2009 12:34:25 +0100 Message-ID: <4B028A41.2080005@gmail.com> Date: Tue, 17 Nov 2009 12:34:25 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Henning Rogge References: <1258126393.5035.20.camel@acorde.it.uc3m.es> <200911171124.58247.henning.rogge@fkie.fraunhofer.de> <4B027AB3.9060709@gmail.com> <200911171138.13770.henning.rogge@fkie.fraunhofer.de> In-Reply-To: <200911171138.13770.henning.rogge@fkie.fraunhofer.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org, "Dearlove, Christopher \(UK\)" , Thomas Heide Clausen Subject: Re: [Autoconf] Question regarding use of LLs X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 11:34:38 -0000 Henning Rogge a écrit : > On Tue November 17 2009 11:28:03 Alexandru Petrescu wrote: >> Henning Rogge a écrit : >>> On Tue November 17 2009 11:22:32 Alexandru Petrescu wrote: >>>> Well we should ack a MANET can use routers with more than one >>>> interface. On these routers the ABC link problems are less >>>> valid. >>> That's not true. You don't seem to know anything about adhoc >>> networks, sorry. >> Hmmm... is this the way you make people go away from your >> consensus? > > At the moment you are wasting time for everyone because you don't > seem to grasp what this WG and MANETs in general are about. You try > to press the working of this group into a concept that was generated > mostly for wired network world Well, I think Internet routing and addressing is very well structured. You can't just change that. An address being topologically correct at only one place in the topology is an inherent feature of Internet routing and addressing that can't be changed just like that. You're touching on very sensitive issues with the LL recommendations and with the /128 prefix per interface. > (and highly structured networks as mobile phone ones). 1. mobile phone networks often consider infrastructure-less relaying, such as in LTE. In this sense they look as ad-hoc networks. 2. highly structured networks exist outside the mobile phone industry, which look a lot like the ad-hocnetworks. Highly-structured is what Internet is, otherwise it doesn't work. > MANETs work differently. They have additional problems and they are > not just a "bunch of well behaving links". Ok, do you have anything else to say about MANETs other than they're different? >> Thomas, >> >> Again, you seem to make AUTOCONF too much related to MANET. >> >> AUTOCONF Charter doesn't say MANET. > > From the charter of the AUTOCONF group: > >> Description of Working Group: In order to communicate among >> themselves, ad hoc nodes (refer to RFC 2501) need to configure >> their network interface(s) with local addresses that are valid >> within an ad hoc network. Ad hoc nodes may also need to configure >> globally routable addresses, in order to communicate with devices >> on the Internet. From the IP layer perspective, an ad hoc network >> presents itself as a L3 multi-hop network formed over a collection >> of links. > >> The main purpose of the AUTOCONF WG is to describe the addressing >> model for ad hoc networks and how nodes in these networks configure >> their addresses. It is required that such models do not cause >> problems for ad hoc-unaware parts of the system, such as standard >> applications running on an ad hoc node or regular Internet nodes >> attached to the ad hoc nodes. This group's effort may include the >> development of new protocol mechanisms, should the existing IP >> autoconfiguration mechanisms be found inadequate. However, the >> first task of the working group is to describe one practical >> addressing model for ad hoc networks. > > Please count how often this text says "ad hoc network" or "ad hoc > nodes". MANET is an acronym for "mobile AD HOC NETWORK". Well - are you sure everybody is on the same line with you when you say adhoc network is a MANET? We have already seen that the MANET term of rfc2501 is not the same MANET term described with the help of ABC problem and non-transitivity links. I remind that two other groups at IETF (6lowpan and ROLL) do things similar to what you would call a "MANET" yet they don't call it "MANET". I suggest you do the same. Alex From charles.perkins@earthlink.net Tue Nov 17 10:02:28 2009 Return-Path: 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 46F723A6782 for ; Tue, 17 Nov 2009 10:02:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 vN3iaQjSzAtJ for ; Tue, 17 Nov 2009 10:02:27 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 558E23A672E for ; Tue, 17 Nov 2009 10:02:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=glc/5R17PnBY20AmpI5o8o6sICbX3ZUy+KPGQyAOepNkbM69w4GiX5bnTkAglNdB; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.154]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NASNj-0005iM-Ad; Tue, 17 Nov 2009 13:02:23 -0500 Message-ID: <4B02E52E.3060809@earthlink.net> Date: Tue, 17 Nov 2009 10:02:22 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1258455361.4335.39.camel@acorde.it.uc3m.es> In-Reply-To: <1258455361.4335.39.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5239ae96bb8a97d51b481106b33c92889c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 18:02:28 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > Quite a few e-mails have been sent lately and I'm not sure we are making > any progress, again we have different views and I think we need to reach > a common understanding. I think it's good that everybody provides their > view, because I think that after 5 years we don't have still a clear and > well accepted view of what a MANET is and -- more important -- what is > the scope of AUTOCONF. > I think there is a very well accepted view of the nature of a MANET. There is a conference series called "MobiHoc" which has published many high-quality papers on the subject. I reviewed many papers for the conference, and I didn't notice the huge conceptual stumbling blocks there that are surfacing on this mailing list. Maybe it would help for the people unclear on the concepts to read some of those papers. There is a huge diversity of opinion, to be sure, but at least people don't try to confine ad hoc networks to be single hop domains configured by network administrators. > > - LLs usage in MANETs. I see and understand (personal view) that "links" > in wireless MANETs do not exactly behave as wired (Ethernet-alike) > links. However, I don't agree that LLs cannot be used in MANETs (in case > a protocol/application wants to use it). These "links" in MANETs are > more dynamic, short-lived and transitivity is not granted, but we still > have a "link". > Sure, you can use them. Others should not have to use them. > - Related to the previous item, IPv6 assumes the existence of "links", > so I agree with Alex that we need to have some better understanding of > what we understand by "link" in autoconf. I don't think that is likely to get you anywhere. I recommend you form a task force to settle the issue for your satisfaction. > For me, I see it as a wireless > link (with all its properties) which is very dynamic and non-transitive. > This implies that special care has to be taken when designing some > mechanisms (DAD is one of the most representative ones), but it does not > necessarily preclude the use of link-locals. IP relies on the existence > of a link and therefore, if we don't want to change many core IP > mechanisms, we need to understand what kind of link IP "sees" in a > MANET. > IP relies on the existence of a communications medium equipped with layer-2 access software (in the device driver) and a standardized calling sequence for the device driver. > - From the last e-mails I see again that the scope of autoconf is not > clear. I always thought that autoconf was dealing with __IP address > autoconfiguration in MANETs__, but I see (I've already raised this > question/comment) that many people is rather working on "IP over MANET" > and here is where most of the controversy appears. I thought that some people indicated they did not believe IP could work over a MANET so then we had to have yet another diversionary discussion. That doesn't mean the scope of [autoconf] is unclear. > I think the charter > should be more explicit about what changes are allowed to IP standards > in order to allow MANETs get IP address autoconfiguration, otherwise > this is not gonna converge (we may get "rough" consensus, but a > non-negligible set of wg members would likely never agree). Especially the ones that don't think it's possible to run IP in a MANET. I think that determining which standards require revision is a problem in the solution space. > If people > feel it is impossible to come up with a practical address > autoconfiguration mechanism without modifying some IPv6 core standards, > then we should go for a "6MANET" working group or something like this. > There address autoconfiguration would be part of the charter (as in > 6lowpan). > Sorry, this is wrong. [autoconf] is chartered to make practical address autoconfiguration mechanisms. It's been shown to be possible. Now if we could just get to doing it instead of convincing people that IP can be run in a MANET. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Nov 17 10:29:27 2009 Return-Path: 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 712E73A68DA for ; Tue, 17 Nov 2009 10:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 u3seHOwNT55v for ; Tue, 17 Nov 2009 10:29:26 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 3F6E43A67E6 for ; Tue, 17 Nov 2009 10:29:26 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAHITKdj017987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Nov 2009 19:29:21 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAHITKuI011391; Tue, 17 Nov 2009 19:29:20 +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 nAHITKRl024049; Tue, 17 Nov 2009 19:29:20 +0100 Message-ID: <4B02EB80.3050505@gmail.com> Date: Tue, 17 Nov 2009 19:29:20 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> In-Reply-To: <4B02E52E.3060809@earthlink.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 18:29:27 -0000 Charles E. Perkins a écrit : [...] > I think there is a very well accepted view of the nature of a MANET. > There is a conference series called "MobiHoc" which has published > many high-quality papers on the subject. I reviewed many papers for > the conference, and I didn't notice the huge conceptual stumbling > blocks there that are surfacing on this mailing list. Maybe it would > help for the people unclear on the concepts to read some of those > papers. Are you talking about me? I too regularly review (for reviews.com) about ad-hoc networks articles published on more than just MobiHoc and I end most of my reviews urging everybody to practice more and simulate less. That gets published. Only to come here be told I don't know about MANETs :-( Alex From charles.perkins@earthlink.net Tue Nov 17 10:45:07 2009 Return-Path: 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 4915828C186 for ; Tue, 17 Nov 2009 10:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.773 X-Spam-Level: X-Spam-Status: No, score=-0.773 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, RCVD_IN_SORBS_WEB=0.619] 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 sAxecO9DX1Nl for ; Tue, 17 Nov 2009 10:45:06 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 9C71328C16E for ; Tue, 17 Nov 2009 10:45:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EHtJmEye5WsYIgwCgntG0jSh9dHl02YOlVthHFLupGoGoIyENYBq0HK9f5mVE7f+; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.154]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NAT2z-0003En-OQ; Tue, 17 Nov 2009 13:45:01 -0500 Message-ID: <4B02EF2C.6020403@earthlink.net> Date: Tue, 17 Nov 2009 10:45:00 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> In-Reply-To: <4B02EB80.3050505@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f525824e99ef0a93f84582d6f6701e4a013350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 18:45:07 -0000 Hello Alex, Here's an excerpt from a recent email: > No no, I am deaf :-) > > I tell you why. > > Whenever considering a 1000somethings bigger something one has to > structure them. And the first setp in structuring is to use > deterministic links. > > Also, whenever considering 1000nodes, there surely will exist _some_ > nodes which are given little more functionalities. I expect these to > have several interfaces. > > Besides, there's no one single human who could deploy alone a working > 1000node IP network. First, since you are deaf, I am silly for responding. I might as well try to convert Texas to humanism. Second, there are examples of 1000 node networks where each node is minimal. Third, a single human could easily deploy a 1000 node sensor network. So, in just this one excerpt you have exhibited fundamental disregard (I won't say ignorance) for existing technology. In a previous email to you, I exhibited nearly a half-dozen errors in a _single sentence_. You insist on necessitating a central role for a "link", in a network where such the communications medium identified by such a concept is likely to be varying very quickly in time and space, sometimes almost unpredictably. The experience of others (who do those 1000 node networks) leads towards certain design decisions that you disregard. [cf: > No no, I am deaf :-) ]. And yet you want to occupy the attention and restrict the solution space available to practitioners who seem to have far more experience than you, regardless of your ability to respond to paper review requests. Regards, Charlie P. From cjbc@it.uc3m.es Tue Nov 17 11:07:25 2009 Return-Path: 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 7E7C13A69C7 for ; Tue, 17 Nov 2009 11:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[AWL=-0.423, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 4lSNTGGRrf1y for ; Tue, 17 Nov 2009 11:07:24 -0800 (PST) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id E2F5C3A6939 for ; Tue, 17 Nov 2009 11:07:23 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id 181467F29FF; Tue, 17 Nov 2009 20:07:21 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: "Charles E. Perkins" In-Reply-To: <4B02E52E.3060809@earthlink.net> References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-uq5B6AC0/+uk2zFu1gfG" Organization: Universidad Carlos III de Madrid Date: Tue, 17 Nov 2009 20:07:21 +0100 Message-Id: <1258484841.30701.43.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17004.003 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 19:07:25 -0000 --=-uq5B6AC0/+uk2zFu1gfG Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Charlie, On Tue, 2009-11-17 at 10:02 -0800, Charles E. Perkins wrote: > Hello Carlos, >=20 > Carlos Jes=FAs Bernardos Cano wrote: > > Quite a few e-mails have been sent lately and I'm not sure we are makin= g > > any progress, again we have different views and I think we need to reac= h > > a common understanding. I think it's good that everybody provides their > > view, because I think that after 5 years we don't have still a clear an= d > > well accepted view of what a MANET is and -- more important -- what is > > the scope of AUTOCONF. > > =20 >=20 > I think there is a very well accepted view of the nature of a MANET. =20 > There is a conference > series called "MobiHoc" which has published many high-quality papers on=20 > the subject. > I reviewed many papers for the conference, and I didn't notice the huge=20 > conceptual stumbling > blocks there that are surfacing on this mailing list. Maybe it would=20 > help for the people unclear > on the concepts to read some of those papers. There is a huge diversity=20 I've also reviewed many papers from this or similar conferences and journals. Even I have published on this topic. > of opinion, to be sure, > but at least people don't try to confine ad hoc networks to be single=20 > hop domains configured by > network administrators. I don't try to do that. I just pointed out the fact that it seems that we don't have in autoconf a agreed view on what a MANET is (I think we tried in the past with the draft-ietf-autoconf-manet-architecture and we failed). So, I agree with you, there is a huge diversity of opinion. >=20 > > > > - LLs usage in MANETs. I see and understand (personal view) that "links= " > > in wireless MANETs do not exactly behave as wired (Ethernet-alike) > > links. However, I don't agree that LLs cannot be used in MANETs (in cas= e > > a protocol/application wants to use it). These "links" in MANETs are > > more dynamic, short-lived and transitivity is not granted, but we still > > have a "link". > > =20 > Sure, you can use them. Others should not have to use them. Right. >=20 > > - Related to the previous item, IPv6 assumes the existence of "links", > > so I agree with Alex that we need to have some better understanding of > > what we understand by "link" in autoconf. > I don't think that is likely to get you anywhere. I recommend you form=20 > a task > force to settle the issue for your satisfaction. Well, I just tried to be constructive here, doing things for my own satisfaction is good, but not very constructive :-). >=20 > > For me, I see it as a wireless > > link (with all its properties) which is very dynamic and non-transitive= . > > This implies that special care has to be taken when designing some > > mechanisms (DAD is one of the most representative ones), but it does no= t > > necessarily preclude the use of link-locals. IP relies on the existence > > of a link and therefore, if we don't want to change many core IP > > mechanisms, we need to understand what kind of link IP "sees" in a > > MANET. > > =20 >=20 > IP relies on the existence of a communications medium equipped with > layer-2 access software (in the device driver) and a standardized > calling sequence for the device driver. Well, IPv6 standars discusses about off-link, on-link, etc, so "links" are critical parts to understand addressing. >=20 > > - From the last e-mails I see again that the scope of autoconf is not > > clear. I always thought that autoconf was dealing with __IP address > > autoconfiguration in MANETs__, but I see (I've already raised this > > question/comment) that many people is rather working on "IP over MANET" > > and here is where most of the controversy appears. >=20 > I thought that some people indicated they did not believe IP could > work over a MANET so then we had to have yet another diversionary > discussion. That doesn't mean the scope of [autoconf] is unclear. I do believe IP can work over a MANET (and I have performed experiments with MANETs in my lab). I'm far from questioning this. My point is that I think we can run IP over MANET without introducing drastic changes to IP. >=20 > > I think the charter > > should be more explicit about what changes are allowed to IP standards > > in order to allow MANETs get IP address autoconfiguration, otherwise > > this is not gonna converge (we may get "rough" consensus, but a > > non-negligible set of wg members would likely never agree). > Especially the ones that don't think it's possible to run IP in a MANET. Again, I hope you are not referring to me here, because I do believe it. > I think that determining which standards require revision is a problem in > the solution space. Well, someone mentioned not using ND at all in MANETs in the last meeting. I have this kind of example in mind when talking about this. >=20 > > If people > > feel it is impossible to come up with a practical address > > autoconfiguration mechanism without modifying some IPv6 core standards, > > then we should go for a "6MANET" working group or something like this. > > There address autoconfiguration would be part of the charter (as in > > 6lowpan). > > =20 > Sorry, this is wrong. [autoconf] is chartered to make practical address > autoconfiguration mechanisms. It's been shown to be possible. Now if > we could just get to doing it instead of convincing people that IP can be > run in a MANET. I'm sorry you think we are arguing against the feasibility of running IP in a MANET, this is not true. I'm just trying to understand the best way of _configuring IP addresses_ in a MANET, with as minimum changes to IP model/protocols as necessary. I just tried to help with this thread, but I guess I've failed again. Maybe I should keep myself quieter from now on... Thanks, Carlos >=20 > Regards, > Charlie P. >=20 --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-uq5B6AC0/+uk2zFu1gfG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksC9GkACgkQNdy6TdFwT2f52ACfYbSy4sQ9hfiiSYTWwnun4fOg mQwAnAmi/BB/e7GwObLa0Tek9mEIJx9V =NYvt -----END PGP SIGNATURE----- --=-uq5B6AC0/+uk2zFu1gfG-- From charles.perkins@earthlink.net Tue Nov 17 11:31:37 2009 Return-Path: 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 75B343A6BDD for ; Tue, 17 Nov 2009 11:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 Deb9zYZPKTgU for ; Tue, 17 Nov 2009 11:31:35 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id AC2263A6BDA for ; Tue, 17 Nov 2009 11:31:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EkzH+PRL94dn40PZ9sQd4B/oFanX21nuuue+x/LOUisOF+zItsCofA5kTm+H+cBW; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.154]) by elasmtp-scoter.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NATm1-0005fe-RZ; Tue, 17 Nov 2009 14:31:34 -0500 Message-ID: <4B02FA14.4090301@earthlink.net> Date: Tue, 17 Nov 2009 11:31:32 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: cjbc@it.uc3m.es References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <1258484841.30701.43.camel@acorde.it.uc3m.es> In-Reply-To: <1258484841.30701.43.camel@acorde.it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f527a07f6926c364fc07aa4779b40b6bbe3350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 19:31:37 -0000 Hello Carlos, Carlos Jesús Bernardos Cano wrote: > I don't try to do that. I just pointed out the fact that it seems that > we don't have in autoconf a agreed view on what a MANET is (I think we > tried in the past with the draft-ietf-autoconf-manet-architecture and we > failed). So, I agree with you, there is a huge diversity of opinion. > All of the failures stem from an attempt to fit a round peg in a square hole. Or, to be more precise, to fit the time-varying nature of the MANET communications medium completely within the square hole of the IP subnet model. > > >>> - Related to the previous item, IPv6 assumes the existence of "links", >>> so I agree with Alex that we need to have some better understanding of >>> what we understand by "link" in autoconf. >>> >> I don't think that is likely to get you anywhere. I recommend you form >> a task >> force to settle the issue for your satisfaction. >> > > Well, I just tried to be constructive here, doing things for my own > satisfaction is good, but not very constructive :-). > But I am pretty sure that focusing on identifying "links" in a MANET is not constructive. Been there, done that! In fact, the whole discussion about link-layer uniqueness is a red herring if protocol cannot identify the "link" on which such an address is supposed to be unique. >> medium equipped with >> layer-2 access software (in the device driver) and a standardized >> calling sequence for the device driver. >> > > Well, IPv6 standars discusses about off-link, on-link, etc, so "links" > are critical parts to understand addressing. > True. I have found that IPv6 works great for packetized communications even across communications media for which "link"-related terms aren't easily associated with physical reality. You have almost provided a road map for those parts of the IPv6 specification that need to be reinterpreted. > > > I do believe IP can work over a MANET (and I have performed experiments > with MANETs in my lab). I'm far from questioning this. My point is that > I think we can run IP over MANET without introducing drastic changes to > IP. > I agree. But I think we have to dispense with tight adherence to previously determined properties of wireline links. > >>> >> Especially the ones that don't think it's possible to run IP in a MANET. >> > > Again, I hope you are not referring to me here, because I do believe it. > I don't think it was you, but _somebody_ indicated they didn't think it was possible. > >> I think that determining which standards require revision is a problem in >> the solution space. >> > > Well, someone mentioned not using ND at all in MANETs in the last > meeting. I have this kind of example in mind when talking about this. > I'm among those who believe ND will require modification if it would be used at all. > >> Sorry, this is wrong. [autoconf] is chartered to make practical address >> autoconfiguration mechanisms. It's been shown to be possible. Now if >> we could just get to doing it instead of convincing people that IP can be >> run in a MANET. >> > > I'm sorry you think we are arguing against the feasibility of running IP > in a MANET, this is not true. I am willing to believe you are not among those making this argument. > I'm just trying to understand the best way > of _configuring IP addresses_ in a MANET, with as minimum changes to IP > model/protocols as necessary. > Here, necessity is defined by the range of applicability. In order to expand the range of applicability to large and/or highly mobile network populations of wireless nodes, modifications are going to be required, and the concept of "link" as defined in the IPv6 specifications is not helping. > I just tried to help with this thread, but I guess I've failed again. > Maybe I should keep myself quieter from now on... > > I don't ask anyone to be quieter, but I like it better when they are not deaf. Regards, Charlie P. From hrogge@googlemail.com Tue Nov 17 11:40:55 2009 Return-Path: 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 58EEC3A6AA3 for ; Tue, 17 Nov 2009 11:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 2EPIcpQRjwyt for ; Tue, 17 Nov 2009 11:40:54 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 4974B3A686D for ; Tue, 17 Nov 2009 11:40:54 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id 9so84363eyd.51 for ; Tue, 17 Nov 2009 11:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=z1DLnNtZLMlBWOV/UC9p46EUJcKJHlv+S8WpH/0lhSM=; b=FF6zM+q7ojxinYyzoJGtn2qLYVbAqaVBz0lCwXwy0SF8f5NuNb/gjWJH5GYlC7jcdl NaXeVKW4l1zwvkJb4/At4jPHIvscbtZucKu2FUIOMFbBGJgFcy6lCH3b4TZBVQdu/Lwo vo523QTIdWE1Q4vi/GRaK8GCbGcY8lucrHDZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=Kf4RODIDBGl/slifwbKfJFBHWnFzcT0sS8I5Ii3d64MeXN4md36JyiN2eait2JmWsm 62heB0UhjmBF7cVTkXCzU/li5R1okth/evfgHuJ0glL7D37Q950U3KnPtyuW/C//spWC A5zA67wC0A5n9loR4jl0Xk+x0bBhac3dEf0jY= Received: by 10.213.100.11 with SMTP id w11mr2344250ebn.34.1258486848449; Tue, 17 Nov 2009 11:40:48 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm516836eyg.17.2009.11.17.11.40.47 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 11:40:47 -0800 (PST) From: Henning Rogge To: autoconf@ietf.org Date: Tue, 17 Nov 2009 20:40:42 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <1258484841.30701.43.camel@acorde.it.uc3m.es> <4B02FA14.4090301@earthlink.net> In-Reply-To: <4B02FA14.4090301@earthlink.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart40599123.fa2aK5yjno"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911172040.47026.hrogge@googlemail.com> Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 19:40:55 -0000 --nextPart40599123.fa2aK5yjno Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Am Dienstag 17 November 2009 20:31:32 schrieb Charles E. Perkins: > > Well, someone mentioned not using ND at all in MANETs in the last > > meeting. I have this kind of example in mind when talking about this. >=20 > I'm among those who believe ND will require modification > if it would be used at all. I think we had already some suggestion how to deal with it... a) If you have unique MAC addresses, use them for IP generation and be happ= y. b) If you have a good source of random numbers, use them for IP generation = and=20 be happy. c) If you don't have any of this, maybe a protocol to generate some random= =20 input in the mesh would be a sollution (just continue with b). Henning Rogge --nextPart40599123.fa2aK5yjno Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAksC/D8ACgkQcenvcwAcHWeGVgCfXZ4bXSbH/DMwpR9kr2FRsA8Q I+IAn0jGDTj4rL+Ulp9cd2D+J/URri1F =gxX2 -----END PGP SIGNATURE----- --nextPart40599123.fa2aK5yjno-- From cjbc@it.uc3m.es Tue Nov 17 11:47:32 2009 Return-Path: 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 756B33A67AB for ; Tue, 17 Nov 2009 11:47:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] 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 dtszEmeR4IKw for ; Tue, 17 Nov 2009 11:47:31 -0800 (PST) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 66B293A67FA for ; Tue, 17 Nov 2009 11:47:31 -0800 (PST) X-uc3m-safe: yes Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 653716C2F21; Tue, 17 Nov 2009 20:47:28 +0100 (CET) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Henning Rogge In-Reply-To: <200911172040.47026.hrogge@googlemail.com> References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <1258484841.30701.43.camel@acorde.it.uc3m.es> <4B02FA14.4090301@earthlink.net> <200911172040.47026.hrogge@googlemail.com> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-8pP5Vr5lXCCyjKEeCDzX" Organization: Universidad Carlos III de Madrid Date: Tue, 17 Nov 2009 20:47:29 +0100 Message-Id: <1258487249.30701.45.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.26.3 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17016.000 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2009 19:47:32 -0000 --=-8pP5Vr5lXCCyjKEeCDzX Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable On Tue, 2009-11-17 at 20:40 +0100, Henning Rogge wrote: > Am Dienstag 17 November 2009 20:31:32 schrieb Charles E. Perkins: > > > Well, someone mentioned not using ND at all in MANETs in the last > > > meeting. I have this kind of example in mind when talking about this. > >=20 > > I'm among those who believe ND will require modification > > if it would be used at all. > I think we had already some suggestion how to deal with it... >=20 > a) If you have unique MAC addresses, use them for IP generation and be ha= ppy. > b) If you have a good source of random numbers, use them for IP generatio= n and=20 > be happy. > c) If you don't have any of this, maybe a protocol to generate some rando= m=20 > input in the mesh would be a sollution (just continue with b). This is not modification of ND, IMHO. Current specs allow to do any of this. Carlos >=20 > Henning Rogge --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-8pP5Vr5lXCCyjKEeCDzX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAksC/dEACgkQNdy6TdFwT2dSrQCg0Z1bHjec+5sRHU/AKKNVW/UV QdsAoJQGXK/UnGutNhEbWdTMAn6VsBap =ZDUs -----END PGP SIGNATURE----- --=-8pP5Vr5lXCCyjKEeCDzX-- From hrogge@googlemail.com Tue Nov 17 11:54:58 2009 Return-Path: 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 C58413A6BDB for ; Tue, 17 Nov 2009 11:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 SSTh5TOo+hyD for ; Tue, 17 Nov 2009 11:54:57 -0800 (PST) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 7F9543A6986 for ; Tue, 17 Nov 2009 11:54:57 -0800 (PST) Received: by qw-out-2122.google.com with SMTP id 9so114509qwb.31 for ; Tue, 17 Nov 2009 11:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=8MhTIpUeK5EWuKAZ6eANILh10aAvhZJjhR6qMakGqlI=; b=JIZsoSPMynd9qfihsl04/dkyNBCEMC+FkylQJwBGO9uHKNCrDsCqmw3ILFkeufHxJI 5sWIQVJg8qww85xzKQW+nbnJUYW/e9okQEvbV9ARkCbUP9G0Et0KdDB9NzfsUS9VzPbw gwiND0FGNIYkT8YFL4VZdGmxxr3+Kb1sYuZjs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=mKOl/QPrH/NbhCU6e54LMG6DliQfhPa7+IM+C/bUyxiHxuzjBc0+es1dZp2Oipqey/ 24PMaTmU1Kf/KjNbFr28KduuvKA5Q39O1Mg3KPuZKBHBknfYJbPujKWXEWxnbJjjX3MN kVDAIz0WM3BaqcXytq2edjqXssRciB9D+WTQM= Received: by 10.213.102.138 with SMTP id g10mr2780160ebo.85.1258487692026; Tue, 17 Nov 2009 11:54:52 -0800 (PST) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id 7sm542285eyg.17.2009.11.17.11.54.51 (version=SSLv3 cipher=RC4-MD5); Tue, 17 Nov 2009 11:54:51 -0800 (PST) From: Henning Rogge To: cjbc@it.uc3m.es Date: Tue, 17 Nov 2009 20:54:46 +0100 User-Agent: KMail/1.12.3 (Linux/2.6.31-gentoo-r5; KDE/4.3.3; x86_64; ; ) References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <200911172040.47026.hrogge@googlemail.com> <1258487249.30701.45.camel@acorde.it.uc3m.es> In-Reply-To: <1258487249.30701.45.camel@acorde.it.uc3m.es> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2135803.I3BtMkZglL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911172054.50817.hrogge@googlemail.com> Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 19:54:58 -0000 --nextPart2135803.I3BtMkZglL Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Am Dienstag 17 November 2009 20:47:29 schrieb Carlos Jes=FAs Bernardos Cano: > On Tue, 2009-11-17 at 20:40 +0100, Henning Rogge wrote: > > Am Dienstag 17 November 2009 20:31:32 schrieb Charles E. Perkins: > > > > Well, someone mentioned not using ND at all in MANETs in the last > > > > meeting. I have this kind of example in mind when talking about thi= s. > > > > > > I'm among those who believe ND will require modification > > > if it would be used at all. > > > > I think we had already some suggestion how to deal with it... > > > > a) If you have unique MAC addresses, use them for IP generation and be > > happy. b) If you have a good source of random numbers, use them for IP > > generation and be happy. > > c) If you don't have any of this, maybe a protocol to generate some > > random input in the mesh would be a sollution (just continue with b). >=20 > This is not modification of ND, IMHO. Current specs allow to do any of > this. The modification we would need would have to go into DAD (to check if we go= od=20 a collision). Instead of directly listening to other DAD checkers using our= =20 interface IP, we would have to programm a DAD which detects if TWO of it's= =20 neighbors are using the same IP and send some kind of "please change this I= P"=20 message as a broadcast. This should be enough to get the ABC-Problem under= =20 controll. In moving networks with changing connectivity we have of course to do this= =20 constantly. Henning Rogge --nextPart2135803.I3BtMkZglL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.13 (GNU/Linux) iEYEABECAAYFAksC/4oACgkQcenvcwAcHWf1ewCcDCZIt5Bac1DwxukeDcRUZ7HS 8LQAn05O+vMlJWSa4VDSZiNdRJp6mAPx =B6d6 -----END PGP SIGNATURE----- --nextPart2135803.I3BtMkZglL-- From alexandru.petrescu@gmail.com Tue Nov 17 13:03:17 2009 Return-Path: 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 EFEB13A69B8 for ; Tue, 17 Nov 2009 13:03:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.415 X-Spam-Level: X-Spam-Status: No, score=-0.415 tagged_above=-999 required=5 tests=[AWL=-0.580, BAYES_40=-0.185, 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 XeBEmkYxg7aA for ; Tue, 17 Nov 2009 13:03:16 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id DBBEA3A6988 for ; Tue, 17 Nov 2009 13:03:14 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 4C45DD48118; Tue, 17 Nov 2009 22:03:07 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id ED1EFD48082; Tue, 17 Nov 2009 22:03:04 +0100 (CET) Message-ID: <4B030F86.1060604@gmail.com> Date: Tue, 17 Nov 2009 22:03:02 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> In-Reply-To: <4B02EF2C.6020403@earthlink.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091117-0, 17/11/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 21:03:17 -0000 Charles E. Perkins a écrit : > Second, there are examples of 1000 node networks where > each node is minimal. Charles - there's no network of 1000 sensors I am aware of that runs IP and that uses exclusively 1-interface routers and /128 prefixes per their interfaces. > Third, a single human could easily deploy a 1000 node sensor > network. Tell about an example. > So, in just this one excerpt you have exhibited fundamental > disregard (I won't say ignorance) for existing technology. > > In a previous email to you, I exhibited nearly a half-dozen > errors in a _single sentence_. > > You insist on necessitating a central role for a "link", in YEs - link is of paramount importance. You also need a communication medium but you simply don't want 4861-links, that's all. You avoid defining them and always claim you and only you understand its non-understandable behaviours. You sometimes use it to explain some protocol design choices, but I can't understand these choices because I simply don't understand what you mean by non-deterministic links and time/space variation of stuff. > a network where such the communications medium identified > by such a concept is likely to be varying very quickly in > time and space, sometimes almost unpredictably. The > experience of others (who do those 1000 node networks) > leads towards certain design decisions that you disregard. Hmmm... tell me about one such 1000node network running IP on each node and 1-interface routers exclusively, and /128 prefixes-per-interfaces... never seen one. I believe it exagerated. If it ran by your AUTOCONF rules then each node would have a host-based route for every other node (i.e. 1000 entries in each node memory), or, sensor nodes are so restricted in memory that their stack takes much of the place. That's why I believe your 1000node claims exagerated. > [cf: >> No no, I am deaf :-) > ]. YEs, and I stay deaf to these statements that don't follow. > And yet you want to occupy the attention and restrict > the solution space available to practitioners who seem to > have far more experience than you, regardless of your > ability to respond to paper review requests. Hmm... at some point I get bored... Alex From charles.perkins@earthlink.net Tue Nov 17 13:23:28 2009 Return-Path: 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 F2BE43A68B6 for ; Tue, 17 Nov 2009 13:23:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.578 X-Spam-Level: X-Spam-Status: No, score=-1.578 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 0ksBdvl+BCdP for ; Tue, 17 Nov 2009 13:23:27 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 0A0213A67E9 for ; Tue, 17 Nov 2009 13:23:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Vbcb7MtjlEzQmXQ6SHZl4M+MkBiEeN26pLGLv9h5jWJigyomW0MgzX/JSqenhlZZ; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.154]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NAVWG-0008GO-45; Tue, 17 Nov 2009 16:23:24 -0500 Message-ID: <4B031448.7090701@earthlink.net> Date: Tue, 17 Nov 2009 13:23:20 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> <4B030F86.1060604@gmail.com> In-Reply-To: <4B030F86.1060604@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5256e8fe95867d671fabef5cf58f6debed350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 21:23:28 -0000 Hello Alex, Alexandru Petrescu wrote: > Charles E. Perkins a écrit : >> Second, there are examples of 1000 node networks where >> each node is minimal. > > Charles - there's no network of 1000 sensors I am aware of that runs > IP and that uses exclusively 1-interface routers and /128 prefixes per > their interfaces. Ohio State University. Rutgers University/GENI Others may give you other citations. > >> Third, a single human could easily deploy a 1000 node sensor >> network. > > Tell about an example. Dropping motion sensors from an airplane. > > >> >> >> You insist on necessitating a central role for a "link", in > > YEs - link is of paramount importance. > > You also need a communication medium but you simply don't want > 4861-links, that's all. Not "simply". Not "that's all". Not just me. > > > You avoid defining them and always claim you and only you understand > its non-understandable behaviours. This is a totally false and unwarranted accusation. > You sometimes use it to explain some protocol design choices, but I > can't understand these choices because I simply don't understand what > you mean by non-deterministic links and time/space variation of stuff. Those words have well-defined meanings. I personally do not use the terminology "non-deterministic". Maybe you are confusing me with someone else. > > > Hmmm... tell me about one such 1000node network running IP on each > node and 1-interface routers exclusively, and /128 > prefixes-per-interfaces... never seen one. See above. > > > If it ran by your AUTOCONF rules then each node would have a > host-based route for every other node (i.e. 1000 entries in each node > memory), or, sensor nodes are so restricted in memory that their stack > takes much of the place. No, each node only requires host routes for destinations required by its applications. > > That's why I believe your 1000node claims exagerated. You must be trying to convince me that proactive link-state protocols have larger memory requirements. > >> [cf: >>> No no, I am deaf :-) >> ]. > > YEs, and I stay deaf to these statements that don't follow. Whenever I am having a technical discussion, I try to understand how the arguments which are presented can be interpreted so that they make sense. > >> And yet you want to occupy the attention and restrict >> the solution space available to practitioners who seem to >> have far more experience than you, regardless of your >> ability to respond to paper review requests. > > Hmm... at some point I get bored... I'm long past bored. Regards, Charlie P. From alexandru.petrescu@gmail.com Tue Nov 17 14:29:41 2009 Return-Path: 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 C1FA13A6B30 for ; Tue, 17 Nov 2009 14:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_40=-0.185, GB_I_INVITATION=-2, 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 gIO-MbFpIuDw for ; Tue, 17 Nov 2009 14:29:40 -0800 (PST) Received: from smtp5-g21.free.fr (smtp5-g21.free.fr [212.27.42.5]) by core3.amsl.com (Postfix) with ESMTP id 8579E3A6B28 for ; Tue, 17 Nov 2009 14:29:38 -0800 (PST) Received: from smtp5-g21.free.fr (localhost [127.0.0.1]) by smtp5-g21.free.fr (Postfix) with ESMTP id 62023D480B9; Tue, 17 Nov 2009 23:29:32 +0100 (CET) Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp5-g21.free.fr (Postfix) with ESMTP id 9FB5FD48050; Tue, 17 Nov 2009 23:29:29 +0100 (CET) Message-ID: <4B0323C7.3060902@gmail.com> Date: Tue, 17 Nov 2009 23:29:27 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Charles E. Perkins" References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> <4B030F86.1060604@gmail.com> <4B031448.7090701@earthlink.net> In-Reply-To: <4B031448.7090701@earthlink.net> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 091117-0, 17/11/2009), Outbound message X-Antivirus-Status: Clean Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 22:29:41 -0000 Charles E. Perkins a écrit : > > Hello Alex, > > Alexandru Petrescu wrote: >> Charles E. Perkins a écrit : >>> Second, there are examples of 1000 node networks where each node >>> is minimal. >> >> Charles - there's no network of 1000 sensors I am aware of that >> runs IP and that uses exclusively 1-interface routers and /128 >> prefixes per their interfaces. > > Ohio State University. It's a big University, what of if more exactly? Is this claim similar to the recent claim that said large networks in Vienna, and yet there are two-interface routers? > > Rutgers University/GENI I do follow GENI and what I see is invitations to conferences - should I accept these invitations? And I don't see networks of 1000s IP 1-interface sensors. > Others may give you other citations. > >> >>> Third, a single human could easily deploy a 1000 node sensor >>> network. >> >> Tell about an example. > > Dropping motion sensors from an airplane. Again - I agree with you in the sense they represent great goals, ideal in a sense. However, I don't see it happening as you describe it, i.e. IP on each sensor dropped from planes. And I did see sensor networks. > >> >> >>> >>> >>> You insist on necessitating a central role for a "link", in >> >> YEs - link is of paramount importance. >> >> You also need a communication medium but you simply don't want >> 4861-links, that's all. > > Not "simply". Not "that's all". Not just me. > >> >> >> You avoid defining them and always claim you and only you >> understand its non-understandable behaviours. > > This is a totally false and unwarranted accusation. Politeness here ok - no accusation. > >> You sometimes use it to explain some protocol design choices, but I >> can't understand these choices because I simply don't understand >> what you mean by non-deterministic links and time/space variation >> of stuff. > > Those words have well-defined meanings. I personally do not use the > terminology "non-deterministic". Maybe you are confusing me with > someone else. You continue saying these ABC-links are different than existing links, with a timespace vocabulary proper to only the pure PHY-inclined. Not that they're not right, but they simply don't use IP - they use OFDMA MIMO and such. >> Hmmm... tell me about one such 1000node network running IP on each >> node and 1-interface routers exclusively, and /128 >> prefixes-per-interfaces... never seen one. > > See above. > >> >> >> If it ran by your AUTOCONF rules then each node would have a >> host-based route for every other node (i.e. 1000 entries in each >> node memory), or, sensor nodes are so restricted in memory that >> their stack takes much of the place. > > No, each node only requires host routes for destinations required by > its applications. Cross-layer violation? How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY) from AUTOCONF? Let me say I refuse completely to agree on this cross-layer violation: applications dictate which route should be present or not. Applications use sockets to send/rcv data that's all. I don't want to fiddle beneath them. I did enough fiddling with below apps Mobile IP to know what I'm talking about. >> That's why I believe your 1000node claims exagerated. > > You must be trying to convince me that proactive link-state protocols > have larger memory requirements. You may like me to, but no. Not my intention was that. I simply don't agree with the app-dictates-routes. There will always exist apps unaware of the supposed routing fiddling. The only interface they assume is their Socket, which is very good. That Socket doens't know MANET. BEsides, I don't want my app blocked until some routing protocol finds its paths through a 1000node unstructured maze. These are enough basic things for me to be in full disagreement with the MANETs as presented. The only way to get past that is to decouple MANET from AUTOCONF. Alex >>> [cf: >>>> No no, I am deaf :-) >>> ]. >> >> YEs, and I stay deaf to these statements that don't follow. > > Whenever I am having a technical discussion, I try to understand how > the arguments which are presented can be interpreted so that they > make sense. > > >> >>> And yet you want to occupy the attention and restrict the >>> solution space available to practitioners who seem to have far >>> more experience than you, regardless of your ability to respond >>> to paper review requests. >> >> Hmm... at some point I get bored... > > I'm long past bored. > > Regards, Charlie P. > > From thomas@thomasclausen.org Tue Nov 17 15:12:19 2009 Return-Path: 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 D618B3A6A29 for ; Tue, 17 Nov 2009 15:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 1sErjUT-Kwg2 for ; Tue, 17 Nov 2009 15:12:15 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id E03F73A6A11 for ; Tue, 17 Nov 2009 15:12:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id B9B51430535; Tue, 17 Nov 2009 15:12:07 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-90-209.w92-140.abo.wanadoo.fr [92.140.105.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 27379430537; Tue, 17 Nov 2009 15:12:05 -0800 (PST) Message-Id: <1FF68FFE-66A2-4C9A-9A6A-7D3AB41DFED5@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B0323C7.3060902@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-4-1019449149 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 00:12:03 +0100 References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> <4B030F86.1060604@gmail.com> <4B031448.7090701@earthlink.net> <4B0323C7.3060902@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 23:12:19 -0000 --Apple-Mail-4-1019449149 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Nov 17, 2009, at 11:29 PM, Alexandru Petrescu wrote: > Charles E. Perkins a =E9crit : >> > >>> Hmmm... tell me about one such 1000node network running IP on each >>> node and 1-interface routers exclusively, and /128 prefixes-per-=20 >>> interfaces... never seen one. >> See above. >>> If it ran by your AUTOCONF rules then each node would have a host-=20= >>> based route for every other node (i.e. 1000 entries in each >>> node memory), or, sensor nodes are so restricted in memory that >>> their stack takes much of the place. >> No, each node only requires host routes for destinations required by >> its applications. > > Cross-layer violation? > > How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY) > from AUTOCONF? > Fortunately, MANETs are just like the rest of the Internet, also in =20 that regard. > Let me say I refuse completely to agree on this cross-layer violation: Fortunately, there is none. > applications dictate which route should be present or not. =20 > Applications > use sockets to send/rcv data that's all. I don't want to fiddle =20 > beneath > them. I did enough fiddling with below apps Mobile IP to know what =20= > I'm > talking about. Fortunately, no fiddling is needed. >>> That's why I believe your 1000node claims exagerated. >> You must be trying to convince me that proactive link-state protocols >> have larger memory requirements. > > You may like me to, but no. Not my intention was that. > > I simply don't agree with the app-dictates-routes. Fortunately, they don't no more than they do in the Internet. > There will always exist apps unaware of the supposed routing fiddling. > The only interface they assume is their Socket, which is very good. > That Socket doens't know MANET. > > BEsides, I don't want my app blocked until some routing protocol > finds its paths through a 1000node unstructured maze. Fortunately, this is not the case. > These are enough basic things for me to be in full disagreement with =20= > the > MANETs as presented. It would appear, that the things you imagine above do not hold for =20 MANETs. > The only way to get past that is to decouple MANET from AUTOCONF. No, not at all. Thomas > > Alex > > >>>> [cf: >>>>> No no, I am deaf :-) >>>> ]. >>> YEs, and I stay deaf to these statements that don't follow. >> Whenever I am having a technical discussion, I try to understand how >> the arguments which are presented can be interpreted so that they >> make sense. >>>> And yet you want to occupy the attention and restrict the >>>> solution space available to practitioners who seem to have far >>>> more experience than you, regardless of your ability to respond >>>> to paper review requests. >>> Hmm... at some point I get bored... >> I'm long past bored. >> Regards, Charlie P. > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --Apple-Mail-4-1019449149 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Nov 17, 2009, = at 11:29 PM, Alexandru Petrescu wrote:

Charles= E. Perkins a =E9crit = :

<SNIP>



Hmmm... tell me about one such = 1000node network running IP on = each
node and 1-interface routers exclusively, and /128 = prefixes-per-interfaces... never seen = one.
See = above.
If it ran by your AUTOCONF rules then each node would have = a host-based route for every other node (i.e. 1000 entries in = each
node memory), or, sensor nodes are so restricted in memory = that
their stack takes much of the = place.
No, each = node only requires host routes for destinations required = by
its = applications.

Cross-layer violation?

How = about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY)
from = AUTOCONF?


Fortunately, MANETs = are just like the rest of the Internet, also in that = regard.

Let me say I refuse = completely to agree on this cross-layer = violation:

Fortunately, there is = none.

applications dictate = which route should be present or not.  Applications
use sockets = to send/rcv data that's all.  I don't want to fiddle = beneath
them.  I did enough fiddling with below apps Mobile IP = to know what I'm
talking = about.

Fortunately, no = fiddling is needed.

That's why I believe your = 1000node claims exagerated.
You must be trying to convince me that proactive = link-state protocols
have = larger memory requirements.

You may like me to, but = no.  Not my intention was that.

I simply don't agree with = the = app-dictates-routes.

Fortunately, = they don't no more than they do in the = Internet.

There will always = exist apps unaware of the supposed routing fiddling.
The only = interface they assume is their Socket, which is very good.
That = Socket doens't know MANET.

BEsides, I don't want my app blocked = until some routing protocol
finds its paths through a 1000node = unstructured = maze.

Fortunately, this is not = the case.

These are = enough basic things for me to be in full disagreement with the
MANETs = as presented.

It would appear, = that the things you imagine above do not hold for = MANETs.

The only way = to get past that is to decouple MANET from = AUTOCONF.

No, not at = all.

Thomas


Alex


[cf:
No no, I am deaf = :-)
].
YEs, and I stay deaf to these = statements that don't follow.
Whenever I am having a technical discussion, I try to = understand how
the arguments = which are presented can be interpreted so that = they
make = sense.
And yet you want to occupy the = attention and restrict = the
solution= space available to practitioners who seem to have = far
more = experience than you, regardless of your ability to = respond
to = paper review = requests.
Hmm... at some point I get = bored...
I'm long = past bored.
Regards, Charlie = P.

_______________________________________________
= Autoconf mailing list
Autoconf@ietf.org
https://www.iet= f.org/mailman/listinfo/autoconf

= --Apple-Mail-4-1019449149-- From charliep@wichorus.com Tue Nov 17 15:08:19 2009 Return-Path: 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 3069B3A6A29 for ; Tue, 17 Nov 2009 15:08:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 uH3hg-a8krSK for ; Tue, 17 Nov 2009 15:08:18 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id 40B153A68AD for ; Tue, 17 Nov 2009 15:08:18 -0800 (PST) Received: from [12.204.153.98] (helo=[10.166.254.154]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NAX9k-0005Az-Ax; Tue, 17 Nov 2009 18:08:16 -0500 Message-ID: <4B032CDD.9090803@wichorus.com> Date: Tue, 17 Nov 2009 15:08:13 -0800 From: "Charles E. Perkins" Organization: WiChorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "autoconf@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5298a1072431f6890fd02976cc3df39473350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 X-Mailman-Approved-At: Tue, 17 Nov 2009 15:12:54 -0800 Cc: Emmanuel Baccelli Subject: [Autoconf] [Fwd: New Version Notification for draft-baccelli-multi-hop-wireless-communication-03] X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 23:08:19 -0000 Hello folks, I've submitted a new revision for the Independent Submission: "Multi-hop Ad Hoc Wireless Communication". It is available at the following URL: http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-communication-03.txt Regards, Charlie P. -------- Original Message -------- Subject: New Version Notification for draft-baccelli-multi-hop-wireless-communication-03 Date: Tue, 17 Nov 2009 18:03:02 -0500 From: IETF I-D Submission Tool To: Charles E. Perkins CC: Emmanuel.Baccelli@inria.fr A new version of I-D, draft-baccelli-multi-hop-wireless-communication-03.txt has been successfuly submitted by Charles Perkins and posted to the IETF repository. Filename: draft-baccelli-multi-hop-wireless-communication Revision: 03 Title: Multi-hop Ad Hoc Wireless Communication Creation_date: 2009-11-17 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document describes some important characteristics of communication between nodes in a multi-hop ad hoc wireless network. These are not requirements in the sense usually understood as applying to formulation of a requirements document. Nevertheless, protocol engineers and system analysts involved with designing solutions for ad hoc networks must maintain awareness of these characteristics. Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May 21, 2010.Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. The IETF Secretariat. From super.ismiti@gmail.com Tue Nov 17 15:21:44 2009 Return-Path: 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 4CAF63A6B1E for ; Tue, 17 Nov 2009 15:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2] 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 eFLW5ZJCOAfZ for ; Tue, 17 Nov 2009 15:21:43 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id F0F353A6B15 for ; Tue, 17 Nov 2009 15:21:42 -0800 (PST) Received: by pzk6 with SMTP id 6so337472pzk.29 for ; Tue, 17 Nov 2009 15:21:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Mqs2Hz5McutkYU6r4jdbanNZ4D269l3U9N5J98fVZSw=; b=o36Vn6WGHcC1GoLV1jdXE4f8oVhxONC+o0AA09g/Sjuk7G8aDboRHACbeuoBKjug8M Cq1jcCUyNj1ht1+Y5QOv6xUbI9T9XeZ9bt8FVOFuwKBS1CyWwcqVFM3lt+7GrEzYkdte jBaGl2h6MfNyrTAkqXGxuS1LoGd7VC8ROa7RA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=f31i1lqnQzZPa1f1RCA1GwOcqF0NSb3z0MAV+Inf269IUVBvhBFEode8DtDPGbsbKS cjF24YnmnW80LJotjavNUkON5dF05AF/htcBHptAYajqL5RyO+c9OCFy3FdZgMQAl+XV aRe3ThjjNVdHrPxYXqWTget1mpcK6tV1oLz9o= MIME-Version: 1.0 Received: by 10.142.250.36 with SMTP id x36mr1102684wfh.176.1258500099331; Tue, 17 Nov 2009 15:21:39 -0800 (PST) In-Reply-To: <4B0323C7.3060902@gmail.com> References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> <4B030F86.1060604@gmail.com> <4B031448.7090701@earthlink.net> <4B0323C7.3060902@gmail.com> Date: Tue, 17 Nov 2009 20:21:39 -0300 Message-ID: From: Ricardo Schmidt To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 23:21:44 -0000 Here we have a good example: http://www.cs.wayne.edu/~hzhang/ 1,400-node mesh network at Wayne State University. On Tue, Nov 17, 2009 at 7:29 PM, Alexandru Petrescu wrote: > Charles E. Perkins a =E9crit : >> >> Hello Alex, >> >> Alexandru Petrescu wrote: >>> >>> Charles E. Perkins a =E9crit : >>>> >>>> Second, there are examples of 1000 node networks where each node >>>> is minimal. >>> >>> Charles - there's no network of 1000 sensors I am aware of that >>> runs IP and that uses exclusively 1-interface routers and /128 >>> prefixes per their interfaces. >> >> Ohio State University. > > It's a big University, what of if more exactly? > > Is this claim similar to the recent claim that said large networks in > Vienna, and yet there are two-interface routers? > >> >> Rutgers University/GENI > > I do follow GENI and what I see is invitations to conferences - should I > accept these invitations? =A0And I don't see networks of 1000s IP > 1-interface sensors. > >> Others may give you other citations. >> >>> >>>> Third, a single human could easily deploy a 1000 node sensor network. >>> >>> Tell about an example. >> >> Dropping motion sensors from an airplane. > > Again - I agree with you in the sense they represent great goals, ideal > in a sense. > > However, I don't see it happening as you describe it, i.e. IP on each > sensor dropped from planes. > > And I did see sensor networks. > >> >>> >>> >>>> >>>> >>>> You insist on necessitating a central role for a "link", in >>> >>> YEs - link is of paramount importance. >>> >>> You also need a communication medium but you simply don't want >>> 4861-links, that's all. >> >> Not "simply". =A0Not "that's all". =A0Not just me. >> >>> >>> >>> You avoid defining them and always claim you and only you >>> understand its non-understandable behaviours. >> >> This is a totally false and unwarranted accusation. > > Politeness here ok - no accusation. > >> >>> You sometimes use it to explain some protocol design choices, but I >>> =A0can't understand these choices because I simply don't understand >>> what you mean by non-deterministic links and time/space variation >>> of stuff. >> >> Those words have well-defined meanings. =A0I personally do not use the >> terminology "non-deterministic". =A0Maybe you are confusing me with >> someone else. > > You continue saying these ABC-links are different than existing links, > with a timespace vocabulary proper to only the pure PHY-inclined. =A0Not > that they're not right, but they simply don't use IP - they use OFDMA > MIMO and such. > >>> Hmmm... tell me about one such 1000node network running IP on each >>> =A0node and 1-interface routers exclusively, and /128 >>> prefixes-per-interfaces... never seen one. >> >> See above. >> >>> >>> >>> If it ran by your AUTOCONF rules then each node would have a host-based >>> route for every other node (i.e. 1000 entries in each >>> node memory), or, sensor nodes are so restricted in memory that >>> their stack takes much of the place. >> >> No, each node only requires host routes for destinations required by >> its applications. > > Cross-layer violation? > > How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY) > from AUTOCONF? > > Let me say I refuse completely to agree on this cross-layer violation: > applications dictate which route should be present or not. =A0Application= s > use sockets to send/rcv data that's all. =A0I don't want to fiddle beneat= h > them. =A0I did enough fiddling with below apps Mobile IP to know what I'm > talking about. > >>> That's why I believe your 1000node claims exagerated. >> >> You must be trying to convince me that proactive link-state protocols >> have larger memory requirements. > > You may like me to, but no. =A0Not my intention was that. > > I simply don't agree with the app-dictates-routes. > > There will always exist apps unaware of the supposed routing fiddling. > The only interface they assume is their Socket, which is very good. > That Socket doens't know MANET. > > BEsides, I don't want my app blocked until some routing protocol > finds its paths through a 1000node unstructured maze. > > These are enough basic things for me to be in full disagreement with the > MANETs as presented. > > The only way to get past that is to decouple MANET from AUTOCONF. > > Alex > > >>>> [cf: >>>>> >>>>> No no, I am deaf :-) >>>> >>>> ]. >>> >>> YEs, and I stay deaf to these statements that don't follow. >> >> Whenever I am having a technical discussion, I try to understand how >> the arguments which are presented can be interpreted so that they >> make sense. >> >> >>> >>>> And yet you want to occupy the attention and restrict the >>>> solution space available to practitioners who seem to have far >>>> more experience than you, regardless of your ability to respond >>>> to paper review requests. >>> >>> Hmm... at some point I get bored... >> >> I'm long past bored. >> >> Regards, Charlie P. >> >> > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf From super.ismiti@gmail.com Tue Nov 17 15:22:17 2009 Return-Path: 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 1FF7728C195 for ; Tue, 17 Nov 2009 15:22:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2] 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 dzmY2U9+qNaQ for ; Tue, 17 Nov 2009 15:22:16 -0800 (PST) Received: from mail-pz0-f176.google.com (mail-pz0-f176.google.com [209.85.222.176]) by core3.amsl.com (Postfix) with ESMTP id 09EA728C194 for ; Tue, 17 Nov 2009 15:22:16 -0800 (PST) Received: by pzk6 with SMTP id 6so337798pzk.29 for ; Tue, 17 Nov 2009 15:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JrQ3OOc4zop/bawxiNKwlauVFLytfaNMoa1su8YjJBQ=; b=Z6kuBi9oEXOawkP73Toxufz08ek8tswPQHyrphx0xiUgpfCiFyC6wjwCDXJ1XQXtEe FUxk0/EQZ0/NFjaq3/G2EgzJCRedrkqlapmj/wilZMx4N4dUmEyXM87jsstGc0LQjo7n 7HTKZpT0ET+XMFV8v/dQtfkPGmueOH9uAPVRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=nLkLHqJs8oUnRhF5O3vOdttyg/S2XMbs9mCd0+CVY2Sm2jbf4n74mrdJRYOAi9WHbe IagcjURYm2g0ygmzWl8kk4xsyEQH/pAGup3VN1EjKsXoQOrbZpyd8aN8mZ0LtOgM7ebk nbtE8JIJcGbgu56dai2np4YxkGMlsK+vqIHAE= MIME-Version: 1.0 Received: by 10.142.74.19 with SMTP id w19mr1068980wfa.196.1258500132171; Tue, 17 Nov 2009 15:22:12 -0800 (PST) In-Reply-To: References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> <4B030F86.1060604@gmail.com> <4B031448.7090701@earthlink.net> <4B0323C7.3060902@gmail.com> Date: Tue, 17 Nov 2009 20:22:12 -0300 Message-ID: From: Ricardo Schmidt To: Alexandru Petrescu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 23:22:17 -0000 Sorry all, the link was wrong: http://www.cs.wayne.edu/~hzhang/ On Tue, Nov 17, 2009 at 8:21 PM, Ricardo Schmidt w= rote: > Here we have a good example: http://www.cs.wayne.edu/~hzhang/ > 1,400-node mesh network at Wayne State University. > > > > On Tue, Nov 17, 2009 at 7:29 PM, Alexandru Petrescu > wrote: >> Charles E. Perkins a =E9crit : >>> >>> Hello Alex, >>> >>> Alexandru Petrescu wrote: >>>> >>>> Charles E. Perkins a =E9crit : >>>>> >>>>> Second, there are examples of 1000 node networks where each node >>>>> is minimal. >>>> >>>> Charles - there's no network of 1000 sensors I am aware of that >>>> runs IP and that uses exclusively 1-interface routers and /128 >>>> prefixes per their interfaces. >>> >>> Ohio State University. >> >> It's a big University, what of if more exactly? >> >> Is this claim similar to the recent claim that said large networks in >> Vienna, and yet there are two-interface routers? >> >>> >>> Rutgers University/GENI >> >> I do follow GENI and what I see is invitations to conferences - should I >> accept these invitations? =A0And I don't see networks of 1000s IP >> 1-interface sensors. >> >>> Others may give you other citations. >>> >>>> >>>>> Third, a single human could easily deploy a 1000 node sensor network. >>>> >>>> Tell about an example. >>> >>> Dropping motion sensors from an airplane. >> >> Again - I agree with you in the sense they represent great goals, ideal >> in a sense. >> >> However, I don't see it happening as you describe it, i.e. IP on each >> sensor dropped from planes. >> >> And I did see sensor networks. >> >>> >>>> >>>> >>>>> >>>>> >>>>> You insist on necessitating a central role for a "link", in >>>> >>>> YEs - link is of paramount importance. >>>> >>>> You also need a communication medium but you simply don't want >>>> 4861-links, that's all. >>> >>> Not "simply". =A0Not "that's all". =A0Not just me. >>> >>>> >>>> >>>> You avoid defining them and always claim you and only you >>>> understand its non-understandable behaviours. >>> >>> This is a totally false and unwarranted accusation. >> >> Politeness here ok - no accusation. >> >>> >>>> You sometimes use it to explain some protocol design choices, but I >>>> =A0can't understand these choices because I simply don't understand >>>> what you mean by non-deterministic links and time/space variation >>>> of stuff. >>> >>> Those words have well-defined meanings. =A0I personally do not use the >>> terminology "non-deterministic". =A0Maybe you are confusing me with >>> someone else. >> >> You continue saying these ABC-links are different than existing links, >> with a timespace vocabulary proper to only the pure PHY-inclined. =A0Not >> that they're not right, but they simply don't use IP - they use OFDMA >> MIMO and such. >> >>>> Hmmm... tell me about one such 1000node network running IP on each >>>> =A0node and 1-interface routers exclusively, and /128 >>>> prefixes-per-interfaces... never seen one. >>> >>> See above. >>> >>>> >>>> >>>> If it ran by your AUTOCONF rules then each node would have a host-base= d >>>> route for every other node (i.e. 1000 entries in each >>>> node memory), or, sensor nodes are so restricted in memory that >>>> their stack takes much of the place. >>> >>> No, each node only requires host routes for destinations required by >>> its applications. >> >> Cross-layer violation? >> >> How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY) >> from AUTOCONF? >> >> Let me say I refuse completely to agree on this cross-layer violation: >> applications dictate which route should be present or not. =A0Applicatio= ns >> use sockets to send/rcv data that's all. =A0I don't want to fiddle benea= th >> them. =A0I did enough fiddling with below apps Mobile IP to know what I'= m >> talking about. >> >>>> That's why I believe your 1000node claims exagerated. >>> >>> You must be trying to convince me that proactive link-state protocols >>> have larger memory requirements. >> >> You may like me to, but no. =A0Not my intention was that. >> >> I simply don't agree with the app-dictates-routes. >> >> There will always exist apps unaware of the supposed routing fiddling. >> The only interface they assume is their Socket, which is very good. >> That Socket doens't know MANET. >> >> BEsides, I don't want my app blocked until some routing protocol >> finds its paths through a 1000node unstructured maze. >> >> These are enough basic things for me to be in full disagreement with the >> MANETs as presented. >> >> The only way to get past that is to decouple MANET from AUTOCONF. >> >> Alex >> >> >>>>> [cf: >>>>>> >>>>>> No no, I am deaf :-) >>>>> >>>>> ]. >>>> >>>> YEs, and I stay deaf to these statements that don't follow. >>> >>> Whenever I am having a technical discussion, I try to understand how >>> the arguments which are presented can be interpreted so that they >>> make sense. >>> >>> >>>> >>>>> And yet you want to occupy the attention and restrict the >>>>> solution space available to practitioners who seem to have far >>>>> more experience than you, regardless of your ability to respond >>>>> to paper review requests. >>>> >>>> Hmm... at some point I get bored... >>> >>> I'm long past bored. >>> >>> Regards, Charlie P. >>> >>> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > --=20 Ricardo Schmidt MSc candidate in Computer Science / UFPE BSc in Computer Science / UPF From charles.perkins@earthlink.net Tue Nov 17 15:53:06 2009 Return-Path: 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 C36253A6B1E for ; Tue, 17 Nov 2009 15:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 8vXgEmiY58yK for ; Tue, 17 Nov 2009 15:53:05 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by core3.amsl.com (Postfix) with ESMTP id C03E93A67B3 for ; Tue, 17 Nov 2009 15:53:05 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=o1QeMiuXAEQ0urRFihejWTBacoPDTrSbZA9R6COhaStqfXqeB6h7sEhDbuyob9YE; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.154]) by elasmtp-masked.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NAXqG-0000Rs-Kr; Tue, 17 Nov 2009 18:52:13 -0500 Message-ID: <4B033728.90200@earthlink.net> Date: Tue, 17 Nov 2009 15:52:08 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Alexandru Petrescu References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> <4B030F86.1060604@gmail.com> <4B031448.7090701@earthlink.net> <4B0323C7.3060902@gmail.com> In-Reply-To: <4B0323C7.3060902@gmail.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f5246d2137103f97abb86bbd95da4e9f9b8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Tue, 17 Nov 2009 23:53:06 -0000 Hello Alex, Alexandru Petrescu wrote: >>> >>> Tell about an example. >> >> Dropping motion sensors from an airplane. > > Again - I agree with you in the sense they represent great goals, ideal > in a sense. > > However, I don't see it happening as you describe it, i.e. IP on each > sensor dropped from planes. Well, that's the way it can happen. > > And I did see sensor networks. Sensor nets can run IP. > >>> >>> >>> You avoid defining them and always claim you and only you >>> understand its non-understandable behaviours. >> >> This is a totally false and unwarranted accusation. > > Politeness here ok - no accusation. Polite, impolite, rude, or downright vicious -- the statement is still totally false. > >> >>> You sometimes use it to explain some protocol design choices, but I >>> can't understand these choices because I simply don't understand >>> what you mean by non-deterministic links and time/space variation >>> of stuff. >> >> Those words have well-defined meanings. I personally do not use the >> terminology "non-deterministic". Maybe you are confusing me with >> someone else. > > You continue saying these ABC-links are different than existing links, > with a timespace vocabulary proper to only the pure PHY-inclined. Not > that they're not right, but they simply don't use IP - they use OFDMA > MIMO and such. I'm not the one talking about links. As far as IP is concerned, all that is needed is to formulate a packet that can be delivered to the next hop, and issue a call on the proper device driver to deliver it. No mind-torquing at all is required to understand this. And you are wrong to suggest that time variations are irrelevant to IP. As I recall, most routing protocols have timing parameters. I hope you will form a design team to work out a suitable ecology for understanding the meaning of the word "link" in your desired environment. > >>> >>> >>> If it ran by your AUTOCONF rules then each node would have a >>> host-based route for every other node (i.e. 1000 entries in each >>> node memory), or, sensor nodes are so restricted in memory that >>> their stack takes much of the place. >> >> No, each node only requires host routes for destinations required by >> its applications. > > Cross-layer violation? Absolutely not. The applications require no changes at all. > > How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY) > from AUTOCONF? Considering that they were never coupled, no problem. > > Let me say I refuse completely to agree on this cross-layer violation: > applications dictate which route should be present or not. Applications > use sockets to send/rcv data that's all. I don't want to fiddle beneath > them. This is a very convenient strawman for your wrath. > >> >> You must be trying to convince me that proactive link-state protocols >> have larger memory requirements. > > You may like me to, but no. Not my intention was that. > > I simply don't agree with the app-dictates-routes. > > There will always exist apps unaware of the supposed routing fiddling. > The only interface they assume is their Socket, which is very good. > That Socket doens't know MANET. Finally -- a point of 100% agreement between us. > > BEsides, I don't want my app blocked until some routing protocol > finds its paths through a 1000node unstructured maze. Nobody likes to wait. > > These are enough basic things for me to be in full disagreement with the > MANETs as presented. But that's the way MANETs _are_. > > The only way to get past that is to decouple MANET from AUTOCONF. That would be dumb. Regards, Charlie P. From amine.dhraief@hana-uma.org Wed Nov 18 00:30:23 2009 Return-Path: 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 D5B303A68EE for ; Wed, 18 Nov 2009 00:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.811 X-Spam-Level: X-Spam-Status: No, score=0.811 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_50=0.001, HOST_MISMATCH_COM=0.311] 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 NxaHSoJ6rqUc for ; Wed, 18 Nov 2009 00:30:22 -0800 (PST) Received: from hoxone.ch (ks368695.kimsufi.com [94.23.36.171]) by core3.amsl.com (Postfix) with ESMTP id 1E50E3A67FD for ; Wed, 18 Nov 2009 00:30:21 -0800 (PST) Received: (qmail 29533 invoked by uid 48); 18 Nov 2009 09:33:07 +0100 Received: from 196.203.135.2 ([196.203.135.2]) by webmail.hana-uma.org (Horde MIME library) with HTTP; Wed, 18 Nov 2009 09:33:07 +0100 Message-ID: <20091118093307.ywfci75dcs4cw4sg@webmail.hana-uma.org> Date: Wed, 18 Nov 2009 09:33:07 +0100 From: amine.dhraief@hana-uma.org To: autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.6) Subject: [Autoconf] [FT-ASN 10] Future Trends on Ad-hoc and Sensor Networks X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 08:32:10 -0000 =09*** Our apologies if you receive multiple copies of this CFP *** =09=09=09=09The ACS/IEEE Workshop =09=09Future Trends on Ad-hoc and Sensor Networks (FT-ASN) In Conjunction with the 8th ACS/IEEE International Conference on =20 Computer Systems and Applications AICCSA 2010 =09=09 =09Hammamet, Tunisia, May 16-19, 2010 Ad Hoc & Sensor Networks have solicited tremendous attentions from =20 both academic community and industry fields for many years. They are becoming an integral part of the current computing landscape =20 and certainly of future computing development and networking platforms. Along with the rapid development of hardware and embedded systems, ad =20 hoc and sensor networks are being further developed towards a large number of mobile and multimedia applications such as video =20 surveillance, traffic enforcement and control systems, advanced healthcare delivery, structural health monitoring, and =20 industrial process control. The support of mobility, multimedia, security and scalability raise =20 many challenging issues such as cross layer optimization, intelligent content aware transmission, scarce resource intelligent =20 allocation, mobile self organization, autonomic management and operation and secured communications and localization. Significant =20 research efforts are still needed from both academia community and industrial fields, yet further experimental enlightening is sought =20 from current deployments and test beds. The workshop aims to be a forum for researchers working on the design, =20 modelling, analysis and performance evaluation of Ad-hoc and Sensor =20 Networks. The objective of the workshop is to bring together state-of-the-art =20 research contributions, and position papers that address key aspects =20 of scalable, mobile, multimedia ad hoc and sensor networks. Original papers =20 describing completed and unpublished work not currently under review =20 are solicited. While we are especially interested in research submissions focusing =20 primarily on scalabilility, mobility, security and autonomic management, other aspects of ad hoc and sensor networks are also solicited. TOPICS OF INTEREST * Scalability and mobility issues in cross-layer design, and =20 optimization for effective communications * Scalable and flexible network architectures, deployments, and =20 heterogeneous applications * Applications and deployment experiences * Design tools and methodologies for sensor networks * Performance and security tradeoffs * Security under resource constraints (e.g., energy, bandwidth, =20 memory, and computation constraints) * Secure multimedia streaming and transmission, QoS and admission control * Secure location services * Secure clock distribution * Secure routing * Secure MAC protocols * Key management and Trust establishment, negotiation, and management * Resource assignment and sharing * Protocols for supporting real-time and reliable multimedia streaming * Energy-efficient multimedia gathering, transmission, traffic =20 management, and sensor data management * Topology control and synchronization protocols * Autonomic management and operation IMPORTANT DATES * Abstract deadline: Friday, January 8th, 2010 * Full papers due: Friday, January 15th, 2010 * Author notification: Friday, February 5th, 2010 * Camera ready due: Friday, February 12th, 2010 * Workshop-Conference: May 16-19, 2010 WORKSHOP ORGANIZING COMMITTEES Workshop General Chairs * Abdelfettah Belghith - University of Manouba, Tunisia * Mario Gerla - University of California at Los Angeles, USA Steering Committee * Abdelfettah Belghith - HANA Research Group, University of Manouba, Tunisia * Habib Youssef - Prince, University of Sousse, Tunisia * Mohamed Abid - CES, University of Sfax, Tunisia * Riadh Robbana - LIP2, University of Carthage, Tunisia Publicity Chairs * Anis Koubaa - Al Imam Mohamed Bin Saud Islamic University, KSA / =20 CISTER Research Unit, Portugal * Amine Dhraief - HANA Research Group, University of Manouba, Tunisia * Rafaa Tahar - HANA Research Group, University of Manouba, Tunisia Technical Program Committee * Abdelfettah Belghith - University of Manouba, Tunisia * Abdelhakim Hafid - University of Montreal, Canada * Abderrahim BenSlimane - University of Avignon, France * Adel Ben Mnaouer - University of Trinidad and Tobago, Trinidad and Tobago * Andreas J. Kassler - Karlstad University, Sweden * Anis Koubaa - Al Imam Mohamed Bin Saud Islamic University, KSA / =20 CISTER Research Unit, Portugal * Aref Meddeb - University of Sousse, Tunisia * Bernard Cousin - IRISA, University of Rennes 1, France * Debashis Saha - IIM, Calcutta, India * Farid Nait Abdessalem - University of Lille, France * Foh Chuan Heng - Nanyang Technological University, Singapore * Guy Pujolle - Pierre and Marie Curie University, France * Habib Youssef - University of Sousse, Tunisia * Hamdi Yahyaoui - Kuwait University, Kuwait * Hossam Hassanein - Queens University, Canada * Jian-Nong Cao - Hong Kong Polytechnic University, Hong Kong * Khaled Ben Letaief - Hong Kong University of Science and Technology, =20 Hong Kong * Khalil Drira - University of Toulouse, France * Kin Choong Yow - Nanyang Technological University, Singapore * Lotfi Kamoun - University of Sfax, Tunisia * Mario Gerla - University of California at Los Angeles, USA * Mieso Denko - University of Guelph, Ontario, Canada * Mohamed Abid - University of Sfax, Tunisia * Mohamed Mosbah - University of Bordeaux 1, France * Mohamed Younis - University of Maryland, USA * Mohsen Guizani - Kuwait University, Kuwait * Mounir Hamdi - Hong Kong University of Science and Technology, Hong Kong * Mourad Loulou - University of Sfax, Tunisia * Nafaa Jabeur - Dhofar University, Oman * Noureddine Boudrigua - SupCom, Tunisia * Raouf Boutaba - University of Waterloo, Canada * Riadh Robbana - University of Carthage, Tunisia * Samuel Pierre - Polytechnique Montreal, Canada * Shafique Ahmad Chaudry - Al Imam Mohamed Bin Saud Islamic University, KSA * Slim Abdellatif - LAAS-CNRS, University of Toulouse, France * Tarik Taleb - Tohoku University, Japan * Zakaria Maamar - Zayed University, UAE --=20 Amine Dhraief HANA Research Group, CRISTAL Laboratory http://www.hana-uma.org ENSI, University of Manouba, Tunisia 2010 From Chris.Dearlove@baesystems.com Wed Nov 18 01:47:50 2009 Return-Path: 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 9265428C0D6 for ; Wed, 18 Nov 2009 01:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.666 X-Spam-Level: X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599] 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 9TWKK8rHVUTP for ; Wed, 18 Nov 2009 01:47:49 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 9D55C3A6A82 for ; Wed, 18 Nov 2009 01:47:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,764,1249254000"; d="scan'208";a="33577291" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 18 Nov 2009 09:47:35 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAI9lg9u032338; Wed, 18 Nov 2009 09:47:43 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 09:47:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 18 Nov 2009 09:47:32 -0000 Message-ID: In-Reply-To: <200911172054.50817.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Links, wireless properties and autoconf scope Thread-Index: Acpnv9lRwqyiROxASkegdBY36T581AAc/EGQ References: <1258455361.4335.39.camel@acorde.it.uc3m.es><200911172040.47026.hrogge@googlemail.com><1258487249.30701.45.camel@acorde.it.uc3m.es> <200911172054.50817.hrogge@googlemail.com> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 18 Nov 2009 09:47:34.0831 (UTC) FILETIME=[27C54BF0:01CA6834] Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 09:47:50 -0000 > The modification we would need would have to go into DAD (to check if we good > a collision). Instead of directly listening to other DAD checkers using our > interface IP, we would have to programm a DAD which detects if TWO of it's > neighbors are using the same IP and send some kind of "please change this IP" > message as a broadcast. This should be enough to get the ABC-Problem under > controll. That's not sufficient. What happens if two nodes three or more hops away pick the same address? That's still a problem that needs solving if you are going to e.g. route with DYMO or OLSRv2. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Wed Nov 18 01:55:00 2009 Return-Path: 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 A8E4E3A6A8F for ; Wed, 18 Nov 2009 01:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 e1YlwDKf0Yg5 for ; Wed, 18 Nov 2009 01:54:59 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id A831B3A68DE for ; Wed, 18 Nov 2009 01:54:59 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAhFV-0005jA-4O; Wed, 18 Nov 2009 10:54:53 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAhFU-0001bu-Kz; Wed, 18 Nov 2009 10:54:52 +0100 From: Henning Rogge To: autoconf@ietf.org Date: Wed, 18 Nov 2009 10:54:36 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <200911172054.50817.hrogge@googlemail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8621859.vPbHi20qWX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911181054.41701.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10038/Wed Nov 18 06:41:45 2009) by mailguard.fgan.de X-Scan-Signature: fe63cde163a9813fbfae5d53d3252e1e Cc: "Dearlove, Christopher \(UK\)" Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 09:55:00 -0000 --nextPart8621859.vPbHi20qWX Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed November 18 2009 10:47:32 Dearlove, Christopher (UK) wrote: > > The modification we would need would have to go into DAD (to check if > > we good > > a collision). Instead of directly listening to other DAD checkers > > using our > > interface IP, we would have to programm a DAD which detects if TWO of > > it's > > neighbors are using the same IP and send some kind of "please change > this IP" > > message as a broadcast. This should be enough to get the ABC-Problem > > under controll. >=20 > That's not sufficient. What happens if two nodes three or more hops away > pick the same address? That's still a problem that needs solving if you > are going to e.g. route with DYMO or OLSRv2. I was talking only about linklocal IPs. If you choose the same LL-IP three= =20 hops away OLSR or DYMO should not care (as long as they support unroutable= =20 addresses). Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart8621859.vPbHi20qWX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksDxFwACgkQRIfGfFXsz+AVoQCdGIHrSVgVgIqrtD8Bivsvt565 8CcAn2qqzzx0FpvoknRmQx79dmfH+fRo =wBjr -----END PGP SIGNATURE----- --nextPart8621859.vPbHi20qWX-- From alexandru.petrescu@gmail.com Wed Nov 18 05:20:08 2009 Return-Path: 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 6F8C43A693C for ; Wed, 18 Nov 2009 05:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.015, 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 2IGgkx-vOBNF for ; Wed, 18 Nov 2009 05:20:07 -0800 (PST) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 57BBD3A6905 for ; Wed, 18 Nov 2009 05:20:06 -0800 (PST) Received: from nephilia.intra.cea.fr (nephilia.intra.cea.fr [132.166.88.33]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id nAIDK02f006022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Nov 2009 14:20:01 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAIDK0Q6027856; Wed, 18 Nov 2009 14:20:00 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAIDK0YA010884; Wed, 18 Nov 2009 14:20:00 +0100 Message-ID: <4B03F47F.6070003@gmail.com> Date: Wed, 18 Nov 2009 14:19:59 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Thomas Heide Clausen References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> <4B030F86.1060604@gmail.com> <4B031448.7090701@earthlink.net> <4B0323C7.3060902@gmail.com> <1FF68FFE-66A2-4C9A-9A6A-7D3AB41DFED5@thomasclausen.org> In-Reply-To: <1FF68FFE-66A2-4C9A-9A6A-7D3AB41DFED5@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 13:20:08 -0000 [Thomas - please make your mails such I see them with fixed-length font (like Courrier), not variable-length fonts (like Times Roman). Displaying variable-length font emails breaks my view. I believe this may come from your use of quoted-printable MIME encoding instead of base64 MIME encoding. HEre we talk English, 7bit ASCII is sufficient, no need to encode it with MIME. If you really want to encode it with MIME then use base64 encoding (instead of quoted-printable) or 8bit encoding, it covers a much wider range of characters. If you need both English and French on the same MUA, you could still make your readers see fixed-font length by not using MIME but 8bit transport - most MTAs and MUAs are 8bit capable since some time now. For example, RFC2045: > For this reason, at least two encoding mechanisms are > necessary: a more or less readable encoding (quoted-printable) and a > "dense" or "uniform" encoding (base64). That "more or less"... means I see "=20" instead of a CR. I ... err... don't like it at all.] Back to our subject. Thomas Heide Clausen a écrit : > > On Nov 17, 2009, at 11:29 PM, Alexandru Petrescu wrote: > >> Charles E. Perkins a écrit : > > > >>> >> >>>> Hmmm... tell me about one such 1000node network running IP on each >>>> node and 1-interface routers exclusively, and /128 >>>> prefixes-per-interfaces... never seen one. >>> See above. >>>> If it ran by your AUTOCONF rules then each node would have a >>>> host-based route for every other node (i.e. 1000 entries in each >>>> node memory), or, sensor nodes are so restricted in memory that >>>> their stack takes much of the place. >>> No, each node only requires host routes for destinations required by >>> its applications. >> >> Cross-layer violation? >> >> How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY) >> from AUTOCONF? >> > > Fortunately, MANETs are just like the rest of the Internet, also in that > regard. Well, not true. Most applications are not aware about there being a route or not. The apps I currently use are not blocked more than 1-2s at worst until a path is found. And that is Internet scale. Generally speaking, the apps on end nodes are generally blocked mainly by the ND use for the default route. HEre - you don't even talk default routes, and not talking ND either. You don't even ack the fact that pure ND should happen with whatever addresses AUTOCONF generates. You are ready to modify ND, or to even replace it with something else. SO I really think we have different view on this aspect too. >> Let me say I refuse completely to agree on this cross-layer violation: > > Fortunately, there is none. It _is_ a cross-layer violations for apps to depend on the existence on routes. >> applications dictate which route should be present or not. Applications >> use sockets to send/rcv data that's all. I don't want to fiddle beneath >> them. I did enough fiddling with below apps Mobile IP to know what I'm >> talking about. > > Fortunately, no fiddling is needed. Hmmm... how does my firefox browser running on a MANET host know a route exist or not to a destination? >>>> That's why I believe your 1000node claims exagerated. >>> You must be trying to convince me that proactive link-state protocols >>> have larger memory requirements. >> >> You may like me to, but no. Not my intention was that. >> >> I simply don't agree with the app-dictates-routes. > > Fortunately, they don't no more than they do in the Internet. Well again, my apps on my laptop has little idea about the presence of routes in its routing table or in the Internet. All the kernel does is use a default route and ND for that. You don't ack any of the two Ronald questioned at the last meeting about this use of ND, and you manage to respond something but it showed non-interest from your part. >> There will always exist apps unaware of the supposed routing fiddling. >> The only interface they assume is their Socket, which is very good. >> That Socket doens't know MANET. >> >> BEsides, I don't want my app blocked until some routing protocol >> finds its paths through a 1000node unstructured maze. > > Fortunately, this is not the case. Which part of that is not the case? >> These are enough basic things for me to be in full disagreement with the >> MANETs as presented. > > It would appear, that the things you imagine above do not hold for MANETs. No, it appears we just exchanged a yes-no pair of messages on which I struggle to explain things and to which you say 'no'. That is not explanation. That is not consensus. That is a Chair imposing stuff. Alex > >> The only way to get past that is to decouple MANET from AUTOCONF. > > No, not at all. > > Thomas > >> >> Alex >> >> >>>>> [cf: >>>>>> No no, I am deaf :-) >>>>> ]. >>>> YEs, and I stay deaf to these statements that don't follow. >>> Whenever I am having a technical discussion, I try to understand how >>> the arguments which are presented can be interpreted so that they >>> make sense. >>>>> And yet you want to occupy the attention and restrict the >>>>> solution space available to practitioners who seem to have far >>>>> more experience than you, regardless of your ability to respond >>>>> to paper review requests. >>>> Hmm... at some point I get bored... >>> I'm long past bored. >>> Regards, Charlie P. >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > From alexandru.petrescu@gmail.com Wed Nov 18 05:23:39 2009 Return-Path: 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 1FE193A6905 for ; Wed, 18 Nov 2009 05:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.264 X-Spam-Level: X-Spam-Status: No, score=-3.264 tagged_above=-999 required=5 tests=[AWL=0.985, BAYES_00=-2.599, GB_I_INVITATION=-2, 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 yNsgQJXbkpVI for ; Wed, 18 Nov 2009 05:23:37 -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 669AD3A6809 for ; Wed, 18 Nov 2009 05:23:37 -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-2.0) with ESMTP id nAIDNVqD010187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 18 Nov 2009 14:23:31 +0100 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by nephilia.intra.cea.fr (8.14.2/8.14.2) with ESMTP id nAIDNVMG029222; Wed, 18 Nov 2009 14:23:31 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id nAIDNVaS012353; Wed, 18 Nov 2009 14:23:31 +0100 Message-ID: <4B03F552.80001@gmail.com> Date: Wed, 18 Nov 2009 14:23:30 +0100 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ricardo Schmidt References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> <4B030F86.1060604@gmail.com> <4B031448.7090701@earthlink.net> <4B0323C7.3060902@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 13:23:39 -0000 Ricardo Schmidt a écrit : > Here we have a good example: http://www.cs.wayne.edu/~hzhang/ > 1,400-node mesh network at Wayne State University. Please digest that page info for me. Is it 1400 nodes? Or area of 1400m times something? (the slides say so) Is each node running IP? IPv6? Is each node having a single interface? That is what I am looking for. Alex > > > > On Tue, Nov 17, 2009 at 7:29 PM, Alexandru Petrescu > wrote: >> Charles E. Perkins a écrit : >>> Hello Alex, >>> >>> Alexandru Petrescu wrote: >>>> Charles E. Perkins a écrit : >>>>> Second, there are examples of 1000 node networks where each node >>>>> is minimal. >>>> Charles - there's no network of 1000 sensors I am aware of that >>>> runs IP and that uses exclusively 1-interface routers and /128 >>>> prefixes per their interfaces. >>> Ohio State University. >> It's a big University, what of if more exactly? >> >> Is this claim similar to the recent claim that said large networks in >> Vienna, and yet there are two-interface routers? >> >>> Rutgers University/GENI >> I do follow GENI and what I see is invitations to conferences - should I >> accept these invitations? And I don't see networks of 1000s IP >> 1-interface sensors. >> >>> Others may give you other citations. >>> >>>>> Third, a single human could easily deploy a 1000 node sensor network. >>>> Tell about an example. >>> Dropping motion sensors from an airplane. >> Again - I agree with you in the sense they represent great goals, ideal >> in a sense. >> >> However, I don't see it happening as you describe it, i.e. IP on each >> sensor dropped from planes. >> >> And I did see sensor networks. >> >>>> >>>>> >>>>> You insist on necessitating a central role for a "link", in >>>> YEs - link is of paramount importance. >>>> >>>> You also need a communication medium but you simply don't want >>>> 4861-links, that's all. >>> Not "simply". Not "that's all". Not just me. >>> >>>> >>>> You avoid defining them and always claim you and only you >>>> understand its non-understandable behaviours. >>> This is a totally false and unwarranted accusation. >> Politeness here ok - no accusation. >> >>>> You sometimes use it to explain some protocol design choices, but I >>>> can't understand these choices because I simply don't understand >>>> what you mean by non-deterministic links and time/space variation >>>> of stuff. >>> Those words have well-defined meanings. I personally do not use the >>> terminology "non-deterministic". Maybe you are confusing me with >>> someone else. >> You continue saying these ABC-links are different than existing links, >> with a timespace vocabulary proper to only the pure PHY-inclined. Not >> that they're not right, but they simply don't use IP - they use OFDMA >> MIMO and such. >> >>>> Hmmm... tell me about one such 1000node network running IP on each >>>> node and 1-interface routers exclusively, and /128 >>>> prefixes-per-interfaces... never seen one. >>> See above. >>> >>>> >>>> If it ran by your AUTOCONF rules then each node would have a host-based >>>> route for every other node (i.e. 1000 entries in each >>>> node memory), or, sensor nodes are so restricted in memory that >>>> their stack takes much of the place. >>> No, each node only requires host routes for destinations required by >>> its applications. >> Cross-layer violation? >> >> How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY) >> from AUTOCONF? >> >> Let me say I refuse completely to agree on this cross-layer violation: >> applications dictate which route should be present or not. Applications >> use sockets to send/rcv data that's all. I don't want to fiddle beneath >> them. I did enough fiddling with below apps Mobile IP to know what I'm >> talking about. >> >>>> That's why I believe your 1000node claims exagerated. >>> You must be trying to convince me that proactive link-state protocols >>> have larger memory requirements. >> You may like me to, but no. Not my intention was that. >> >> I simply don't agree with the app-dictates-routes. >> >> There will always exist apps unaware of the supposed routing fiddling. >> The only interface they assume is their Socket, which is very good. >> That Socket doens't know MANET. >> >> BEsides, I don't want my app blocked until some routing protocol >> finds its paths through a 1000node unstructured maze. >> >> These are enough basic things for me to be in full disagreement with the >> MANETs as presented. >> >> The only way to get past that is to decouple MANET from AUTOCONF. >> >> Alex >> >> >>>>> [cf: >>>>>> No no, I am deaf :-) >>>>> ]. >>>> YEs, and I stay deaf to these statements that don't follow. >>> Whenever I am having a technical discussion, I try to understand how >>> the arguments which are presented can be interpreted so that they >>> make sense. >>> >>> >>>>> And yet you want to occupy the attention and restrict the >>>>> solution space available to practitioners who seem to have far >>>>> more experience than you, regardless of your ability to respond >>>>> to paper review requests. >>>> Hmm... at some point I get bored... >>> I'm long past bored. >>> >>> Regards, Charlie P. >>> >>> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf > From Chris.Dearlove@baesystems.com Wed Nov 18 06:03:14 2009 Return-Path: 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 9809D3A6AA8 for ; Wed, 18 Nov 2009 06:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.662 X-Spam-Level: X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599] 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 kKSFfit053D1 for ; Wed, 18 Nov 2009 06:03:13 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id 8C23F3A6A9E for ; Wed, 18 Nov 2009 06:03:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,765,1249254000"; d="scan'208";a="33661237" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 18 Nov 2009 14:03:11 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAIE3J5l027591; Wed, 18 Nov 2009 14:03:19 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Wed, 18 Nov 2009 14:03:11 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 18 Nov 2009 14:03:10 -0000 Message-ID: In-Reply-To: <200911181054.41701.henning.rogge@fkie.fraunhofer.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Links, wireless properties and autoconf scope Thread-Index: AcpoNTGVDA+ZHtfzTL+wF2OjpHqQHAAHZUqQ References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <200911172054.50817.hrogge@googlemail.com> <200911181054.41701.henning.rogge@fkie.fraunhofer.de> From: "Dearlove, Christopher (UK)" To: "Henning Rogge" , X-OriginalArrivalTime: 18 Nov 2009 14:03:11.0070 (UTC) FILETIME=[DCE1A7E0:01CA6857] Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 14:03:14 -0000 >> That's not sufficient. What happens if two nodes three or more hops away >> pick the same address? That's still a problem that needs solving if you >> are going to e.g. route with DYMO or OLSRv2. > I was talking only about linklocal IPs. If autoconf is to be useful, we need it to create addresses with MANET wide scope (at least) and uniqueness in that scope. That needs something more than a two hop approach. Maybe you can get a two hop approach to work and create LL addresses with that (dynamically changing) scope. And if that's useful to you, fine. But to route across a MANET with autoconfigured addresses needs more than that. And that's what the WG needs to create if it's to be useful. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From henning.rogge@fkie.fraunhofer.de Wed Nov 18 06:16:39 2009 Return-Path: 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 4A2293A6B6C for ; Wed, 18 Nov 2009 06:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.162 X-Spam-Level: X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] 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 zKvCEFPBiz1g for ; Wed, 18 Nov 2009 06:16:36 -0800 (PST) Received: from mailguard.fgan.de (mailguard.fgan.de [128.7.3.5]) by core3.amsl.com (Postfix) with ESMTP id 4F3F63A6957 for ; Wed, 18 Nov 2009 06:16:36 -0800 (PST) Received: from rufsun5.fkie.fgan.de ([128.7.2.5] helo=mailhost.fgan.de) by mailguard.fgan.de with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAlKi-00068q-Ah; Wed, 18 Nov 2009 15:16:32 +0100 Received: from stream.fkie.fgan.de ([128.7.5.148] helo=stream.localnet) by mailhost.fgan.de with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1NAlKi-0003Ex-1L; Wed, 18 Nov 2009 15:16:32 +0100 From: Henning Rogge To: "Dearlove, Christopher (UK)" Date: Wed, 18 Nov 2009 15:16:21 +0100 User-Agent: KMail/1.12.2 (Linux/2.6.31-15-generic; KDE/4.3.2; i686; ; ) References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <200911181054.41701.henning.rogge@fkie.fraunhofer.de> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4823799.te9th3X8P0"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200911181516.26605.henning.rogge@fkie.fraunhofer.de> X-Virus-Scanned: yes (ClamAV 0.95.2/10040/Wed Nov 18 12:36:37 2009) by mailguard.fgan.de X-Scan-Signature: 03aa31d695fb3eb984fab57667d62e5a Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 14:16:39 -0000 --nextPart4823799.te9th3X8P0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Wed November 18 2009 15:03:10 Dearlove, Christopher (UK) wrote: > If autoconf is to be useful, we need it to create addresses with > MANET wide scope (at least) and uniqueness in that scope. That needs > something more than a two hop approach. Maybe you can get a two hop > approach to work and create LL addresses with that (dynamically > changing) scope. And if that's useful to you, fine. But to route > across a MANET with autoconfigured addresses needs more than that. > And that's what the WG needs to create if it's to be useful. I completely agree with you, creation of manet-unique IPs is the more=20 important part of this WG. But I think we will be able to get the LL-Proble= m=20 done too with a little bit creative work. Henning Rogge =2D-=20 Diplom-Informatiker Henning Rogge , Fraunhofer-Institut f=FCr Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Neuenahrer Stra=DFe 20, 53343 Wachtberg, Germany Telefon +49 228 9435-263, Fax +49 228 9435 685 mailto:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0 --nextPart4823799.te9th3X8P0 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAksEAbUACgkQRIfGfFXsz+BovACcDoTwnFPoiAuNGwJKkb5auExk 0CUAoJ1sbwvkmB5AMi4q/a7u42yALwgd =d5cC -----END PGP SIGNATURE----- --nextPart4823799.te9th3X8P0-- From thomas@thomasclausen.org Wed Nov 18 08:04:04 2009 Return-Path: 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 33FF928C0FA for ; Wed, 18 Nov 2009 08:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 8RisN8wszUob for ; Wed, 18 Nov 2009 08:04:02 -0800 (PST) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id ADA2928C0F7 for ; Wed, 18 Nov 2009 08:04:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 3D2764302D6; Wed, 18 Nov 2009 08:04:01 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [192.168.147.148] (AMontsouris-552-1-90-209.w92-140.abo.wanadoo.fr [92.140.105.209]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id BAD0443029F; Wed, 18 Nov 2009 08:03:59 -0800 (PST) Message-Id: From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4B03F47F.6070003@gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-17--1067320146 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Nov 2009 17:03:57 +0100 References: <1258455361.4335.39.camel@acorde.it.uc3m.es> <4B02E52E.3060809@earthlink.net> <4B02EB80.3050505@gmail.com> <4B02EF2C.6020403@earthlink.net> <4B030F86.1060604@gmail.com> <4B031448.7090701@earthlink.net> <4B0323C7.3060902@gmail.com> <1FF68FFE-66A2-4C9A-9A6A-7D3AB41DFED5@thomasclausen.org> <4B03F47F.6070003@gmail.com> X-Mailer: Apple Mail (2.936) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Links, wireless properties and autoconf scope X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 16:04:04 -0000 --Apple-Mail-17--1067320146 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Nov 18, 2009, at 2:19 PM, Alexandru Petrescu wrote: > > Thomas Heide Clausen a =E9crit : >> On Nov 17, 2009, at 11:29 PM, Alexandru Petrescu wrote: >>> Charles E. Perkins a =E9crit : >> >>>> >>> >>>>> Hmmm... tell me about one such 1000node network running IP on each >>>>> node and 1-interface routers exclusively, and /128 prefixes-per-=20= >>>>> interfaces... never seen one. >>>> See above. >>>>> If it ran by your AUTOCONF rules then each node would have a =20 >>>>> host-based route for every other node (i.e. 1000 entries in each >>>>> node memory), or, sensor nodes are so restricted in memory that >>>>> their stack takes much of the place. >>>> No, each node only requires host routes for destinations required =20= >>>> by >>>> its applications. >>> >>> Cross-layer violation? >>> >>> How about decoupling both the layer-7 (apps) _and_ the layer-0 (PHY) >>> from AUTOCONF? >>> >> Fortunately, MANETs are just like the rest of the Internet, also in =20= >> that regard. > > Well, not true. Most applications are not aware about there being a =20= > route or not. The apps I currently use are not blocked more than =20 > 1-2s at worst until a path is found. And that is Internet scale. As MANETs are *exactly* like the other parts of the Internet in this =20 respect, you either disagree with the Internet or agree with MANETs =20 here. > Generally speaking, the apps on end nodes are generally blocked =20 > mainly by the ND use for the default route. HEre - you don't even =20 > talk default routes, and not talking ND either. > > You don't even ack the fact that pure ND should happen with whatever =20= > addresses AUTOCONF generates. You are ready to modify ND, or to =20 > even replace it with something else. > > SO I really think we have different view on this aspect too. > >>> Let me say I refuse completely to agree on this cross-layer =20 >>> violation: >> Fortunately, there is none. > > It _is_ a cross-layer violations for apps to depend on the existence =20= > on routes. Fortunately, they do not depend on this in a MANET either. A MANET is =20= just like the Internet in this regard. >>> applications dictate which route should be present or not. =20 >>> Applications >>> use sockets to send/rcv data that's all. I don't want to fiddle =20 >>> beneath >>> them. I did enough fiddling with below apps Mobile IP to know =20 >>> what I'm >>> talking about. >> Fortunately, no fiddling is needed. > > Hmmm... how does my firefox browser running on a MANET host know a =20 > route exist or not to a destination? It doesn't. I am *this second* writing this email using a stock Apple-=20= issue laptop with nothing but std. applications. My Firefox, Safari, =20= Mail et. al. do not know that they are connected across a MANET =20 routing domain, any more than they would know if they were connected =20 over an OSPF domain..... So, no fiddling is needed. >>>>> That's why I believe your 1000node claims exagerated. >>>> You must be trying to convince me that proactive link-state =20 >>>> protocols >>>> have larger memory requirements. >>> >>> You may like me to, but no. Not my intention was that. >>> >>> I simply don't agree with the app-dictates-routes. >> Fortunately, they don't no more than they do in the Internet. > > Well again, my apps on my laptop has little idea about the presence =20= > of routes in its routing table or in the Internet. > All the kernel does is use a default route and ND for that. You =20 > don't ack any of the two I am connected to the Internet via a MANET right now. You don't ack =20 that that works just fine. > Ronald questioned at the last meeting about this use of ND, and you =20= > manage to respond something but it showed non-interest from your part. Ronald has a point, which is very relevant when we go to the next =20 phase: designing solutions. > >>> There will always exist apps unaware of the supposed routing =20 >>> fiddling. >>> The only interface they assume is their Socket, which is very good. >>> That Socket doens't know MANET. >>> >>> BEsides, I don't want my app blocked until some routing protocol >>> finds its paths through a 1000node unstructured maze. >> Fortunately, this is not the case. > > Which part of that is not the case? All parts. > >>> These are enough basic things for me to be in full disagreement =20 >>> with the >>> MANETs as presented. >> It would appear, that the things you imagine above do not hold for =20= >> MANETs. > > No, it appears we just exchanged a yes-no pair of messages on which =20= > I struggle to explain things and to which you say 'no'. > > That is not explanation. > > That is not consensus. > > That is a Chair imposing stuff. Many people have tried to explain matters, but it seems that these =20 explanations fall on deaf ears. It is hard not to get more than a =20 little frustrated. Thomas > Alex > >>> The only way to get past that is to decouple MANET from AUTOCONF. >> No, not at all. >> Thomas >>> >>> Alex >>> >>> >>>>>> [cf: >>>>>>> No no, I am deaf :-) >>>>>> ]. >>>>> YEs, and I stay deaf to these statements that don't follow. >>>> Whenever I am having a technical discussion, I try to understand =20= >>>> how >>>> the arguments which are presented can be interpreted so that they >>>> make sense. >>>>>> And yet you want to occupy the attention and restrict the >>>>>> solution space available to practitioners who seem to have far >>>>>> more experience than you, regardless of your ability to respond >>>>>> to paper review requests. >>>>> Hmm... at some point I get bored... >>>> I'm long past bored. >>>> Regards, Charlie P. >>> >>> _______________________________________________ >>> Autoconf mailing list >>> Autoconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/autoconf > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf --Apple-Mail-17--1067320146 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Nov 18, 2009, = at 2:19 PM, Alexandru Petrescu wrote:
<SNIP>


Thomas Heide Clausen a =E9crit :
On Nov 17, 2009, at 11:29 PM, Alexandru Petrescu = wrote:
Charles E. Perkins a =E9crit = :
<SNIP>


Hmmm... tell me about one such = 1000node network running IP on = each
node and 1-interface routers = exclusively, and /128 prefixes-per-interfaces... never seen = one.
See = above.
If it ran by your AUTOCONF rules = then each node would have a host-based route for every other node (i.e. = 1000 entries in = each
node memory), or, sensor nodes = are so restricted in memory = that
their stack takes much of the = place.
No, = each node only requires host routes for destinations required = by
its = applications.

Cross-layer = violation?

How about decoupling both the = layer-7 (apps) _and_ the layer-0 = (PHY)
from AUTOCONF?

Fortunately, MANETs are just like the rest of the = Internet, also in that regard.

Well, not true. =  Most applications are not aware about there being a route or not. =  The apps I currently use are not blocked more than 1-2s at worst = until a path is found.  And that is Internet = scale.

As MANETs are *exactly* like = the other parts of the Internet in this respect, you either disagree = with the Internet or agree with MANETs here.

Generally speaking, the apps on end nodes are = generally blocked mainly by the ND use for the default route.  HEre = - you don't even talk default routes, and not talking ND = either.

You don't even ack the fact that pure ND should happen = with whatever addresses AUTOCONF generates.  You are ready to = modify ND, or to even replace it with something else.

SO I really = think we have different view on this aspect = too.

Let me say I refuse completely to agree on this = cross-layer violation:
Fortunately, there is none.

It _is_ a = cross-layer violations for apps to depend on the existence on = routes.

Fortunately, they do not = depend on this in a MANET either. A MANET is just like the Internet in = this regard.

applications dictate which route should be present or not. =  Applications
use sockets to send/rcv data = that's all.  I don't want to fiddle = beneath
them.  I did enough fiddling with below apps Mobile = IP to know what I'm
talking = about.
Fortunately,= no fiddling is needed.

Hmmm... how does my firefox = browser running on a MANET host know a route exist or not to a = destination?

It doesn't. I am *this = second* writing this email using a stock Apple-issue laptop with nothing = but std. applications.  My Firefox, Safari, Mail et. al. do not = know that they are connected across a MANET routing domain, any more = than they would know if they were connected over an OSPF = domain.....

So, no fiddling is = needed. 

That's why I believe your = 1000node claims = exagerated.
You= must be trying to convince me that proactive link-state = protocols
have = larger memory = requirements.

You may like me to, but no. =  Not my intention was = that.

I simply don't agree with the = app-dictates-routes.
Fortunately, they don't no more than they do in the = Internet.

Well again, my apps on my laptop has = little idea about the presence of routes in its routing table or in the = Internet.
 All = the kernel does is use a default route and ND for that.  You don't = ack any of the two

I am connected = to the Internet via a MANET right now. You don't ack that that works = just fine.

Ronald = questioned at the last meeting about this use of ND, and you manage to = respond something but it showed non-interest from your = part.

Ronald has a point, which is = very relevant when we go to the next phase: designing = solutions. 


There will always exist apps unaware of the supposed = routing fiddling.
The only interface they assume = is their Socket, which is very = good.
That Socket doens't know = MANET.

BEsides, I don't want my app = blocked until some routing = protocol
finds its paths through a = 1000node unstructured maze.
Fortunately, this is not the = case.

Which part of that is not the = case?

All = parts.


These are enough basic things = for me to be in full disagreement with = the
MANETs as = presented.
It = would appear, that the things you imagine above do not hold for = MANETs.

No, it appears we just exchanged a yes-no = pair of messages on which I struggle to explain things and to which you = say 'no'.

That is not explanation.

That is not consensus.

That is a Chair = imposing stuff.

Many people = have tried to explain matters, but it seems that these explanations fall = on deaf ears. It is hard not to get more than a little = frustrated.

Thomas

Alex

The only way to get past that is to decouple MANET from = AUTOCONF.
No, not = at all.
Thomas

Alex


[cf:
=
No no, = I am deaf = :-)
].
YEs, and I stay deaf to these = statements that don't = follow.
Whenever I am having a technical discussion, I try to = understand how
the = arguments which are presented can be interpreted so that = they
make = sense.
And = yet you want to occupy the attention and restrict = the
solution= space available to practitioners who seem to have = far
more = experience than you, regardless of your ability to = respond
to = paper review = requests.
Hmm... at some point I get = bored...
I'm = long past bored.
Regards,= Charlie P.

_______________________________________________
Autoconf mailing = list
Autoconf@ietf.org <mailto:Autoconf@ietf.org>
https://www.ietf.o= rg/mailman/listinfo/autoconf


____= ___________________________________________
Autoconf mailing = list
Autoconf@ietf.org
https://www.iet= f.org/mailman/listinfo/autoconf

= --Apple-Mail-17--1067320146-- From ulrich@herberg.name Wed Nov 18 13:38:28 2009 Return-Path: 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 CBC2E3A69EF for ; Wed, 18 Nov 2009 13:38:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 tQ8m3zLHSOnX for ; Wed, 18 Nov 2009 13:38:28 -0800 (PST) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id BFBEB3A69EB for ; Wed, 18 Nov 2009 13:38:27 -0800 (PST) Received: by bwz23 with SMTP id 23so1740944bwz.29 for ; Wed, 18 Nov 2009 13:38:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.34.194 with SMTP id m2mr5500573bkd.53.1258580302764; Wed, 18 Nov 2009 13:38:22 -0800 (PST) In-Reply-To: <4B032CDD.9090803@wichorus.com> References: <4B032CDD.9090803@wichorus.com> Date: Wed, 18 Nov 2009 22:38:22 +0100 Message-ID: <25c114b90911181338m6139dc5bx6a54392d0539a856@mail.gmail.com> From: Ulrich Herberg To: "Charles E. Perkins" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] [Fwd: New Version Notification for draft-baccelli-multi-hop-wireless-communication-03] X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 21:38:28 -0000 Hi Charlie, thanks for submitting the document again. I think it is very useful. Are there any differences to the -02 version? Or is it the same version resubmitted? Ulrich On Wed, Nov 18, 2009 at 12:08 AM, Charles E. Perkins wrote: > > Hello folks, > > I've submitted a new revision for the Independent Submission: > =A0 "Multi-hop Ad Hoc Wireless Communication". > > It is available at the following URL: > > http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-com= munication-03.txt > > Regards, > Charlie P. > > > -------- Original Message -------- > Subject: =A0 =A0 =A0 =A0New Version Notification for > draft-baccelli-multi-hop-wireless-communication-03 > Date: =A0 Tue, 17 Nov 2009 18:03:02 -0500 > From: =A0 IETF I-D Submission Tool > To: =A0 =A0 Charles E. Perkins > CC: =A0 =A0 Emmanuel.Baccelli@inria.fr > > > > A new version of I-D, draft-baccelli-multi-hop-wireless-communication-03.= txt > has been successfuly submitted by Charles Perkins and posted to the IETF > repository. > > Filename: =A0 =A0 =A0 =A0draft-baccelli-multi-hop-wireless-communication > Revision: =A0 =A0 =A0 =A003 > Title: =A0 =A0 =A0 =A0 =A0 Multi-hop Ad Hoc Wireless Communication > Creation_date: =A0 2009-11-17 > WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission > Number_of_pages: 9 > > Abstract: > This document describes some important characteristics of > communication between nodes in a multi-hop ad hoc wireless network. > These are not requirements in the sense usually understood as > applying to formulation of a requirements document. =A0Nevertheless, > protocol engineers and system analysts involved with designing > solutions for ad hoc networks must maintain awareness of these > characteristics. > > Status of This Memo > > This Internet-Draft is submitted to IETF in full conformance with the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. =A0Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. =A0It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > This Internet-Draft will expire on May 21, 2010.Copyright Notice > > Copyright (c) 2009 IETF Trust and the persons identified as the > document authors. =A0All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. =A0Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. =A0Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > > The IETF Secretariat. > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www.ietf.org/mailman/listinfo/autoconf > From charles.perkins@earthlink.net Wed Nov 18 14:43:11 2009 Return-Path: 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 4F5DB3A68FF for ; Wed, 18 Nov 2009 14:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] 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 U3s0BJXLkP5c for ; Wed, 18 Nov 2009 14:43:10 -0800 (PST) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by core3.amsl.com (Postfix) with ESMTP id 465213A6810 for ; Wed, 18 Nov 2009 14:43:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=p3/YBaGkeDOmtEnrcGk5PB9zmVTUWsq1bTurS4DaWVcnCZFsAjudyIMZ4N/7N8Yq; h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-ELNK-Trace:X-Originating-IP; Received: from [12.204.153.98] (helo=[10.166.254.154]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1NAtEx-0005Ti-PW; Wed, 18 Nov 2009 17:43:08 -0500 Message-ID: <4B04787A.90200@earthlink.net> Date: Wed, 18 Nov 2009 14:43:06 -0800 From: "Charles E. Perkins" Organization: Wichorus Inc. User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Ulrich Herberg References: <4B032CDD.9090803@wichorus.com> <25c114b90911181338m6139dc5bx6a54392d0539a856@mail.gmail.com> In-Reply-To: <25c114b90911181338m6139dc5bx6a54392d0539a856@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956abb457f1b4332f527230c43a092b7566dab4226d754d2097350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 12.204.153.98 Cc: "autoconf@ietf.org" , Emmanuel Baccelli Subject: Re: [Autoconf] [Fwd: New Version Notification for draft-baccelli-multi-hop-wireless-communication-03] X-BeenThere: autoconf@ietf.org 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: Wed, 18 Nov 2009 22:43:11 -0000 Hello Ulrich, It is almost the same document. But I need to update the description for "exposed nodes". My presentation at the IETF was correct, but I forgot to go back and update the text in the draft. I hope to do that tomorrow. Regards, Charlie P. PS. sorry for the repeat messages -- I keep forgetting which email address works for the [autoconf] mailing list. Ulrich Herberg wrote: > Hi Charlie, > > thanks for submitting the document again. I think it is very useful. > Are there any differences to the -02 version? Or is it the same > version resubmitted? > > Ulrich > > On Wed, Nov 18, 2009 at 12:08 AM, Charles E. Perkins > wrote: > >> Hello folks, >> >> I've submitted a new revision for the Independent Submission: >> "Multi-hop Ad Hoc Wireless Communication". >> >> It is available at the following URL: >> >> http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-communication-03.txt >> >> Regards, >> Charlie P. >> >> >> -------- Original Message -------- >> Subject: New Version Notification for >> draft-baccelli-multi-hop-wireless-communication-03 >> Date: Tue, 17 Nov 2009 18:03:02 -0500 >> From: IETF I-D Submission Tool >> To: Charles E. Perkins >> CC: Emmanuel.Baccelli@inria.fr >> >> >> >> A new version of I-D, draft-baccelli-multi-hop-wireless-communication-03.txt >> has been successfuly submitted by Charles Perkins and posted to the IETF >> repository. >> >> Filename: draft-baccelli-multi-hop-wireless-communication >> Revision: 03 >> Title: Multi-hop Ad Hoc Wireless Communication >> Creation_date: 2009-11-17 >> WG ID: Independent Submission >> Number_of_pages: 9 >> >> Abstract: >> This document describes some important characteristics of >> communication between nodes in a multi-hop ad hoc wireless network. >> These are not requirements in the sense usually understood as >> applying to formulation of a requirements document. Nevertheless, >> protocol engineers and system analysts involved with designing >> solutions for ad hoc networks must maintain awareness of these >> characteristics. >> >> Status of This Memo >> >> This Internet-Draft is submitted to IETF in full conformance with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups. Note that >> other groups may also distribute working documents as Internet- >> Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six months >> and may be updated, replaced, or obsoleted by other documents at any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> This Internet-Draft will expire on May 21, 2010.Copyright Notice >> >> Copyright (c) 2009 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with respect >> to this document. Code Components extracted from this document must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the BSD License. >> >> >> >> The IETF Secretariat. >> >> >> >> _______________________________________________ >> Autoconf mailing list >> Autoconf@ietf.org >> https://www.ietf.org/mailman/listinfo/autoconf >> >> From zach@sensinode.com Thu Nov 19 02:18:22 2009 Return-Path: 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 E34383A6A89 for ; Thu, 19 Nov 2009 02:18:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 6vqe3PYNAhoF for ; Thu, 19 Nov 2009 02:18:21 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 150F33A6AAE for ; Thu, 19 Nov 2009 02:18:20 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nAJAID3Z011617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 19 Nov 2009 12:18:14 +0200 From: Zach Shelby Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 19 Nov 2009 12:18:21 +0200 Message-Id: <287B72D4-175D-4134-9425-30A048CCAA26@sensinode.com> To: autoconf@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Autoconf] Comments on adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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, 19 Nov 2009 10:18:23 -0000 Hi, Over in the 6lowpan WG we are defining a technique for optimizing the = host-router (node-router) interface, called 6lowpan-nd. Working on this = problem for a couple years, and starting with RFC4861 terminology, it = turns out that we came to a very similar conclusion to the autoconf WG. = However, in 6lowpan we are routing protocol agnostic and we deal with = hosts and routers. The link technologies we use in 6lowpan exhibit the characteristics = defined (very nicely!) in = draft-baccelli-multi-hop-wireless-communications-03. Although we don't = always have multi-hop, even then many of the same characteristics occur. The current version of ietf-6lowpan-nd-07 goes to all the trouble of = defining mostly the same things you have (with much more text...). In = Hiroshima we got a kick (thanks Dave!) to explore the use of = draft-ietf-autoconf-adhoc-addr-model to simplify our own document and to = unite the models across WGs.=20 Here are my comments/thoughts on the addr-model-00 document from the = 6lowpan perspective: 1. Make the document MANET agnostic. This can just as well be referenced = by ROLL and 6LoWPAN work e.g. I only find MANET referenced in the intro = (can be extended with other examples) and in the last paragraph of 6.2. = Both are easily fixed. 2. I like the "link of undetermined properties"... however you might = want to point to a document like = draft-baccelli-multi-hop-wireless-communications to point out why links = end up like that. RFC4861 also explains that a link might be = non-transitive, so that could also be referenced.=20 3. You have two open issues in Appendix A. To me both of these are OK = already. The link model is fine (see 2). If globally unique addresses = are needed, leave that to some other mechanism. This is what 6lowpan-nd = does for a 6lowpan network. 4. In 6lowpan we would use the "when more specific assumptions can be = made about connectivity" clause, as we always assign a single (global or = ULA) prefix across the whole 6lowpan network. So the "MAY be configured = with the same prefix" in Section 4 would be applied. In 6lowpan-nd we = are able to make an assumption about connectivity between node-router = pairs thanks to our mechanism defined. So please do keep this clause, it = is very useful ;-) 5. We consider link-local addresses in the same way, this is OK. 6. The second bullet point of Section 6.2 needs some expansion not to = be misunderstood. In addition to the existing sentence, also add text = like: ", unless an assumption can be made about connectivity in which = case the prefix may be /64." The point being that if you can assume = connectivity with a router (who somehow advertises a prefix), you may be = able to autoconfigure an address using a shared prefix. This is what we = do in 6lowpan. So in my opinion, with the very small changes above (1. and 6.), this = document would be very useful for our work.=20 Thanks, Zach=20 --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From Chris.Dearlove@baesystems.com Thu Nov 19 02:53:08 2009 Return-Path: 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 B0F7E3A68B4 for ; Thu, 19 Nov 2009 02:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599] 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 vkO4VKUJAqa7 for ; Thu, 19 Nov 2009 02:53:08 -0800 (PST) Received: from ukmta3.baesystems.com (ukmta3.baesystems.com [20.133.40.55]) by core3.amsl.com (Postfix) with ESMTP id C57D83A68B0 for ; Thu, 19 Nov 2009 02:53:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.44,770,1249254000"; d="scan'208";a="33843142" Received: from unknown (HELO baemasodc004.greenlnk.net) ([10.108.36.11]) by Baemasodc001ir.sharelnk.net with ESMTP; 19 Nov 2009 10:53:05 +0000 Received: from glkms1103.GREENLNK.NET (glkms1103.greenlnk.net [10.108.36.194]) by baemasodc004.greenlnk.net (Switch-3.4.1/Switch-3.4.1) with ESMTP id nAJArDQm028749; Thu, 19 Nov 2009 10:53:13 GMT Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1103.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Nov 2009 10:53:04 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 19 Nov 2009 10:53:04 -0000 Message-ID: In-Reply-To: <287B72D4-175D-4134-9425-30A048CCAA26@sensinode.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Comments on adhoc-addr-model-00 Thread-Index: AcppAaaNguDrlYcaQki9FnNCHKt/PQABDDcA References: <287B72D4-175D-4134-9425-30A048CCAA26@sensinode.com> From: "Dearlove, Christopher (UK)" To: "Zach Shelby" , X-OriginalArrivalTime: 19 Nov 2009 10:53:05.0094 (UTC) FILETIME=[78CD9660:01CA6906] Subject: Re: [Autoconf] Comments on adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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, 19 Nov 2009 10:53:08 -0000 > 1. Make the document MANET agnostic. MANET is an overloaded term. One meaning is "what's done in the MANET WG". The other is "what's done in an ad hoc network". (Why have I dropped "mobile"? - because really it's not mobility that matters, it's dynamism, and pretty much all ad hoc networks are dynamic, just the timescale varies.) In the latter sense - which is what I think matters - what's happening in ROLL and 6LoWPAN are specialised MANETs. The document may be agnostic on the former sense, but not, I suggest, on the latter sense. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** From ulrich@herberg.name Thu Nov 19 02:53:18 2009 Return-Path: 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 D2A013A69C4 for ; Thu, 19 Nov 2009 02:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 G1yPL2yNTKmb for ; Thu, 19 Nov 2009 02:53:18 -0800 (PST) Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by core3.amsl.com (Postfix) with ESMTP id B35E13A6924 for ; Thu, 19 Nov 2009 02:53:17 -0800 (PST) Received: by fxm7 with SMTP id 7so2275084fxm.29 for ; Thu, 19 Nov 2009 02:53:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.204.32.204 with SMTP id e12mr2116606bkd.51.1258627990665; Thu, 19 Nov 2009 02:53:10 -0800 (PST) In-Reply-To: <287B72D4-175D-4134-9425-30A048CCAA26@sensinode.com> References: <287B72D4-175D-4134-9425-30A048CCAA26@sensinode.com> Date: Thu, 19 Nov 2009 11:53:10 +0100 Message-ID: <25c114b90911190253ra808d8cwc80c27efcc1ab065@mail.gmail.com> From: Ulrich Herberg To: Zach Shelby Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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, 19 Nov 2009 10:53:18 -0000 Zach, it's good to hear that the autoconf-addr-model can be used for 6lowpan with only small changes. My comments inline... On Thu, Nov 19, 2009 at 11:18 AM, Zach Shelby wrote: > Hi, > > Over in the 6lowpan WG we are defining a technique for optimizing the hos= t-router (node-router) interface, called 6lowpan-nd. Working on this proble= m for a couple years, and starting with RFC4861 terminology, it turns out t= hat we came to a very similar conclusion to the autoconf WG. However, in 6l= owpan we are routing protocol agnostic and we deal with hosts and routers. > > The link technologies we use in 6lowpan exhibit the characteristics defin= ed (very nicely!) in draft-baccelli-multi-hop-wireless-communications-03. A= lthough we don't always have multi-hop, even then many of the same characte= ristics occur. > > The current version of ietf-6lowpan-nd-07 goes to all the trouble of defi= ning mostly the same things you have (with much more text...). In Hiroshima= we got a kick (thanks Dave!) to explore the use of draft-ietf-autoconf-adh= oc-addr-model to simplify our own document and to unite the models across W= Gs. > > Here are my comments/thoughts on the addr-model-00 document from the 6low= pan perspective: > > 1. Make the document MANET agnostic. This can just as well be referenced = by ROLL and 6LoWPAN work e.g. I only find MANET referenced in the intro (ca= n be extended with other examples) and in the last paragraph of 6.2. Both a= re easily fixed. Yes, that seems to be reasonable for me. > 2. I like the "link of undetermined properties"... however you might want= to point to a document like draft-baccelli-multi-hop-wireless-communicatio= ns to point out why links end up like that. RFC4861 also explains that a li= nk might be non-transitive, so that could also be referenced. I agree that the baccelli draft is very useful. I am undecided on whether to include a reference to that draft in the address model. While I think it could be very useful as a rationale for the address model, I also understand that the chairs are afraid of going this direction. The reason is that autoconf is only chartered for a single document, namely the address model. We are already years behind schedule. Producing a second document -- and including a reference from the address-model ID -- which we are not chartered for, could be difficult to argue for in the IESG. > 3. You have two open issues in Appendix A. To me both of these are OK alr= eady. The link model is fine (see 2). If globally unique addresses are need= ed, leave that to some other mechanism. This is what 6lowpan-nd does for a = 6lowpan network. I think that the authors of the draft will release an updated version very soon that removes the Appendix. Is this correct? > 4. In 6lowpan we would use the "when more specific assumptions can be mad= e about connectivity" clause, as we always assign a single (global or ULA) = prefix across the whole 6lowpan network. So the "MAY be configured with the= same prefix" in Section 4 would be applied. In 6lowpan-nd we are able to m= ake an assumption about connectivity between node-router pairs thanks to ou= r mechanism defined. So please do keep this clause, it is very useful ;-) good :-) > 5. We consider link-local addresses in the same way, this is OK. good. > 6. =A0The second bullet point of Section 6.2 needs some expansion not to = be misunderstood. In addition to the existing sentence, also add text like:= ", unless an assumption can be made about connectivity in which case the p= refix may be /64." The point being that if you can assume connectivity with= a router (who somehow advertises a prefix), you may be able to autoconfigu= re an address using a shared prefix. This is what we do in 6lowpan. One could argue that this is already implicit due to the sentence in sectio= n 3: "When more specific assumptions can be made regarding the connectivity between interfaces, these SHOULD be considered when configuring subnet prefixes." > > So in my opinion, with the very small changes above (1. and 6.), this doc= ument would be very useful for our work. Thanks for your review, Zach. Ulrich From zach@sensinode.com Thu Nov 19 03:31:37 2009 Return-Path: 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 5537E3A6870 for ; Thu, 19 Nov 2009 03:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 kadrDF31ba54 for ; Thu, 19 Nov 2009 03:31:36 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 1A0EF3A6907 for ; Thu, 19 Nov 2009 03:31:35 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nAJBVQSf024601 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Nov 2009 13:31:26 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: Date: Thu, 19 Nov 2009 13:31:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <619B6AB4-B288-4DE4-9D93-42AAECD84D04@sensinode.com> References: <287B72D4-175D-4134-9425-30A048CCAA26@sensinode.com> To: "Dearlove, Christopher (UK)" X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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, 19 Nov 2009 11:31:37 -0000 On Nov 19, 2009, at 12:53 , Dearlove, Christopher (UK) wrote: >> 1. Make the document MANET agnostic. >=20 > MANET is an overloaded term. One meaning is "what's done in > the MANET WG". The other is "what's done in an ad hoc network". > (Why have I dropped "mobile"? - because really it's not mobility > that matters, it's dynamism, and pretty much all ad hoc networks > are dynamic, just the timescale varies.) In the latter sense > - which is what I think matters - what's happening in ROLL and > 6LoWPAN are specialised MANETs. The document may be agnostic on > the former sense, but not, I suggest, on the latter sense. Exactly.=20 Zach >=20 > ******************************************************************** > This email and any attachments are confidential to the intended > recipient and may also be privileged. If you are not the intended > recipient please delete it from your system and notify the sender. > You should not copy it or use it for any purpose nor disclose or > distribute its contents to any other person. > ******************************************************************** >=20 --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From zach@sensinode.com Thu Nov 19 03:37:05 2009 Return-Path: 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 4A29D28C0E8 for ; Thu, 19 Nov 2009 03:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 b0nBfwZLMFVd for ; Thu, 19 Nov 2009 03:37:04 -0800 (PST) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 22C083A6A35 for ; Thu, 19 Nov 2009 03:37:03 -0800 (PST) Received: from [62.145.172.51] ([62.145.172.51]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id nAJBaumh027215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Nov 2009 13:36:57 +0200 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <25c114b90911190253ra808d8cwc80c27efcc1ab065@mail.gmail.com> Date: Thu, 19 Nov 2009 13:37:04 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <287B72D4-175D-4134-9425-30A048CCAA26@sensinode.com> <25c114b90911190253ra808d8cwc80c27efcc1ab065@mail.gmail.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1077) Cc: autoconf@ietf.org Subject: Re: [Autoconf] Comments on adhoc-addr-model-00 X-BeenThere: autoconf@ietf.org 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, 19 Nov 2009 11:37:05 -0000 Ulrich, On Nov 19, 2009, at 12:53 , Ulrich Herberg wrote: >> 2. I like the "link of undetermined properties"... however you might = want to point to a document like = draft-baccelli-multi-hop-wireless-communications to point out why links = end up like that. RFC4861 also explains that a link might be = non-transitive, so that could also be referenced. >=20 > I agree that the baccelli draft is very useful. I am undecided on > whether to include a reference to that draft in the address model. > While I think it could be very useful as a rationale for the address > model, I also understand that the chairs are afraid of going this > direction. The reason is that autoconf is only chartered for a single > document, namely the address model. We are already years behind > schedule. Producing a second document -- and including a reference > from the address-model ID -- which we are not chartered for, could be > difficult to argue for in the IESG. Yep, makes sense. So instead just summarize the reasons why such a link = might be categorized like this with a short paragraph in the = adhoc-addr-model document. You may still point at RFC4861, as = non-transitivity is mentioned there as well. >=20 >> 6. The second bullet point of Section 6.2 needs some expansion not = to be misunderstood. In addition to the existing sentence, also add text = like: ", unless an assumption can be made about connectivity in which = case the prefix may be /64." The point being that if you can assume = connectivity with a router (who somehow advertises a prefix), you may be = able to autoconfigure an address using a shared prefix. This is what we = do in 6lowpan. >=20 >=20 > One could argue that this is already implicit due to the sentence in = section 3: > "When more specific assumptions can be made regarding the = connectivity > between interfaces, these SHOULD be considered when configuring > subnet prefixes." Right, so there could be a pointer to Section 3 at least in that bullet = point to remind the reader of this exception?=20 Zach --=20 http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded = Internet" Mobile: +358 40 7796297 Zach Shelby Head of Research Sensinode Ltd. Kidekuja 2 88610 Vuokatti, FINLAND This e-mail and all attached material are confidential and may contain = legally privileged information. If you are not the intended recipient, = please contact the sender and delete the e-mail from your system without = producing, distributing or retaining copies thereof.=20 From ryuji.wakikawa@gmail.com Mon Nov 30 12:12:13 2009 Return-Path: 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 9974A3A68FF for ; Mon, 30 Nov 2009 12:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 FHmaDDJ2buY5 for ; Mon, 30 Nov 2009 12:12:09 -0800 (PST) Received: from mail-qy0-f183.google.com (mail-qy0-f183.google.com [209.85.221.183]) by core3.amsl.com (Postfix) with ESMTP id 28C2D28C167 for ; Mon, 30 Nov 2009 12:12:07 -0800 (PST) Received: by qyk13 with SMTP id 13so230127qyk.31 for ; Mon, 30 Nov 2009 12:11:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:content-type :content-transfer-encoding:subject:date:message-id:to:mime-version :x-mailer; bh=puCQzpuo0rK1UQbBTAEewsJ8pyyOOhNQkzDaX4vjoOo=; b=OnZwcza11G9zRX84kDGpNpFnui3jEdtcmBKVhFyX/AO3weZcohqC8T6g/bkL3twhzr cniPizpnJc6fjaeZzwZ4EG1qslhSgRnd7z/+ukbEkNfYNYQgyE3Hea17js/rObcb6xvu MCjDO6d6ek0ddTjSKuIxP4riG3VFJkZPxQjbU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=aVw0NILys7g0VN8MYou/rPllK9kqYTYbaePz3UJg2XhJ+nlUofzK1uLK3Zyqhd6OMj IbPYFen+A4HGn6CQuhuB+ny4uNCuGOJW4i0XMbForu31tfRdDsJ+TGku7aupB44mJ6ym EjF8798/vNgJf4dytgWgt475GmJtzvuzxxf+U= Received: by 10.224.63.202 with SMTP id c10mr2388525qai.39.1259611916490; Mon, 30 Nov 2009 12:11:56 -0800 (PST) Received: from ?192.168.110.114? ([206.132.173.18]) by mx.google.com with ESMTPS id 5sm12562469qwg.28.2009.11.30.12.11.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 30 Nov 2009 12:11:55 -0800 (PST) From: Ryuji Wakikawa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 30 Nov 2009 12:11:48 -0800 Message-Id: <0071C220-367A-419E-A77F-20A781B700B7@gmail.com> To: autoconf@ietf.org Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Subject: [Autoconf] The minutes of IETF 76th autoconf meeting X-BeenThere: autoconf@ietf.org 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: Mon, 30 Nov 2009 20:12:13 -0000 Hi all, The draft minutes is now available on the IETF web. http://www.ietf.org/proceedings/09nov/minutes/autoconf.txt Special thanks to Fred and Mark for taking the minutes! We also thanks to Ulrich for the jabber scribe. Please review the minutes and send additions and/or corrections if necessary. regards, ryuji